ASP.NET WebForms

Απ: Postback databinding: Viewstate vs Database reload

Mitsaras — Mon, 25 Sep 2006 03:14:43 GMT

Ευχαριστώ για τα σχόλια. Με πρόλαβες, ήθελα κι εγώ να βάλω link στο άρθρο του Infinities loop, το οποίο είναι από τα πιο αναλυτικά που υπάρχουν (αν και νομίζω ότι το έχω κάνει στο παρελθόν).

Απ: Postback databinding: Viewstate vs Database reload

KelMan — Mon, 25 Sep 2006 02:54:25 GMT

Δεν ξέρω τι κάνει και πως το κάνει η σελίδα του Πλαισίου ή μάλλον οι developers που έφτιαξαν τη σελίδα του Πλαισίου και είναι λίγο δύσκολο να υποθέσει κανείς αν δεν δει το source κώδικα. Γενικά, το ViewState είναι ένα από τα πιο misused χαρακτηριστικά του ASP.NET και ως εκ τούτου υπάρχει πάντοτε η πιθανότητα η όποια σελίδα να έχει τεράστιο ViewState που να έχει προκύψει από κακή (ή μη-optimized) χρήση του.

Από την άλλη μεριά, σε ό,τι αφορά το scalability, σε μια ολοκληρωμένη εφαρμογή που αποτελείται από πολλά tiers, μία λύση (όπως η χρήση queries αντί ViewState) που μπορεί να δουλεύει καλά σε μια δεδομένη χρονική στιγμή ή σε ένα δεδομένο περιβάλλον, μπορεί να μην δουλεύει καλά σε άλλη χρονική στιγμή ή περιβάλλον (όταν για παράδειγμα το RDBMS έχει φτάσει σε near capacity φορτία). Γι αυτό κι έγραψα ότι κάθε επιλογή έχει trade offs. Η δική μου προσέγγιση στο πρόβλημα θα ήταν να μην απαρνηθώ το ViewState (εξάλλου προσφέρει ευκολία, όπερ σημαίνει γρηγορότερη υλοποίηση, όπερ σημαίνει μικρό κόστος (ή μεγαλύτερο κέρδος - εξαρατάται την οπτική γωνία ) αλλά να βεβαιωθώ ότι κάνω σε πρώτη φάση σωστή και σε δεύτερη optimized χρήση. Κατόπιν να ελέγξω αν υπάρχουν προβλήματα στο performance και να δοκιμάσω την εναλλακτική λύση του database reload.

Ρίξε μια ματιά εδώ: http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx καθώς επίσης κι εδώ http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/viewstate.asp (αναφέρεται στο πρώτο) ιδιαίτερο ενδιαφέρον έχει το σημείο "Specifying Where to Persist the View State"

Απ: Postback databinding: Viewstate vs Database reload

Mitsaras — Sun, 24 Sep 2006 04:14:00 GMT

Μάνο, δεν στέκομαι μόνο στην αρχική σελίδα, ανέφερα το πλαίσιο ως παράδειγμα.

Αν κι εδώ πρέπει να πω ότι πιστεύω πως έχει μεγάλη σημασία, διότι αν ο μέσος χρήστης δεν έχει γρήγορη σύνδεση και το site κατέβει σε 1-2 λεπτά, δύσκολα θα έχει την υπομονή για να περιμένει.

Αυτήν την περίοδο κατασκευάζω ένα site, και θέλω να γίνει όσο το δυνατόν αποδοτικότερη η κατανάλωση των resources, οπότε προσπαθώ να δω τι κοστίζει πιο πολύ. Βέβαια, στο πρώτο μήνυμά μου δεν καθόρισα τους παράγοντες, αλλά ίσως να μπορούσαμε να ανάγουμε την ερώτηση στο αν το LOS (de)serialization του Viewstate μαζί με το κόστος μεταφοράς του από και προς τον client "στοιχίζει" περισσότερο από την λήψη των δεδομένων από τη βάση, μαζί με την μετά μετατροπή τους σε objects.

Πάντως, θέλω να κάνω και κάποια σχόλια για το πλαίσιο, και αν έχω καταλάβει κάτι λάθος, παρακαλώ διορθώστε με!

Στην αρχική σελίδα (μια και την αναφέραμε) δεν πρέπει να υπάρχουν παρά 1 ή 2 controls τα οποία κάνουν post-back (ένα self-page postback text-box για εγγραφή στο newsletter τους, και ένα για αναζήτηση, το οποίο μάλλον είναι cross-page postback).

Το δεύτερο σε πάει σε μια σελίδα, η οποία έχει ένα Viewstate μόλις 1.5KB. Τι έχει αλλάξει; Δεν υπάρχουν οι internal διαφημίσεις οι "top-web προσφορές" και οι προτάσεις της αρχικής (είναι ίσως η πιο ελαφριά σελίδα σε όλο το site, αν η αναζήτησή σου δεν έχει αποτελέσματα. Τώρα που το δοκιμάζω, αν αναζητήσω για κάτι που επιστρέφει 7 αποτελέσματα, το Viewstate αυξάνεται στα 10KB, και κάτι με 40 αποτελέσματα, εκτοξεύει το Viewstate στα 75KB!!!).

Με άλλα λόγια, όπως το βλέπω, η μόνη περίπτωση που το Viewstate έχει νόημα ως αποθήκη πληροφορίας στην πρώτη σελίδα είναι να χρησιμοποιήσει κανείς το newsletter text-box, διότι σε όλες τις άλλες περιπτώσεις, είτε δεν έχεις postback (direct-links), είτε όλα αυτά τα στοιχεία (κυρίως Datalists απ' ότι φαίνεται) δε χρειάζονται στη δεύτερη σελίδα.

Το ίδιο ισχύει και με τα αποτελέσματα της αναζήτησης, όπου δε φαίνεται να υπάρχει λόγος ύπαρξης της χρήσης του Viewstate ως αποθήκης.

Επίσης, παρατηρώ πως ορισμένα links χρησιμοποιούν μια άλλη σελίδα η οποία κάνει redirection. Δε μπορώ να φανταστώ για ποιον ακριβώς λόγο χρειάζεται αυτό το logic για εσωτερικά links, αλλά θα το αποδώσω πιθανότατα στην άγνοια των developers.

Απ: Postback databinding: Viewstate vs Database reload

KelMan — Sun, 24 Sep 2006 02:44:58 GMT

"Every decision is a trade-off"

Δεν υπάρχει ο απόλυτος κανόνας, όλα εξαρτώνται από διάφορες παραμέτρους, όπως το infrastructure που θα σου παράγει την τελική σελίδα. Πάρε για παράδειγμα το Windows Live Spaves που έχει 858Κ sites(!) Αν σχεδίαζες την αρχιτεκτονική αυτού του τέρατος, θα σε ενδιέφερε το μέγεθος της πρώτης σελίδας ως παράγοντας που επηρεάζει το scalability; Μάλλον όχι...

Postback databinding: Viewstate vs Database reload

Mitsaras — Sun, 24 Sep 2006 01:19:35 GMT

Τελικά, ποια λύση είναι προτιμότερη; Να φορτώνω τα δεδομένα που θέλω από τη βάση δεδομένων κάθε φορά, ή να τα στείλω μια και καλή στο viewstate, φουσκώνοντάς το;

Η αλήθεια είναι ότι προσωπικά, φορτώνω ορισμένα από τα δεδομένα στην cache (κυρίως αυτά που είναι μικρά σε πλήθος/όγκο ή/και δε διαφέρουν μεταξύ των sessions), τραβώντας όλα τα άλλα από την βάση, και αποφεύγω τη χρήση του Viewstate όσο το δυνατό.

Ποια είναι η άποψή σας; Είδα το καινούριο site του Πλαισίου (το οποίο ξανάγραψαν σε ASP.Net), και η αρχική σελίδα έχει ένα viewstate μεγέθους 25KB! H ASP.Net ήδη παράγει πολύ μεγαλύτερα αρχεία σε μέγεθος, σε σχέση με άλλες τεχνολογίες (κατά μέσον όρο, κυμαίνονται στα 50KB, με την αρχική του dotnetzone να φτάνει τα 130KB!!), ένα μεγάλο viewstate, μόνο χειροτερεύει την κατάσταση και επηρρεάζει σημαντικά το scalability. Είναι όμως προτιμότερο να επιβαρύνουμε τον client από το να απασχολούμε τη βάση δεδομένων;