Εντελώς εμπειρικά βλέπω ότι τα stored procedures εκτελούνται ποιό αργα από τον SQL Server και δημιουργούν μεγαλύτερο φόρτο από ότι να στείλεις τα ίδια τα SQL statements στην βάση....

Τι θέλω να πώ ..Πρόσφατα ανέλαβα ένα εργό σύντηρησης μιας εφαρμογής. Κάποια κομμάτια της είναι φτιαγμένα μέσα σε stored procedures και είναι ουσιαστικά απλά Select queries. Δεν έχει άλλο ουσιαστικό κώδικα T-SQL.


Εκοψα λοιπόν τα "προβληματικά stored proceudres" και έβαλα τα ερωτήματα αυτά μέσα στην εφαμρογή και τρέχουν πολύ ταχύτερα....Βέβαια δεν είναι σφαίρα αλλά εχω δεί σημαντική διαφορά !! Γιατί ..? Δαηλαδή αυτό που κέρδισα είναι να μην ψάχνει να βρεί τον κώδικα στα system tables....?

Ουπς! Πρόσεχε γιατί θα πλακώσει ο Καναβός με δεκάδες ερωτήσεις και επιχειρήματα :)

Γενικά τα stored procedures εκπληρώνουν τον αντίθετο ακριβώς σκοπό. Δηλαδή, κάνουν τα πράγματα να τρέχουν (για διάφορους λόγους) πιό γρήγορα. Και εδώ είμαι αναγκασμένος να σε ρωτήσω: Πώς εννοείς το "εμπειρικά"; Με βάση ποιά metrics διαπίστωσες οτι τα SPs δεν είναι εξίσου αποτελεσματικά με τα χύμα SQL Statements; Εννοώ, είδες την εφαρμογή σε high-load (έστω και simulated) καταστάσεις; Εκανες σύγκριση κάποιων χρόνων εκτέλεσης;

Γενικά, τα stored procedures (όχι στη δική σου περίπτωση οπου περιέχουν απλά - και λιτά ίσως - select statements) αλλά σε περιπτώσεις π.χ. οπου κάποιος στέλνει σεντόνια κώδικα στη βάση βοηθούν καταρχήν στη μείωση του network traffic. Μπορεί να ακούγεται αστείο αλλά για σκέψου μια εφαρμογή που στέλνει στον SQL Server πεντε-εξι σελίδες SQL με κάθε query και αυτό σε ένα σύστημα που έχει π.χ. 1000 ενεργούς χρήστες οπου για κάθε ενέργειά τους απαιτούνται 3-4 τέτοια τη φορά... το όνομα του stored procedure είναι γενικά λιγότερο από ολόκληρο τον κώδικα :)

Επίσης ένα άλλο καλό (εκτός αν χρησιμοποιούν dynamic sql) είναι οτι στα stored procedures ο κώδικας είναι σταθερός. Ο SQL Server τον ξέρει εκ των προτέρων και έτσι μπορεί να κάνει cache ένα πραγματάκι που λέγεται execution plan και να το χρησιμοποιήσει χωρίς να αναγκάζεται να το ξαναδημιουργήσει κάθε φορά που του έρχεται ένα query-σεντόνι.

Τώρα, υπάρχουν και περιπτώσεις που τα πράγματα λειτουργούν αντίστροφα. Ας πούμε, αν τα stored procedures είναι κακογραμμένα, τότε προφανώς και δεν θα έχουν την αποτελεσματικότητα που κάποιος θα περίμενε. Ομως εσύ είδες διαφορά χρησιμοποιώντας embedded στην εφαρμογή σου ΤΗΝ ΙΔΙΑ ακριβώς SQL; Αυτό μου φαίνεται λίγο περίεργο. Μήπως η ταχύτερη εκτέλεση οφείλεται σε κάποιο άλλο παράγοντα που άλλαξε ταυτόχρονα;

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Αν έτρεξες τις ΙΔΙΕΣ ακριβώς SQL statements στον κώδικα και τις χρονο-μέτρησες και ήτανε πιο γρήγορες από τις stored procedure τότε μάλλον το πρόβλημα βρίσκεται στο.... ρολόι σου!!!

Σοβαρά τώρα!!!
Πρέπει να προσέξεις βασικά τα εξής όταν μετράς χρόνους:
1. Το cashing του SQL Server
2. Το trafic στο Δίκτυο.

Προτείνω:
1. Να κάνεις τον έλεγχο μέσα από τον profiler.
2. Να ρίξεις μια ματιά στις παρακάτω εντολές:

SET STATISTICS IO off
SET STATISTICS TIME Off
DBCC DROPCLEANBUFFERS -- to clear the buffers
SET STATISTICS IO on
SET STATISTICS TIME On
--> Τρέχω εδώ αυτό που θέλωωωωωωωωωωω!!!

---

Nothing to declare...

Thiseas, δεν έχεις δίκιο σ'αυτά τα οποία γράφεις. Πρώτον το caching του SQL Server "σπάει" σε δύο διαφορετικά. Στο procedure cache και στο data cache. Για να έχεις σωστά αποτελέσματα, θα πρέπει να αδειάσεις και το procedure cache με "DBCC FREEPROCCACHE".

To traffic στο δίκτυο δεν παίζει σχεδόν κανένα ρόλο, εκτός εάν είναι στο παρα πέντε να μπουκώσει. Εάν ο Server που τρέχει έχει να δώσει "γκάζι", τότε θα παίξει μια χαρά.

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Πως δεν παίζει ρόλο το traffic! Για δες τι συμβαινει σε περίπτωση που ο SQL Server είναι σε άλλο δίκτυο (οχι στο LAN μας) και τον χτυπάς μέσω IP...ειδικά αν είναι σε κάτι 256άρες μισθωμένες. :)

Για το caching δεν έχω άποψη.

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

@Thiseas:Νομίζω ότι είμουν ξεκάθαρος σε αυτό που έιπα. Τα stored procedures είχαν μέσα απλά select queries. Και δεν το χρονομέτρησα όπως λες με ρολόι. αλλά με κώδικα. και μην με ρωτήσεις πως το εκανα....εκτός και αν το πάμε ότι ο υπολογιστής δεν κάνει σωστές πράξεις !!!!

Στην αρχή νόμιζα ότι εφταιγε ο SQL Server και κάτι δεν το πήγαινε καλά....Οταν η συγκεκριμένη έκδοση έγινε εγκατάσταση και σε άλλο δίκτυο με άλλο SQL Server με βάση ίδιας δομής αλλά δεδομένα σαφώς είχε την ίδια σμπεριφορά...

Μάλιστα δε με την έκδοση που καλούσε την διαδικασία αυτή όταν αργούσε υπερβολικά να να τελειώσει έβγαζαν οι άλλοι σταθμοί Timed Out.

Το δίκτιο για το οποίο μιλάω χςρίζεται σε 3 μέρη αρα έχει servers με 70 σταθμούς ο κάθενας γύρω του...

Οτι είπαν ο cap και ο Παναγιώτης τα ξέρω ήδη..Τώρα θέμα κακογραμένου δεν μπορώ να πώ ότι τίθεται γιατί πόσο κακογραμένη μπορεί να είναι μια διαδικασία που περιέχει ένα ερώτημα με 3 πίνακες .? το οποίο μάλιστα να πάιζει καλύτερα όταν το κάνεις paste οπως είναι μέσα σε μια εφαρμογή

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

Θα μπορούσες να δοκιμάσεις να περάσεις τα δύο σενάρια από ένα stress testing με κάποιον τρόπο; Πολλές φορές εκτέλεση των ίδιων queries (εν ανάγκη μέσα από query analyzer) και αντίστοιχα των stored procedures και χρονομέτρηση αυτών και να μας πεις τα αποτελέσματα; Πάντως μου φαίνεται πολύ περίεργο και δεν μου βγαίνει από το μυαλό οτι κάτι άλλο ευθύνεται για τις διαφορές στις επιδόσεις...

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

cap:

Πως δεν παίζει ρόλο το traffic! Για δες τι συμβαινει σε περίπτωση που ο SQL Server είναι σε άλλο δίκτυο (οχι στο LAN μας) και τον χτυπάς μέσω IP...ειδικά αν είναι σε κάτι 256άρες μισθωμένες. :)

Για το caching δεν έχω άποψη.

 

Το ίδιο με εμένα λες.. Όταν η γραμμή είνια μπουκωμένη, παίζει ρόλο.. Άλλο να έχω High traffic κι άλλο μπουκωμένη γραμμή. Δηλαδή άλλο να έχω 30 άτομα τα οποιά χτυπάνε ένα server καταλαμβάνοντας 194kbps απο μια 256 kbps γραμμή, κι άλλο να έχω 50 άτομα κι να καταλαμβάνουν 155kbps γιατί έχουν διαφορετικά queries πχ.. Έτσι έχω μεγάλο traffic (50 άτομα) αλλά δεν έχω μεγάλο Latency, καθώς η γραμμή έχει γκάζι να δώσει.

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Guys... το network-traffic είναι από τα μεγαλύτερα bottle-necks στο performance.... όσοι έχουν δουλέψει σε VPNs ή/και Remote Desktops θα με καταλάβουνε.

Τώρα για το DBCC FREEPROCCACHE που ανέφερε ο φίλτατος Παναγιώτης... ναί έχει δίκιο, χρειάζεται οποσδήποτε κι αυτό!!!



Κατά τα άλλα είμαι σίγουρος οτι το πρόβλημα είναι αλλού... αν και θα επιμείνω στον φίλο Vader να κοιτάξει τις τιμές του SQL Profiler!

---

Nothing to declare...

Κάποια στιγμή θα κάνω μες την εβδομάδα .....και θα τα πούμε ....

Αν και μπήκα λίγο αργά στην κουβέντα (που θα πάει, θα μου έρθει το ριμάδι το DSL) θα ήθελα να επισημάνω το εξής:

Σε παλιότερες version του SQL Server οι stored procedures είχαν "ειδική" μεταχείριση από τον server για λόγους performance σε σχέση με τα queries. Υπήρχε ένας caching μηχανισμός ο οποίος δεν υπήρχε για τα ad-hoc queries. Από τον SQL Server 7 αυτός ο μηχανισμός ισχύει και για τα queries. Στα books on line του SQL Server 7 και 2000 λέει:

SQL Server 2000 and SQL Server 7.0 do not save a partially compiled plan for stored procedures when they are created. A stored procedure is compiled at execution time, like any other Transact-SQL statement. SQL Server 2000 and SQL Server 7.0 retain execution plans for all SQL statements in the procedure cache, not just stored procedure execution plans.

Και όμως, ο κόσμος συνεχίζει να πιστεύει από τότε ότι υπάρχει (πάντα μιλάμε ως προς το performance) διαφορά, υπέρ των SP. Πρακτικά, ΔΕΝ υπάρχει. Αν μια λύση αποδίδει καλύτερα με τον έναν ή τον άλλον τρόπο, θα πρέπει να αναζητηθούν αλλού τα αίτια.

Πάντως, οι stored procedures δεν παύουν να είναι χρήσιμες καθώς προσφέρουν άλλο ένα αφαιρετικό επίπεδο. Επίσης, είναι και αυτό που είπε ο Σωτήρης. Εξαρτάται παντότε από το τι θέλουμε να κάνουμε. You win some, you loose some. To debate SPs vs queries τρέχει εδώ και αρκετό καιρό...

---

Vir prudens non contra ventum mingit

Να πω και εγώ τη γνώμη μου για αυτό το debate.
Εγώ σαν Oracle developer δουλεύω πάρα πολύ με stored procedures. Με την ενασχόληση μου με τον ado.net μηχανισμό είδα ότι πλέον υπάρχει και άλλος δρόμος. Και ενώ περίμενα ότι θα είχα χαμηλή απόδοση στην ταχύτητα με τα queries διαπίστωσα ότι κάτι τέτοιο δεν συμβαίνει.
Το τι θα διαλέξει ο developer είναι καθαρά θέμα δικής του οπτικής, προτίμησης, εμπειρίας, συνήθειας, παραξενιάς κ.λ.π. Δεν υπάρχει κατά τη γνώμη μου καθαρή υπεροχή της μίας ή της άλλης πλευράς.
Εγώ επειδή χρησιμοποιώ πολύ τους Triggers, χρησιμοποιώ πολύ και stored procedures για να είναι πιο ευανάγνωστος ο κώδικας μέσα στους triggers.


 

---

Manos

KelMan:

Και όμως, ο κόσμος συνεχίζει να πιστεύει από τότε ότι υπάρχει (πάντα μιλάμε ως προς το performance) διαφορά, υπέρ των SP. Πρακτικά, ΔΕΝ υπάρχει.

+1000. Δεν το είχα αντιληφθεί. Πρακτικά λοιπόν μας μένει μονο το θέμα του network traffic σε high-stress καταστάσεις και τίποτα άλλο σε σχέση με τις επιδόσεις.

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Vader:

.... βλέπω ότι τα stored procedures εκτελούνται ποιό αργα από τον SQL Server και δημιουργούν μεγαλύτερο φόρτο από ότι να στείλεις τα ίδια τα SQL statements στην βάση....

Να υπενθυμίσω οτι το "DebAte" ξεκίνησε από αυτήν την διαπίστωση...

---

Nothing to declare...

Ναι, έχεις δίκιο. Θα πρέπει λοιπόν να περιμένουμε το συνάδελφο να κάνει τις σχετικές μετρήσεις για να δούμε αν όντως (και ίσως και για ποιό λόγο) συμβαινει αυτό, που πρακτικά δεν θα έπρεπε να συμβαίνει (σύμφωνα και με τα όσα είπε ο Μάνος, θα έπρεπε το πολύ πολύ να είχαμε ίδιο performance).

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services