Hej Det beror naturligtvis på serverns kapacitet, om det är den enda sidan som körs från servern, hur många samtidiga användare du har och framförallt serverns RAM-minne som håller listan medan den används. Hej, Tack för svaren. Jag kodar inte .NET utan gammal ASP. Om ett "Race condition" kan uppstå bör du låsa appliakationen när du uppdaterar din globala variable. Spara en array i application("")
Jag har en del listor som är globala. Listorna sprarar jag som array och i application.
application("lista") = strLista
Detta fungerar mycket bra (snabbt som bara den) och jag slipper hämta från databas varje gång en användare vill se på listan.
Nu till frågan:
Nu stora listor kan jag spara på detta visset innan det börjar sega ner servern? idag har jag nog en lista på 1000 rader.
Någon som har erfarenhet av detta? Bra eller dåligt.
mvh
DavidSv: Spara en array i application("")
En gissning är att du utan problem kan köra listor på några hundra tusen.Sv: Spara en array i application("")
Delar du listan mellan flera sidor eller bara på en sida? För då kan du använda cache-hanteringen i ASP .Net istället för att nyttja Application, det medför lite mer "ren" kod så att säga. OBS! Endast om
det används på en sida. Delar du mellan flera sidor är Application helt ok. Dock skulle jagförseslå designmässigt att du bygger en egen liten klass som nyttjar applikation för att öka spårbarheten.
Ex.
IList customerList = CacheLists.Customer();
IList userOnlineList = CacheLists.UserOnline();
class CahceLists
{
public static IList Customer()
{
return ( (IList)Application["Customer"]);
}
...
Ang hur mkt och många poster du kan spara har du redan fått ett bra svar på. Men Måste du spara listor på detta sätt har du så stora prestanda problem så du inte kan hämta in dem varje gång?
Det är väldigt vanligt att man spenderar 80% av sin utv tid helt i onödan på att bygga optimalkod som inte behövs. Mitt tips är att du först kodar det du vill göra ha en bra OO modell. Om prestandan inte räcker åt när man är klar och gör tester då kan man börja optimera de ställen som går trögt istället för spendera tid på alla ställen helt i onödan. Du kommer bli förvånad över hur fort du kommer bli klar i tiden genom detta arbetssätt. YAGNI som det kallas. (You Aren't Gonna Need It).
Ex. Gör en klass för varje Lista, antar att listorna innehåller något som kan binda listan till sin egna klass. Ex Customer, Article, Invoice... Gör en metod som hämtar listan. Gå mot databas för att fylla listan. Anropa alltid denna metod när du vill ha listan istället för Application[""] syntax. Gör prestanda tester håller inte måtten efter kunden eller dina krav då kan du enkelt bara lägga till lite optimering i din metod i efterhand där du ser till så listan bara läser in en gång. Du behöver då inte ändra koden i UI som anropar dina Listor utan bara ändra lite lätt koden inne i metoden som ger dig listorna.
Mvh JohanSv:Spara en array i application("")
Prestandavinsten jag gjorde med detta var enorm, därför vill jag använda detta sätt på flera funktioner.
mvh
DavidSv: Spara en array i application("")
Jag antar att du läser in variablerna i Application start?
Listan finns sparad i en databas?
Om någon lägger till en ny post i listan för datasen, uppdaterar du listan från databasen?
Jag tror då risken för "Race conditions" är minimal.
"Race conditions" är mer troligt att inträffa om man har:
<%
Application("visits")=Application("visits")+1
%>
Då asp är trådat kan en request hämta visits, avbrytas för en annan tråd som hämtar visits och skriver över med visits+1. Den första requesten får fortsätta oc uppdaterar visits med samma värde.
Just för besökare är det ju ingen kritisk funktionalitet. Men det kan ställa till det i andra situationer.
För att undvika det skriver man:
<%
Application.Lock
Application("visits")=Application("visits")+1
Application.Unlock
%>
Lock/Unlockfungerar som en mutex/semaphore.