Μιλήσαμε για τη μεθοδολογία στο άρθρο, σε αυτό δοκιμάζουμε το HTTPS, αλλά σε πιο ρεαλιστικά σενάρια. Για δοκιμή, αποκτήσαμε ένα πιστοποιητικό Let's Encrypt και ενεργοποιήσαμε τη συμπίεση Brotli στο 11.
Αυτή τη φορά θα προσπαθήσουμε να αναπαράγουμε το σενάριο ανάπτυξης διακομιστή σε VDS ή ως εικονική μηχανή σε κεντρικό υπολογιστή με τυπικό επεξεργαστή. Για το σκοπό αυτό, ορίστηκε όριο:
- 25% - που ισοδυναμεί με συχνότητα ~ 1350 MHz
- 35% -1890 MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Ο αριθμός των εφάπαξ συνδέσεων μειώθηκε από 500 σε 1, 3, 5, 7 και 9,
Αποτελέσματα:
Καθυστερήσεις:
Το TTFB συμπεριλήφθηκε ειδικά ως ξεχωριστή δοκιμή, επειδή το HTTPD Tools δημιουργεί έναν νέο χρήστη για κάθε μεμονωμένο αίτημα. Αυτή η δοκιμή εξακολουθεί να είναι αρκετά αποκομμένη από την πραγματικότητα, επειδή ο χρήστης θα εξακολουθεί να κάνει κλικ σε μερικές σελίδες και στην πραγματικότητα το TTFP θα παίζει τον κύριο ρόλο.
Το πρώτο, γενικά το πρώτο αίτημα μετά την πρώτη εκκίνηση της εικονικής μηχανής IIS διαρκεί κατά μέσο όρο 120 ms.
Όλα τα επόμενα αιτήματα εμφανίζουν TTFP 1.5 ms. Οι Apache και Nginx υστερούν σε αυτό το θέμα. Προσωπικά, ο συγγραφέας θεωρεί αυτό το τεστ το πιο αποκαλυπτικό και θα επέλεγε τον νικητή μόνο με βάση αυτό.
Το αποτέλεσμα δεν προκαλεί έκπληξη, καθώς οι υπηρεσίες IIS αποθηκεύουν προσωρινά το ήδη συμπιεσμένο στατικό περιεχόμενο και δεν το συμπιέζει κάθε φορά που γίνεται πρόσβαση σε αυτό.
Χρόνος που δαπανάται ανά πελάτη
Για την αξιολόγηση της απόδοσης, αρκεί μια δοκιμή με 1 απλή σύνδεση.
Για παράδειγμα, η IIS ολοκλήρωσε μια δοκιμή 5000 χρηστών σε 40 δευτερόλεπτα, δηλαδή 123 αιτήματα ανά δευτερόλεπτο.
Τα παρακάτω γραφήματα δείχνουν το χρόνο μέχρι την πλήρη μεταφορά του περιεχομένου του ιστότοπου. Αυτό είναι το ποσοστό των αιτημάτων που ολοκληρώθηκαν σε μια δεδομένη χρονική στιγμή. Στην περίπτωσή μας, το 80% όλων των αιτημάτων υποβλήθηκε σε επεξεργασία σε 8 ms σε IIS και σε 4.5 ms σε Apache και Nginx, και το 8% όλων των αιτημάτων σε Apache και Nginx ολοκληρώθηκαν σε διάστημα έως και 98 χιλιοστών του δευτερολέπτου.
Χρόνος κατά τον οποίο διεκπεραιώθηκαν 5000 αιτήματα:
Χρόνος κατά τον οποίο διεκπεραιώθηκαν 5000 αιτήματα:
Εάν έχετε μια εικονική μηχανή με CPU 3.5 GHz και 8 πυρήνες, τότε επιλέξτε αυτό που θέλετε. Όλοι οι διακομιστές ιστού είναι πολύ παρόμοιοι σε αυτήν τη δοκιμή. Θα μιλήσουμε για τον διακομιστή ιστού που θα επιλέξετε για κάθε κεντρικό υπολογιστή παρακάτω.
Όταν πρόκειται για μια ελαφρώς πιο ρεαλιστική κατάσταση, όλοι οι διακομιστές ιστού πηγαίνουν αντιμέτωποι.
Διακίνηση:
Γράφημα καθυστερήσεων σε σχέση με τον αριθμό των ταυτόχρονων συνδέσεων. Ομαλά και χαμηλότερα είναι καλύτερα. Το τελευταίο 2% αφαιρέθηκε από τα γραφήματα επειδή θα τα καθιστούσε δυσανάγνωστα.
Ας εξετάσουμε τώρα την επιλογή όπου ο διακομιστής φιλοξενείται σε εικονική φιλοξενία. Ας πάρουμε 4 πυρήνες στα 2.2 GHz και έναν πυρήνα στα 1.8 GHz.
Πώς να κλιμακώσετε
Αν έχετε δει ποτέ πώς μοιάζουν τα χαρακτηριστικά τάσης ρεύματος των τριοδίων κενού, των πεντόδων και ούτω καθεξής, αυτά τα γραφήματα θα σας είναι γνωστά. Αυτό προσπαθούμε να πιάσουμε - κορεσμός. Το όριο είναι όταν όσους πυρήνες και να πετάξεις, η αύξηση της απόδοσης δεν θα είναι αισθητή.
Προηγουμένως, η όλη πρόκληση ήταν να επεξεργαστούμε το 98% των αιτημάτων με τη χαμηλότερη καθυστέρηση για όλα τα αιτήματα, διατηρώντας την καμπύλη όσο το δυνατόν πιο επίπεδη. Τώρα, κατασκευάζοντας μια άλλη καμπύλη, θα βρούμε το βέλτιστο σημείο λειτουργίας για κάθε έναν από τους διακομιστές.
Για να το κάνουμε αυτό, ας πάρουμε την ένδειξη Αιτήματα ανά δευτερόλεπτο (RPR). Οριζόντια είναι η συχνότητα, κάθετη είναι ο αριθμός των αιτημάτων που υποβάλλονται σε επεξεργασία ανά δευτερόλεπτο, γραμμές είναι ο αριθμός των πυρήνων.
Δείχνει έναν συσχετισμό του πόσο καλά επεξεργάζεται τα αιτήματα το Nginx το ένα μετά το άλλο. 8 πυρήνες αποδίδουν καλύτερα σε αυτή τη δοκιμή.
Αυτό το γράφημα δείχνει ξεκάθαρα πόσο καλύτερα (όχι πολύ) λειτουργεί το Nginx σε έναν μόνο πυρήνα. Εάν έχετε Nginx, θα πρέπει να εξετάσετε το ενδεχόμενο να μειώσετε τον αριθμό των πυρήνων σε έναν εάν φιλοξενείτε μόνο στατικούς.
Η IIS, αν και έχει το χαμηλότερο TTFB σύμφωνα με το DevTools στον Chrome, καταφέρνει να χάσει τόσο από το Nginx όσο και από τον Apache σε μια σοβαρή μάχη με το stress test από το Apache Foundation.
Όλη η καμπυλότητα των γραφημάτων αναπαράγεται με επένδυση σιδήρου.
Κάποιο συμπέρασμα:
Ναι, το Apache λειτουργεί χειρότερα σε 1 και 8 πυρήνες, αλλά λειτουργεί λίγο καλύτερα σε 4.
Ναι, το Nginx σε 8 πυρήνες επεξεργάζεται τα αιτήματα καλύτερα το ένα μετά το άλλο, σε 1 και 4 πυρήνες και λειτουργεί χειρότερα όταν υπάρχουν πολλές συνδέσεις.
Ναι, το IIS προτιμά 4 πυρήνες για φόρτους εργασίας πολλαπλών νημάτων και προτιμά 8 πυρήνες για φόρτους εργασίας ενός νήματος. Τελικά, το IIS ήταν ελαφρώς ταχύτερο από όλους τους άλλους σε 8 πυρήνες υπό υψηλό φορτίο, αν και όλοι οι διακομιστές ήταν ίσοι.
Αυτό δεν είναι σφάλμα μέτρησης, το σφάλμα εδώ δεν είναι μεγαλύτερο από +-1ms. σε καθυστερήσεις και όχι περισσότερες από +- 2-3 αιτήματα ανά δευτερόλεπτο για RPR.
Τα αποτελέσματα όπου 8 πυρήνες αποδίδουν χειρότερα δεν είναι καθόλου εκπληκτικά, πολλοί πυρήνες και το SMT/Hyperthreading υποβαθμίζουν σημαντικά την απόδοση εάν έχουμε ένα χρονικό πλαίσιο στο οποίο πρέπει να ολοκληρώσουμε ολόκληρο τον αγωγό.
Πηγή: www.habr.com