Αργό website, αδρανής server: πού πάει ο χρόνος

Γιατί η βάση δεδομένων είναι ο συνήθης ύποπτος

Όταν μια σελίδα γίνεται αργή, η βάση δεδομένων είναι το σημείο όπου το σύμπτωμα γίνεται πρώτα ορατό. Οι συνδέσεις στοιβάζονται, η λίστα διεργασιών γεμίζει με queries σε κατάσταση sending data, και το slow query log αρχίζει να μεγαλώνει. Όλα αυτά είναι αληθινά, και κανένα δεν λέει πού πήγε ο χρόνος. Η βάση βρίσκεται στο τέλος των περισσότερων διαδρομών αιτήματος. Μια σελίδα που την καλεί διακόσιες φορές αντί για δύο, ένας worker που κρατά μια σύνδεση ανοιχτή όσο περιμένει ένα payment gateway, ένα cache που παρακάμπτεται σε κάθε hit: καθένα από αυτά εμφανίζεται ως φορτίο βάσης, γιατί η βάση κάνει ακριβώς αυτό που της ζητείται, πιο συχνά από όσο θα έπρεπε να της ζητείται.

Το ίδιο ισχύει για τον server. Ένα μηχάνημα με υψηλό load είναι ένα μηχάνημα στο οποίο δίνεται δουλειά. Αν η δουλειά είναι αναγκαία, είναι ερώτηση που το γράφημα του load δεν μπορεί να απαντήσει.

Ιχνηλατήστε ένα αίτημα, όχι ολόκληρο το site

Η μέθοδος είναι να διαλέξετε ένα αργό URL και να το ακολουθήσετε μέσα από τα επίπεδα, μετρώντας σε κάθε όριο. Ξεκινήστε από έξω, από ένα μηχάνημα που δεν βρίσκεται στο ίδιο δίκτυο, και αφήστε το curl να αναφέρει πού πάει ο χρόνος πριν φτάσει το πρώτο byte.

$ curl -o /dev/null -s -w 'dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n' https://www.example.com/slow-page

Αν ο χρόνος μέχρι το πρώτο byte είναι το μεγαλύτερο μέρος του συνόλου, η αναμονή είναι στην πλευρά του server. Αν το σύνολο είναι πολύ μεγαλύτερο από τον χρόνο μέχρι το πρώτο byte, η σελίδα είναι βαριά ή η διαδρομή ανάμεσα στον επισκέπτη και το edge είναι η ιστορία, και ο server δεν συμμετείχε στην αναμονή.

Στο μηχάνημα, δειγματίστε τη CPU όσο το αργό αίτημα είναι σε εξέλιξη, όχι μια αδρανή ώρα αργότερα.

$ mpstat -P ALL 1 5
$ vmstat 1 5

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

Έπειτα η εφαρμογή. Τα περισσότερα frameworks μπορούν να καταγράψουν, ανά αίτημα, τον αριθμό των queries που εκδόθηκαν, τον συνολικό χρόνο που ξοδεύτηκε σε αυτά, και τον χρόνο που ξοδεύτηκε σε εξερχόμενες κλήσεις HTTP. Ενεργοποιήστε το για το αργό URL. Δύο αριθμοί κλείνουν τη συζήτηση: πόσα queries εκδίδει μία σελίδα, και πόσος από τον χρόνο ρολογιού ξοδεύτηκε εντελώς έξω από την εφαρμογή.

Τέλος η βάση δεδομένων, με το slow query log ενεργό και το κατώφλι αρκετά χαμηλό ώστε να πιάνει ό,τι μετράει.

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.2;
SET GLOBAL log_queries_not_using_indexes = ON;

Διαβάστε το log για το παράθυρο του αργού αιτήματος. Μια χούφτα queries που παίρνουν δευτερόλεπτα το καθένα είναι πρόβλημα βάσης. Χιλιάδες queries που παίρνουν ένα χιλιοστό του δευτερολέπτου το καθένα είναι πρόβλημα εφαρμογής για το οποίο κατηγορείται η βάση.

Τα μοτίβα που βγαίνουν από τη μέτρηση

Με τα επίπεδα χωρισμένα, η αιτία παίρνει συνήθως ένα από λίγα σχήματα.

Ένα endpoint που καλείται σε βρόχο. Ένα front end που ξαναζητά τον ίδιο πόρο σε κάθε αλλαγή κατάστασης, ή μια σελίδα που εκδίδει ένα query ανά γραμμή αντί για ένα query ανά σελίδα. Η βάση απαντά σε κάθε κλήση γρήγορα. Ο αριθμός τους είναι το πρόβλημα.

Μια σύγχρονη κλήση σε κάποιον άλλο. Ένας πάροχος πληρωμών, ένα ERP, ένα API αποστολών, ένας tag manager, που κάθονται στη διαδρομή του αιτήματος πίσω από ένα μακρύ timeout. Ο server είναι αδρανής για όλη την αναμονή, και η σελίδα είναι τόσο αργή όσο το πιο αργό τρίτο μέρος από το οποίο εξαρτάται.

Ένα cache που ακυρώνεται. Headers που απαγορεύουν το caching σε σελίδες που δεν αλλάζουν, ή καθόλου edge cache μπροστά από ανώνυμη κίνηση που ποτέ δεν ήταν δυναμική.

Pools διαστασιολογημένα στην τύχη. Pools για workers, συνδέσεις και buffers ρυθμισμένα πολύ μεγάλα εξίσου συχνά όσο και πολύ μικρά. Ένα pool πολύ μεγαλύτερο από όσο μπορεί να εξυπηρετήσει ταυτόχρονα το μηχάνημα μετατρέπει μια ουρά σε thrash.

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

Τι αλλάζει ένας μεγαλύτερος server

Η προσθήκη πυρήνων ή μνήμης συντομεύει το κομμάτι του αιτήματος που υπολόγιζε. Αν αυτό το κομμάτι ήταν ήδη μικρό, η σελίδα δεν γίνεται πιο γρήγορη. Η αναμονή μετακομίζει μαζί της. Ο βρόχος συνεχίζει να γυρίζει, το τρίτο μέρος συνεχίζει να παίρνει τον χρόνο του, το cache συνεχίζει να παρακάμπτεται. Η αναβάθμιση κρύβει και τη μέτρηση που θα είχε βρει την αιτία, γιατί το γράφημα που ήταν κόκκινο είναι τώρα πορτοκαλί, και το ticket κλείνει.

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