Paging: besser auf Client oder Server?

verwendetes Datenbanksystem: MS SQL 2008

Hi,

ich habe eine Performance Frage vor der ich jetzt stehe und die ich mir selbst leider nicht beantworten kann.

Ich habe ein Webprojekt mit einem GridControl und ich stehe jetzt vor der Frage welcher Weg der Datenbeschaffung der richtige ist.

Das Grid bietet Paging mit z.B. 20 Einträgen pro Seite.
Jetzt kann ich technisch beides machen, ich kann einmal alle Daten holen, diese dann lokal cachen und alles was danach passiert, wie im Grid filtern, mittels Paging blättern und sortieren auf den lokalen Daten machen, oder ich kann mir immer nur die 20 Einträge holen und mit diesen arbeiten und bei jeder Aktion die Daten neu holen, aber eben immer nur 20 Einträge, statt vielleicht 2000.

Das eine sind halt viele DB Abfragen, aber dafür lächerliche.
Das andere ist viel RAM Verbrauch und einmal eine sehr lange Abfrage, aber dafür nur eine.

Ratschläge?

Hallo,

ja das ist das typsiche Fat-Client vs. Thin-Client 😉
Eine konkrete Antwort wirst du wohl nicht bekommen können, denn es weiß niemand mehr über deine Anwendung - zB was macht der Benutzer mit den angezeigten Daten - und es ist teils auch glaubensfrage. Letzen Endes kannst nur du das entscheiden.

Probier am besten beide Varianten und schau wie es besser ist.

mfG Gü

Also, du meinst von Fall zu Fall entscheiden?!

Ist wahrscheinlich das beste, oder...

Hallo Curse4Life,

wenn du dir sicher bist dass du nie die riesigen Datenmengen in deiner Applikation erreichen wirst dann kannst du einen Fat-Client verwenden

Wenn die Datenmenge mit der zeit wächst und du früher oder später viele Daten zusammenkriegst dann ist es wohl besser einen Thin-Client zu verwenden.

Aber wie schon gfoidl gesagt hat musst du das von Fall zu Fall unterscheiden und es evtl. mit Performancetests überprüfen

Mir sind Fat-Clients lieber. Denn da kann man im Paging sehr schnell umschalten.
Aber wenn zu viele Daten sind dann dauert es am Anfang zu lange und frisst zu viel Ram...

Gruß
Michael

Tja, müsste man mal wissen, was so eine Instanz(DB Model) an RAM verbraucht...
Dann könnte man ja rechnen, eine Klasse 10 KB x 2000.

Aber sowas kann man wahrscheinlich nur mit irgendwelchen teuren Tools rausfinden.

Hallo,

such einfach mal nach "fat client vs. fat server" oder "fat client vs. thin client" und du wirst "Glaubenskriege" erleben. Eine pauschale Antwort der Art "es ist besser ABC zu verwenden" gibt es hier nicht.

Früher wo die Client-Rechner alle schwach waren und nur der Server Leistung hatte war Thin-Client eindeutig im Vorteil. Die Client-Rechner sind heutzutage aber auch schon sehr leistungsstark (zumindest verglichen mit früher) und somit ergab sich als (logische) Konsequenz den Server etwas zu entlasten und Teile von "Serveraufgaben" zum Client zu verlagern. Es gibt dann halt nicht nur die beiden Extreme sondern auch alles dazwischen und für jede Anwendung ist irgendwo dazwischen das Optimum. Das kann aber nciht pauschal festgestellt werden. Deshalb probiere es einfach aus.

Überlege einfach was für Vor- und Nachteile jede Variante hat und wäge dann ab was gewichtiger ist.

ZB wenn die Netzwerkverbindung zur Datenbank langsam ist dann können mehrere Daten als benötigt auf einemal geholt werden - ist zwar einmalig langsamer aber in Summe wahrscheinlich schneller.

ZB wenn die Daten von mehrere Benutzer gleichzeitig bearbeitet werden können und ich hole alle auf einmal lokal und ein anderer Benutzer ändert einen Datensatzt (schreibt diese auch in die DB) dann der Benutzer im lokalen Cache alte - womöglich ungültige - Daten vorliegen.

usw.
Es hängt halt sehr davon ab welche Anwendung gemacht wird.

Tja, müsste man mal wissen, was so eine Instanz(DB Model) an RAM verbraucht...
Aber sowas kann man wahrscheinlich nur mit irgendwelchen teuren Tools rausfinden.

Zum abschätzen geht das auch mit .net-Bordmitteln und ein paar Zeilen Code (3 Zeilen eigentlich). Der GC bietet die Methode GetTotalMemory. Wie diese dazu verwendet wird überlass ich als Rätselaufgabe dir 😉

mfG Gü

Es kommt nicht nur auf die Menge der Datensätze an, sondern auch auf die Übertragungsgröße des Umfelds. Das trifft auch das Thema, dass der Client mehr arbeit übernimmt.
Ich würde bei Web-Anwendungen immer schauen, möglichst wenig Daten auf einmal zu laden; und lieber Nachladen anstatt den Usern ewig vor einem rotierenden Kringel warten zu lassen. Bei Webanwendungen bietet sich hier vor allem Json an, das im Vergleich enorm wenig Overhead erzeugt.

Hallo!

Was ist mit einer kombinierten Alternative:
Man macht die Anfrage auf alle Datensätze, aber sobald die ersten x Seiten vorhanden sind, lässt man diese bereits anzeigen, während im Hintergrund der Rest geladen wird (ungefähr so, wie es im SQL Management Studio gemaht wird).

Allerdings wird man sich dafür eine Art DataSource-Proxy schreiben müssen.

Ich würde immer nur eine laden lassen und den Client nicht wissen wieviel Seiten es gibt.

Und dann so vorgehen dass der Server dem Client 21 Einträge sendet wenn es eine neue Seite dannach gibt und somit Paging zur nächsten Seite aktivieren bis er auf der letzten Seite ist. Dies wäre denke ich am perfomantesten bei größerer Datenmenge, da weder Client noch Server alle Einträge holt sondern nur in "Häppchen" 😃