Πόσους ταυτόχρονους χρήστες αντέχει ένα VPS: κάντε τον υπολογισμό

Από τους χρήστες στα αιτήματα

Οι «ταυτόχρονοι χρήστες» σημαίνουν τρία διαφορετικά μεγέθη, ανάλογα με το ποιος μιλά:

• Οι εγγεγραμμένοι λογαριασμοί: δεν κοστίζουν τίποτα στον διακομιστή όσο δεν συνδέονται.
• Οι ενεργοί χρήστες την ίδια στιγμή: άτομα που περιηγούνται, διαβάζουν, συμπληρώνουν μια φόρμα. Καθένα στέλνει ένα αίτημα κατά διαστήματα, τυπικά κάθε 10 έως 30 δευτερόλεπτα, συν μερικές κλήσεις API ανά οθόνη σε μια σύγχρονη εφαρμογή.
• Τα αιτήματα σε εξέλιξη: αυτά που επεξεργάζεται ο διακομιστής σε μια δεδομένη στιγμή. Είναι το μόνο μέγεθος που καταναλώνει επεξεργαστή και μνήμη.

Περνάμε από το ένα στο άλλο με τον νόμο του Little: ο αριθμός των αιτημάτων σε εξέλιξη ισούται με τη ροή, σε αιτήματα ανά δευτερόλεπτο, πολλαπλασιασμένη με τη μέση διάρκεια ενός αιτήματος.

Παράδειγμα. 600 ενεργοί χρήστες την ίδια στιγμή, που ο καθένας στέλνει ένα αίτημα κάθε 20 δευτερόλεπτα, κάνουν 30 αιτήματα το δευτερόλεπτο. Αν κάθε αίτημα διαρκεί 100 ms, ο διακομιστής έχει κατά μέσο όρο μόλις 3 αιτήματα σε εξέλιξη. Το διακύβευμα βρίσκεται αλλού: στις αιχμές και στα αργά αιτήματα.

Τι αντέχει ένα vCPU

Ένα αίτημα απασχολεί τον επεξεργαστή όσο διαρκεί ο υπολογισμός του: εκτέλεση του κώδικα, ερώτημα στη βάση, κατασκευή της απάντησης. Ένα vCPU επεξεργάζεται λοιπόν το πολύ 1.000 ÷ t αιτήματα το δευτερόλεπτο, όπου t είναι ο χρόνος υπολογισμού ενός αιτήματος σε χιλιοστά του δευτερολέπτου. Ο χρόνος αναμονής (ένα εξωτερικό API, ένας δίσκος) δεν απασχολεί τον επεξεργαστή, απασχολεί όμως έναν worker.

Με αυτές τις τάξεις μεγέθους, 30 αιτήματα API το δευτερόλεπτο με 10 ms υπολογισμού απασχολούν το 30 % ενός μόνο vCPU. Τα ίδια 30 αιτήματα το δευτερόλεπτο σε σελίδες WordPress χωρίς cache ζητούν 3 έως 9 vCPU. Η cache σελίδων υπάρχει ακριβώς για να μεταφέρει μια σελίδα από την τέταρτη γραμμή του πίνακα στη δεύτερη.

Τι αντέχει η μνήμη

Κάθε αίτημα σε εξέλιξη το αναλαμβάνει ένας worker, και οι workers καταλαμβάνουν μνήμη, είτε δουλεύουν είτε όχι. Συχνά η μνήμη, περισσότερο από τον επεξεργαστή, καθορίζει πόσα αιτήματα επεξεργάζονται παράλληλα:

• PHP-FPM: μία διεργασία ανά αίτημα σε εξέλιξη, 40 έως 80 MB η καθεμία. Το pm.max_children ορίζει το ανώτατο όριο: 20 διεργασίες σημαίνουν 800 MB έως 1,6 GB.
• Python (Gunicorn, Uvicorn): η τεκμηρίωση του Gunicorn προτείνει να ξεκινήσετε από (2 × αριθμός πυρήνων) + 1 workers, των 80 έως 200 MB ο καθένας. Ένας ασύγχρονος worker κρατά πολλά αιτήματα σε αναμονή με το κόστος μίας μόνο διεργασίας.
• Node.js: μία μόνο διεργασία κρατά χιλιάδες συνδέσεις σε αναμονή, αλλά χρησιμοποιεί μόνο έναν πυρήνα. Η λειτουργία cluster, ή το PM2, ξεκινά μία διεργασία ανά vCPU.
• Η βάση δεδομένων: η PostgreSQL ανοίγει μία διεργασία ανά σύνδεση και δέχεται εξ ορισμού 100. Πέρα από μερικές δεκάδες ενεργές συνδέσεις, ένα εργαλείο συγκέντρωσης συνδέσεων όπως το PgBouncer είναι προτιμότερο από την αύξηση του max_connections.

Οι μόνιμες συνδέσεις (websockets, ειδοποιήσεις σε πραγματικό χρόνο) μετρούν χωριστά: ανοιχτές διαρκώς, καταναλώνουν λίγο επεξεργαστή και μερικές δεκάδες kilobyte μνήμης η καθεμία. Ένας διακομιστής Node.js κρατά χιλιάδες από αυτές σε μερικές εκατοντάδες MB.

Τα πραγματικά σημεία συμφόρησης

Σε μια πραγματική εφαρμογή, ο διακομιστής σπάνια φτάνει στον κορεσμό εκεί που το περιμένει κανείς. Οι πιο συχνές αιτίες, με τη σειρά που αξίζει να τις αναζητήσετε:

1. Ένα αργό ερώτημα SQL: ένα ευρετήριο που λείπει μετατρέπει ένα ερώτημα 2 ms σε ερώτημα 2 δευτερολέπτων, που δεσμεύει έναν worker και μια σύνδεση. Το pg_stat_statements στην PostgreSQL, ή το αρχείο αργών ερωτημάτων της MySQL, το εντοπίζει.
2. Τα ερωτήματα σε αλυσίδα (το πρόβλημα N+1): μια σελίδα που στέλνει ένα ερώτημα για κάθε γραμμή που εμφανίζει στέλνει εκατοντάδες.
3. Μια σύγχρονη εξωτερική κλήση: ένα API πληρωμών ή AI που απαντά σε 3 δευτερόλεπτα μπλοκάρει έναν σύγχρονο worker για 3 δευτερόλεπτα.
4. Βαριές επεξεργασίες μέσα στο αίτημα: αποστολή email, αλλαγή μεγέθους εικόνων, δημιουργία PDF, που αξίζει να μεταφερθούν σε μια ουρά εργασιών.
5. Η απουσία cache: οι σελίδες που είναι ίδιες για όλους τους επισκέπτες εξυπηρετούνται από cache, και τα στατικά αρχεία από τον διακομιστή web.

Η επαλήθευση: η δοκιμή φορτίου

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

wrk -t2 -c50 -d30s --latency https://preprod.i-istoselida-sas.com/

Για μια πλήρη διαδρομή (σύνδεση, περιήγηση, αναζήτηση), το k6 περιγράφει ένα σενάριο σε JavaScript και ανεβάζει το φορτίο σταδιακά:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 300 },
    { duration: '5m', target: 300 },
    { duration: '2m', target: 0 },
  ],
  thresholds: { http_req_duration: ['p(95)<500'] },
};

export default function () {
  http.get('https://preprod.i-istoselida-sas.com/');
  sleep(15);
}

• Δοκιμάστε ένα αντίγραφο, όχι την παραγωγή, και ενημερώστε τον πάροχο φιλοξενίας σας αν η δοκιμή στοχεύει έναν διακομιστή που λειτουργεί εκείνος.
• Εκτελέστε τη δοκιμή από άλλο μηχάνημα από τον διακομιστή που δοκιμάζετε, αλλιώς το εργαλείο του αφαιρεί τους δικούς του πόρους.
• Κοιτάξτε το 95^ο εκατοστημόριο του χρόνου απόκρισης, όχι τον μέσο όρο: αυτό ζουν οι χρήστες σας που εξυπηρετούνται χειρότερα.
• Παρακολουθήστε τον διακομιστή κατά τη δοκιμή: htop για τον επεξεργαστή, free -h για τη μνήμη, τα αρχεία καταγραφής για τα σφάλματα.

Όταν το φορτίο μεγαλώνει

Η σειρά που κοστίζει λιγότερο και αποδίδει περισσότερο:

1. Βάλτε σε cache ό,τι μπορεί να μπει (σελίδες, τμήματα σελίδων, αποτελέσματα ερωτημάτων) και διορθώστε τα αργά ερωτήματα.
2. Ρυθμίστε τον αριθμό των workers ανάλογα με τη διαθέσιμη μνήμη και τον επεξεργαστή.
3. Περάστε σε μεγαλύτερο μέγεθος: περισσότερα vCPU και περισσότερη μνήμη, χωρίς καμία αλλαγή στην εφαρμογή.
4. Μεταφέρετε τη βάση δεδομένων στον δικό της διακομιστή.
5. Κατανείμετε την εφαρμογή σε πολλούς διακομιστές πίσω από έναν εξισορροπητή φορτίου (load balancer).

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