F�r ein Forum w�rde es sinn machen nach Threads zu initialisieren. Dann kannste direkt auf dem Cache die Daten schreiben (neue Postings usw.) und das Cache Objekt kann gleichzeitig auch in die DB schreiben.
-----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Thomas Bandt Gesendet: Montag, 28. Februar 2005 09:57 An: [email protected] Betreff: AW: [Asp.net] Ressourcen schonendes Paging mit DataReader Gr�� dich, nun, ich kann das Caching ja auch verwenden, wenn ich mir immer nur die gew�nschten Records per Page aus der DB geholt habe, dann Cache ich z.B. das DataSet mit den Eintr�gen pro Seite. Damit habe ich auch beide Vorteile, d.h. sowohl beim ersten Aufruf m�ssen nicht ggf. 100.000 Datens�tze geholt werden, und auch beim Zweiten geht's dann nochmal ne Runde schneller. Das Problem ist, dass ich es teilweise z.B. f�r ein Forum ben�tige, wo es eigentlich keinen Sinn macht bzw. sehr schwierig ist, komplette Hitlisten zu cachen, da sich die ja st�ndig �ndern (bei Anzeige von Aufrufen, Antworten usw.). D.h. Caching JA - unter Abw�gung der Gegebenheiten, Das holen von tats�chlich gebrauchten Datens�tzen - auf jeden Fall. Gru�, Thomas http://blogs.dotnetgerman.com/thomas/ > -----Urspr�ngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Pessner, Andreas > Gesendet: Montag, 28. Februar 2005 09:01 > An: [email protected] > Betreff: AW: [Asp.net] Ressourcen schonendes Paging mit DataReader > > Ich denke man sollte in dem Fall einfach mal abw�gen was �berwiegt! > > 1. der Traffic (die Anzahl der Leute die auf der Seite ist) > 2. die Anzahl der Eintr�ge in der DB > > Das Cachen des kompletten Objektes via Dataset oder > Hashtable, ArrayList usw. kann f�r Punkt 1 eine gigantische > Leistungssteigerung bringen - verbraucht aber auch im > Umkehrschluss mehr Ressourcen - was sich bei zunehmenden > Punkt 2 ung�nstig bemerkbar machen wird. (Weil das Objekt ja > immer neu gef�llt werden muss - wenn der Cache ausgelaufen ist). > > Bei wenigen Besuchern - ist das direkte einlesen der > gew�nschten Eintr�ge aus der DB am sinnvollsten. Wenn wenig > los ist lohnt sich das Cachen der Daten deutlich weniger. > > Man kann auch einen Mischkultur aus beiden implementieren. > Dazu habe ich ein Objekt gebaut - der die Daten sowie der > bereits geholten EintragsIDs zwischenspeichert. Wenn ein > Zugriff auf eine Seite geschieht - wird erstmal in den Cache > geschaut - wenn Die Daten da liegen - werden diese von dort > gelesen - wenn nein werden die Daten aus der DB nachgelesen - > und dann aus dem erweiterten Cache zur�ck gegeben. > > Das gibt den Vorteil - dass man die Performancesteigerung > durch den Cache - mit der Schnelligkeit bei der > Initialisierung verbindet. Indem ja immer nur die gew�nschten > Daten auf einen Rutsch gelesen werden m�ssen. Nat�rlich > verbraucht dieses Objekt auch mehr Speicher im Server - aber > das ist bei caching eigentlich immer der Fall. > > > -----Urspr�ngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Thomas Bandt > Gesendet: Samstag, 26. Februar 2005 12:54 > An: [email protected] > Betreff: RE: [Asp.net] Ressourcen schonendes Paging mit DataReader > > Ja das ist eigentlich die sinnvollste L�sung, so habe ich es > jetzt auch > gemacht. Hatte wohl irgendwie nen Knoten im Hirn. > > Gru�, Thomas > _____________________________________ > http://blogs.dotnetgerman.com/thomas/ > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Buchholz > > Sent: Saturday, February 26, 2005 12:03 PM > > To: [email protected] > > Subject: Re: [Asp.net] Ressourcen schonendes Paging mit DataReader > > > > On Fri, 25 Feb 2005 23:13:01 +0100, Thomas Bandt > > <[EMAIL PROTECTED]> wrote: > > > Hallo, > > > > > > gegeben: ASP.NET 1.1, SQL Server 2000 als Datenquelle, > > Repeater-Control > > > zur Listendarstellung. > > > > Hi! > > > > Eben aus den Performance-Bedenken holen wir uns > mittlerweile nur noch > > die Datens�tze von der DB, die wir wirklich im Frontend > sehen wollen. > > Dazu bekommt die jeweilige procedure die gew�nschte Seite und die > > Anzahl der Datens�tze als Parameter. Die procedure > ermittelt zun�chst > > nur die PKs die aufgrund der Suchbedingungen relevant sind, packt > > diese in eine tempor�re Tabelle und ein zweites Select holt dann die > > passende "Seite" aus der temp. Tabelle und die f�r das Frontend > > relevanten Daten zus�tzlich. > > > > Daniel > > _______________________________________________ > > Asp.net Mailingliste, Postings senden an: > > [email protected] > > An-/Abmeldung und Suchfunktion unter: > > http://www.glengamoi.com/mailman/listinfo/asp.net > > > > > _______________________________________________ > Asp.net Mailingliste, Postings senden an: > [email protected] > An-/Abmeldung und Suchfunktion unter: > http://www.glengamoi.com/mailman/listinfo/asp.net > > _______________________________________________ > Asp.net Mailingliste, Postings senden an: > [email protected] > An-/Abmeldung und Suchfunktion unter: > http://www.glengamoi.com/mailman/listinfo/asp.net > > _______________________________________________ Asp.net Mailingliste, Postings senden an: [email protected] An-/Abmeldung und Suchfunktion unter: http://www.glengamoi.com/mailman/listinfo/asp.net _______________________________________________ Asp.net Mailingliste, Postings senden an: [email protected] An-/Abmeldung und Suchfunktion unter: http://www.glengamoi.com/mailman/listinfo/asp.net
