[ASP.NET C#] Tabellen opslaan geheugen of anders?

[DerKleinePunkt]

Taal
ASP.NET in C# versie 3.5

Database
Microsoft SQL 2005

Situatieschets
Neem een willekeurige categorie en product tabel van bijv. een onlineshop. Momenteel worden deze tabellen per aanvraag elke keer opnieuw ingelezen. Dit proces moet efficiënter, maar hoe? (ben nog een beginner)

Mijn idee
De gegevens van de betreffende tabellen in het geheugen wegschrijven en vervolgens met linq uitlezen (paging is een vereiste).

Struikelblokken
De gegevens worden per gebruiker in het geheugen weggeschreven. Heb je 10 gebruikers dan staan dezelfde gegevens dus 10 keer in het geheugen. Welke mogelijkheid heb ik om alles eenmalig weg te schrijven voor alle gebruikers? Is application data een oplossing en / of wat zijn struikelblokken hiervan, een limiet of iets dergelijks?

Suggesties
Wat vinden jullie van mijn idee? Hoe zouden jullie dit aanpakken en / of welke alternatieven heb ik?

[ Voor 12% gewijzigd door DerKleinePunkt op 18-08-2008 23:09 ]

[Verwijderd]

.NET bevat zelf volgens mij prima functionaliteit voor caching (dat is wat je bedoelt). Zie bijvoorbeeld deze MSDN pagina:
http://msdn.microsoft.com/en-us/library/xsbfdd8c(VS.71).aspx

Ik denk dat, ook omdat je zelf aangeeft dat je een beginner bent, je hier het best niet aan kunt branden. Gewoon de uitgebreide .NET libraries gebruiken ;-)

[gorgi_19]

Suggesties
Wat vinden jullie van mijn idee? Hoe zouden jullie dit aanpakken en / of welke alternatieven heb ik?

Niet cachen een optie? 10 gebruikers met paging is peanuts voor een webserver / database.

[whoami]

Je volledige DB in het geheugen inladen ?
Wat als je DB enkele GB's aan informatie bevat ?
Wat ga je doen als gebruiker x iets wijzigt aan record A, en gebruiker y wil daarna dat record (dat hij al in 't geheugen heeft) gaan bekijken ?

Haal gewoon de informatie uit de DB op op het moment dat je ze nodig hebt. Data die (redelijk) statisch is, kan je evt gaan cachen (met de infrastructuur die .NET daarvoor biedt) mocht dit nodig blijken.

[BulMi]

Ik vind het wel een interesante vraag om te weten hoe ver ga je met cachen?
Stel je hebt 1000 producten, gaan deze allemaal in de application cache?
En als het er 10.000 zijn doe je het dan ook nog?

[DerKleinePunkt]

Verwijderd schreef op maandag 18 augustus 2008 @ 23:07:
.NET bevat zelf volgens mij prima functionaliteit voor caching (dat is wat je bedoelt). Zie bijvoorbeeld deze MSDN pagina:
http://msdn.microsoft.com/en-us/library/xsbfdd8c(VS.71).aspx

Ik denk dat, ook omdat je zelf aangeeft dat je een beginner bent, je hier het best niet aan kunt branden. Gewoon de uitgebreide .NET libraries gebruiken ;-)

Als beginner wil je natuurlijk wel graag nieuwe dingen leren

gorgi_19 schreef op dinsdag 19 augustus 2008 @ 08:10:
[...]

Niet cachen een optie? 10 gebruikers met paging is peanuts voor een webserver / database.

Het getal 10 was gewoon een willekeurig gekozen waarde, denk aan 1000+ bezoekers per dag.

whoami schreef op dinsdag 19 augustus 2008 @ 08:54:
Je volledige DB in het geheugen inladen ?
Wat als je DB enkele GB's aan informatie bevat ?
Wat ga je doen als gebruiker x iets wijzigt aan record A, en gebruiker y wil daarna dat record (dat hij al in 't geheugen heeft) gaan bekijken ?

Haal gewoon de informatie uit de DB op op het moment dat je ze nodig hebt. Data die (redelijk) statisch is, kan je evt gaan cachen (met de infrastructuur die .NET daarvoor biedt) mocht dit nodig blijken.

Het was mijn bedoeling statische tabellen zoals een categorieen of merken op te slaan in het geheugen.

Michel82 schreef op dinsdag 19 augustus 2008 @ 08:56:
Ik vind het wel een interesante vraag om te weten hoe ver ga je met cachen?
Stel je hebt 1000 producten, gaan deze allemaal in de application cache?
En als het er 10.000 zijn doe je het dan ook nog?

Hier ben ik dus ook benieuwd naar?

[Verwijderd]

DerKleinePunkt schreef op maandag 18 augustus 2008 @ 22:59:
Mijn idee
De gegevens van de betreffende tabellen in het geheugen wegschrijven en vervolgens met linq uitlezen (paging is een vereiste).

Sinds de row_number() functie in MSSQL (vanaf 2005) is 't niet echt meer nodig om voor paging gebruik te maken van een eigen caching systeem. MSSQL handelt dat nu prima zelf af.
Bij MSSQL 2000 kon dat ook wel redelijk efficient, maar dan via een temp table, en dan zat je al gauw vast aan een stored procedure. Ook geen ramp, maar net iets omslachtiger...

Zelf de boel naar memory copieren is sowieso niet handig, en bij een website ook niet sneller dan wat .NET's caching en MSSQL je bieden.
HTTP is per definitie stateless, en de kans dat je na pagina 1 (die de gegevens cachet) op pagina 2 ook nog bij de cache van pagina 1 kunt is binnen je website nogal nihil: pagina 2 krijgt gewoon weer een nieuwe instance van je connectie, dus je oude gegevens zijn niet meer benaderbaar.
't Kan wel, door een cache service te schrijven die tussen je website en je database zit, maar tenzij je heel veel data real time moet serveren is 't de moeite niet waard.

[gorgi_19]

DerKleinePunkt schreef op dinsdag 19 augustus 2008 @ 16:44:
Het getal 10 was gewoon een willekeurig gekozen waarde, denk aan 1000+ bezoekers per dag.

Vind ik nog niet zo heel bijzonder; mocht de performance echt onderuit gaan, dan kan je eens gaan denken aan een page caching van 1 tot 3 seconden op de meest gebruikte pagina's.
Maar 60k aan queries is niet zo gek veel, imho.

Michel82 schreef op dinsdag 19 augustus 2008 @ 08:56:
Ik vind het wel een interesante vraag om te weten hoe ver ga je met cachen?
Stel je hebt 1000 producten, gaan deze allemaal in de application cache?
En als het er 10.000 zijn doe je het dan ook nog?

Echt schaalbaar is dat niet, kan je imho beter een page caching toepassen.

[ Voor 32% gewijzigd door gorgi_19 op 19-08-2008 21:34 ]

[Cousin Boneless]

Je kan in .net static fields gebruiken.. Static wil zeggen als dat er maar eentje van is in de hele applicatie, over alle gebruikers. Heel erg singleton dus.

Echter moet je de kracht van de database niet onderschatten. Ik krijg ook behoorlijke performance uit de paging in MSSQL 2005. Zowel met dit nieuwe row_number() als ook met een temp tabel en een identity field (+/- 40000 records). Het is milliseconde werk.

[Woy]

Somige data die veel gebruikt word zou je op kunnen slaan in de Cache of in de Application collection, die is voor alle users beschikbaar. Maar de vraag is natuurlijk of een klein beetje performance opweegt tegen al het extra werk dat je moet doen om de data up-to date te houden. Zolang je database nog geen bottleneck is, zou ik gewoon elke keer de data ophalen, weet je zeker dat de data up-to-date is.

Maar als je veel pagina's hebt die vaak hetzelfde zijn kun je beter output caching gaan gebruiken. Dat is een stuk eenvoudiger, en bespaart nog meer dan alleen de data te cachen.

Cousin Boneless schreef op dinsdag 19 augustus 2008 @ 22:53:
Je kan in .net static fields gebruiken.. Static wil zeggen als dat er maar eentje van is in de hele applicatie, over alle gebruikers. Heel erg singleton dus.

Echter moet je de kracht van de database niet onderschatten. Ik krijg ook behoorlijke performance uit de paging in MSSQL 2005. Zowel met dit nieuwe row_number() als ook met een temp tabel en een identity field (+/- 40000 records). Het is milliseconde werk.

Static is niet "heel erg singleton". Je kunt static wel gebruiken om het Singleton pattern te implementeren. Maar ik zou het niet aanraden, je moet dan meteen rekening gaan houden met Concurrency, aangezien ASP.NET van nature multi-threaded is. En zoals ik hierboven al aanhaal moet je ook een mechanisme maken die zorgt dat de Data altijd up-to-date is. Uiteindelijk vraag ik me af hoe veel winst je er echt mee maakt.

[ Voor 6% gewijzigd door Woy op 20-08-2008 10:23 ]

[DerKleinePunkt]

Loont het zich überhaupt waarden in het geheugen weg te schrijven mits men beschikking heeft over de juiste caching methoden? Hoe zit dat bijvoorbeeld met sites zoals Tweakers.net?

[Woy]

DerKleinePunkt schreef op woensdag 20 augustus 2008 @ 16:21:
Loont het zich überhaupt waarden in het geheugen weg te schrijven mits men beschikking heeft over de juiste caching methoden? Hoe zit dat bijvoorbeeld met sites zoals Tweakers.net?

Bij de Tweakers.net frontpage zullen ze waarschijnlijk output caching gebruiken. Op het forum zal dat een stuk minder effect hebben aangezien dat veel dynamischer is

[Creepy]

Ff een open deur intrappen:

Dit proces moet efficiënter

Waarom? Is het traag? Wat is je bottleneck (aka, profilen!)?

[DerKleinePunkt]

Creepy schreef op woensdag 20 augustus 2008 @ 16:42:
Ff een open deur intrappen:

[...]

Waarom? Is het traag? Wat is je bottleneck (aka, profilen!)?

[flauw]
Deur snel dicht gooit...
[/flauw]

Het lijkt / leek me niet efficient elke keer de database te moeten benaderen voor ophalen van dezelfde gegevens. Om dit proces te versnellen lijk / leek het mij een idee enkele tabellen in het geheugen weg te schrijven.

[Woy]

DerKleinePunkt schreef op donderdag 21 augustus 2008 @ 09:32:
[...]


[flauw]
Deur snel dicht gooit...
[/flauw]

Het lijkt / leek me niet efficient elke keer de database te moeten benaderen voor ophalen van dezelfde gegevens. Om dit proces te versnellen lijk / leek het mij een idee enkele tabellen in het geheugen weg te schrijven.

Je weet dat de database zelf waarschijnlijk ook een cache heeft, en dus data die vaak opgevraagd word gewoon in zijn geheugen cached?

Maar het gezegde is niet voor niks: "Premature optimization is the root of all evil!"

[DerKleinePunkt]

rwb schreef op donderdag 21 augustus 2008 @ 09:35:
[...]

Je weet dat de database zelf waarschijnlijk ook een cache heeft, en dus data die vaak opgevraagd word gewoon in zijn geheugen cached?

Maar het gezegde is niet voor niks: "Premature optimization is the root of all evil!"

Ben bekend met database cache, maar met mijn werkwijze zou ik meer (kunnen) controle hebben over de gegevens. Ben nou eenmaal een control freak

Gezegde: een goed begin is het halve werk.

[farlane]

DerKleinePunkt schreef op donderdag 21 augustus 2008 @ 23:16:
Gezegde: een goed begin is het halve werk.

Een goed begin van optimaliseren is weten _wat_ je moet optimaliseren.

[Woy]

DerKleinePunkt schreef op donderdag 21 augustus 2008 @ 23:16:
[...]
Ben bekend met database cache, maar met mijn werkwijze zou ik meer (kunnen) controle hebben over de gegevens. Ben nou eenmaal een control freak

Dan zou ik een cache systeem maken dat je data relationeel op kan slaan, je zou dan eventueel een taal kunnen maken om deze data te queryen. Dan heb je echt veel controle

[gorgi_19]

rwb schreef op vrijdag 22 augustus 2008 @ 09:13:
[...]

Dan zou ik een cache systeem maken dat je data relationeel op kan slaan, je zou dan eventueel een taal kunnen maken om deze data te queryen. Dan heb je echt veel controle

Ja En op een bepaald moment lijkt het je handig om deze niet in memory te cachen, maar op schijf (anders ben je anders na een power failure / restart kwijt ). En dan heb je vervolgens een probleem als je wilt opschalen, want hoe moet je dan met je andere webserver bij de data? De oplossing, je zet hem dan op een aparta dataserver die je de boel laat cachen

[Creepy]

DerKleinePunkt schreef op donderdag 21 augustus 2008 @ 23:16:
[...]


Ben bekend met database cache, maar met mijn werkwijze zou ik meer (kunnen) controle hebben over de gegevens. Ben nou eenmaal een control freak

Gezegde: een goed begin is het halve werk.

Ken je "premature optimization is the root of all evil" al?

Dus ga pas optimaliseren als je er 100% zeker van bent dat het wat gaat oplossen. Je weet nu niet eens of je uberhaupt een performance probleem hebt en als je die al hebt waar het hem dan precies in zit.

Dus hoe lang duurt het ophalen van al die "vaste gegevens" voor elke gebruiker nu? Hoeveel van die tijd wordt besteed door de database?

[ Voor 10% gewijzigd door Creepy op 22-08-2008 10:01 ]

[DerKleinePunkt]

gorgi_19 schreef op vrijdag 22 augustus 2008 @ 09:40:
[...]

Ja En op een bepaald moment lijkt het je handig om deze niet in memory te cachen, maar op schijf (anders ben je anders na een power failure / restart kwijt ). En dan heb je vervolgens een probleem als je wilt opschalen, want hoe moet je dan met je andere webserver bij de data? De oplossing, je zet hem dan op een aparta dataserver die je de boel laat cachen

Het sarcasme druipt er vanaf, gaan jij en rwb even lekker buiten spelen

Creepy schreef op vrijdag 22 augustus 2008 @ 09:59:
[...]

Ken je "premature optimization is the root of all evil" al?

Dus ga pas optimaliseren als je er 100% zeker van bent dat het wat gaat oplossen. Je weet nu niet eens of je uberhaupt een performance probleem hebt en als je die al hebt waar het hem dan precies in zit.

Dus hoe lang duurt het ophalen van al die "vaste gegevens" voor elke gebruiker nu? Hoeveel van die tijd wordt besteed door de database?

Het leek me geen gek idee om "extern advies" in te winnen voordat ik ermee aan de slag ging. Jou gezegde heb ik nog niet eerder gehoord (scroll eens naar boven ) Ik zal me eens vertiefen in het caching verhaal.