ADO.NET

Απ: Performance Issue

rousso — Fri, 13 Jan 2006 16:19:26 GMT

Δυο μικρά σχολιάκια μια και ο Γιώργος το κάλυψε ήδη:

Το connection pooling σώζει όντως την κατάσταση με τα connections όχι μόνο σε επίπεδο χρήστη αλλά και σε επίπεδο εφαρμογής εάν τα connection string είναι ίδια σε διαφορετικά sessions (διαφορετικών χρηστών). Μην συγκρίνεις την Access με τον MS-SQL (ούτε καν με το MSDE)...
Το να βάζεις datasets στο session και το application object (εκτός από κάποιες σπάνιες ενεδεχομένως περιπτώσεις) δεν είναι και τόσο καλή ιδέα. Αν μιλάμε για performance τότε προφανώς δεν μιλάμε για κανένα μικρό dataset που είναι χρήσιμο σε όλο το session ή σε όλο το application (γιατί σε αυτή την περίπτωση το βάζεις από την αρχή στο Session ή το Application object και κάνεις την δουλειά από εκεί). Προφανώς όμως ένα ή περισσότερα datasets που αφορούν την λειτουργικότητα μιας και μόνο σελίδας δεν χρειάζονται ούτε σε όλους τους χρήστες (σε επίπεδο application δηλαδή), ούτε σε όλη την διάρκεια επαφής τους με την εφαρμογή (δηλ. όλο το session). Έτσι ναι μεν δεν θα ξαναφτιάχνεις ένα dataset σε κάθε round-trip αν το βάλεις στο Session π.χ. αλλά θα σου κοστίσει αλλού περισσότερο αργότερα, γιατί όταν δεν θα το χρειάζεσαι πια θα είναι ακόμα στην μνημη του server! Πότε θα το καθαρίσεις; Αν έχεις 100 χρήστες (πόσο μάλλον χίλιους!) τότε θα βρεθείς πολύ γρήγρα με τουλάχιστον 100 άχρηστες κόπιες του ίδιου dataset στο session object...

Σε ότι αφορά τουτς datareaders είναι μεν ταχύτεροι και προτιμότεροι από datasets όπου αυτό είναι εφικτό, αλλά προφανώς υπάρχουν πολλές περιπτώσεις που δεν είναι τόσο χρήσιμοι όσο ένα dataset...

φιλικά
rousso

Απ: Performance Issue

George J. Capnias — Fri, 13 Jan 2006 15:06:31 GMT

Η χρήση dataset δεν αλλάζει κάτι σε σχέση με την σύνδεση στον SQL Server.

Το σημείο προσοχής εδώ είναι, ότι αν επιλέξεις να δουλέψεις με dataset μέσα στις σελίδες σου, θα έχεις πολλαπλάσια διαβάσματα από την βάση, για να γεμίσει με δεδομένα το dataset κάθε φορά, που δεν θα σου είναι κάθε φορά απαραίτητα. Αποτέλεσμα θα είναι η εφαρμογή σου να γίνει πιο αργή.

Αν υποθέσουμε ότι το dataset δεν φορτώνεται για κάθε σελίδα, αλλά υπάρχει μέσα στο session ή ακόμα μέσα στο application object, θα πρέπει να προσέξεις το μέγεθός του - μπορεί να καταλήξει να έχει όλη τη βάση δεδομένων στην μνήμη τους server σου για να μπορεί να εξυπηρετήσει τους χρήστες. Βέβαια μπορεί να είναι πολύ γρήγορη η εξυπηρέτηση των χρηστών, αλλά τα server resources είναι πολύτιμα για να τα παίρνει όλα μία και μόνο εφαρμογή.

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

Ένας τρόπος να αντικαταστήσεις την χρηστικότητα και την ευκολία του dataset, είναι να φτιάξεις store procedures που θα δέχονται τα δεδομένα που χρειάζεται να γραφτούν στην βάση, και θα είναι υπεύθυνες να κάνουν πολλαπλές εγγραφές σε διάφορους πίνακες, αλλά εσύ θα περνάς τα δεδομένα προς την βάση μόνο μια φορά. Έτσι διατηρείς την ευκολία στην ανανέωση δεδομένων, αλλά αποφεύγεις το πρόβλημα που σου δημιουργούν τα datasets.

George J.

Performance Issue

Zeus — Fri, 13 Jan 2006 10:27:05 GMT

Κατ' αρχήν ευχαριστώ για την βοήθεια!
Το βασικό σενάριο είναι και select αλλά και updates, insert κλπ (στην γενική περίπτωση τουλ.)
Αυτό με το cache προσπαθώ να το κάνω και όντως βοηθά την ταχύτητα.
Τα πολλά ανοιγοκλεισίματα δεν επηρεάζουν τον Ms sql? (γιατί λχ στην access ήταν καταστροφή σχεδόν).
Επίσης, επειδή το θίξατε, μπορεί να χρησιμοποιηθεί εξίσου αποτελεσματικά το dataset αντί του datareader, διότι γενικά είναι πιο βολικό.
Ευχαριστώ, και πάλι.
Φιλικά Ζευς

Απ: Performance Issue

George J. Capnias — Fri, 13 Jan 2006 07:10:11 GMT

Είναι διάφοροι παράμετροι οι οποίοι πρέπει να λάβεις υπόψη σου.

Αν τα queries είναι action (INSERT, UPDATE, DELETE) καλό θα είναι να κλείνεις το connection όσο το δυνατόν πιο γρήγορα, μετά από κάθε query.

Αν είναι μόνο SELECT, δεν έχει μεγάλη διαφορά, καθότι αν δεν το κλείσεις και συνεχίσεις, υποτίθεται ότι κερδίζεις χρόνο. Στην πραγματικότητα, δεν λειτουργεί έτσι, γιατί ένα connection όταν κλείνει, επιστρέφει στο connection pool του SQL Server για σύντομο χρονικό διάστημα, και αν χρειαστεί μέσα σε αυτό το διάστημα ένα νέο connection, ξαναγυρνάει για χρήση της εφαρμογής που το ζήτησε.

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

Αν μιλάμε για μια ακολουθία από SELECT statements, που συνήθως συμβαίνει στα Web sites, καλό είναι να σκεφτείς την χρήση του cache.

Θα μπορούσες πχ, το result set που σου επιστρέφει ο datareader να το βάλεις στο application cache με κλειδιά, το WHERE κομμάτι του SELECT και το table ή view που αναφέρεται και να μείνει εκεί για κάποιο περιορισμένο χρόνο. Έτσι σε ένα site που έχει μεγάλη κίνηση, θα γλυτώσεις πολλά queries και να ανέβει στο κατακόρυφο η ταχύτητα που θα γίνονται render οι σελίδες...

George J.

Performance Issue

Zeus — Fri, 13 Jan 2006 04:30:12 GMT

Καλησπέρα και συγχαρητήρια στην κοινότητα αυτή για την δουλειά που κάνει!

Λοιπόν ας πούμε ότι έχουμε ένα website σε asp.net με Ms SQL! Και ας πούμε σε μια σελίδα χρειάζεται να εκτελέσεις διάφορες SQL. Η δική μου ερώτηση αφορά 2 διαφορετικά σενάρια σύνδεσης με database:

1.Ανοίγεις το connection στην αρχή της σελίδας λχ στο OnInit, εκτελεις τα queries, και κλείνεις στο Unload

2.Σε κάθε query ανοιγοκλείνεις το connection.

Έχει κάποιος ιδέα τι θα ήταν πιο αποτελεσματικό?

Φιλικά Ζευς