Har ett projekt som jag håller på och utvecklar, men inte tagit del av cachning och viewstate. Nån som har en bra åsikt om detta? :) Det finns en mljon saker du kan göra för att få din applikation snabbare och allihop är helt beroende på ditt scenario och hur din applikation är uppbyggd. Vad är explicit casting? Response.Redirect("newpage.aspx", false); Patrik, du som verkar ha kolla på detta med cachning.. (även andra får svara.... :-)) Jag tycker att för ditt scenario är det det en fullständigt normal lösning. När ska man använda cachning av sidor eller viewstate
hur kan man förbättra prestandan?
vad kan man göra snabbare?Sv: När ska man använda cachning av sidor eller viewstate
Några generella tips dock:
1) Stäng av viewstate på kontroller som inte behöver resa några händelser vid en postback och på kontroller som inte behöver komma ihåg någt tillstånde mellan postbacks.
2) Använd inte DataBinder.Eval utan jobba med explicit casting.
3) Använd aldrig DataBind på sid nivå (dvs this.DataBind) eftersom den itererar alla kontroller och ropar på DataBind även på de som inte har någon data att binda till.
4) Undvik Response.Redirect, om du måste använda Response.Redirect sätt EndRepsonse flaggan till fals så det inte kastas ett thread abort exception
5) Använd outputcache i så stor usträckning som möjligt
6) Där output cache inte är tillämpligt, försök att lagra data som inte är transaktions intensiv med hjälp av Cache api'et (ex listor på länder, produkt kategorier mm som sällan ändras)Sv:När ska man använda cachning av sidor eller viewstate
Var ska EndResponse-flaggan vara? Jag får det där undantaget i min fellogg efter att en användare har loggat in...Sv: När ska man använda cachning av sidor eller viewstate
Explicit casting i databindning ser ut ungefär så här:
<%# ((DataRow)Container.DataItem)["Name"] %>Sv:När ska man använda cachning av sidor eller viewstate
Jag har i ett nytt projekt bestämt mig för att använda mycket cachning av datatabeller som sällan ändras.. (konton, projektkoder, osv)... (men som man vill kunna söka i mha filter, därför cachar jag det som Dataset)
För närvarande är det kanske 30 dagliga användare i systemet.
På sikt kommer det bli kanske omkring 500 användare som är i systemet dagligen. Jag gissar att det kommer vara runt 300 samtidiga användare när det är som mest belastning.
Lite överdrivet räknat kommer antalet Dataset som mest att bli omkring 200 st (inte per användare utan datasetten är en handfull per organisation och det kommer finnas ca 40 organisationer sen)
Fortfarande väldigt högt räknat är de 100 kb/Dataset, alltså ca 20 MB minne totalt.
Servern har 2 GB RAM... så jag tycker det ska vara helt lugnt.. eller? :)
Prestandan i dessa sökningar är väldigt bra (nu!). Man hinner inte blinka.
På servern finns andra applikationer som körs. aspnet_wp var sist jag kollade uppe i ca 250 MB.
Alternativen jag har är att slå upp i ett stordatorsystem (Det går iofs, men det blir för segt.. Jag hämtar därifrån om det saknas data i cachen.. det tar ca 2-5 sekunder per Dataset att göra en sådan hämtning, beroende på hur stort det är.. och därför cachas det..)... ELLER att dubbellagra all data i en SQL-databas (vill vi inte göra).
Ok lösning eller fullkomligt galet..?? :-DSv: När ska man använda cachning av sidor eller viewstate
Du kanske kan kombinera med att lagra tempfiler på disk om du inte vill kasta in mer minne i servern. Men är det en hyfsat ny burk så är mer minne ganska billigt.
Det jag kanske hade gjort, om det bara är read data, är att jag skulle skapat mina egna datastrukturer. DataSet är rätt tungrodda och det skulle nog spara en del minne.
Liten notis bara, man måste skilja på samtidiga användare och samtidiga sessioner på en webbapplikation. Det där hänger tyvärr kvar från gamla client / server när samtidg användare var == samtidiga sessioner men det stämmer inte riktigt längre.
För en webbapplikation betyder samtidiga användare samtidiga förfrågningar mot servern, medans samtidiga sessioner är hur många användare som surfar runt just nu.