Колко едновременни потребители издържа един VPS: да направим сметката

От потребители към заявки

„Едновременни потребители“ означава три различни величини в зависимост от това кой говори:

• Регистрираните акаунти: не струват нищо на сървъра, докато не влязат.
• Потребителите, активни по едно и също време: хора, които разглеждат, четат, попълват формуляр. Всеки от тях изпраща заявка от време на време, обикновено на всеки 10 до 30 секунди, плюс няколко API извиквания на екран в едно съвременно приложение.
• Заявките в обработка: тези, които сървърът изчислява в даден момент. Това е единствената величина, която консумира процесор и памет.

От едната величина към другата се преминава чрез закона на Литъл: броят на заявките в обработка е равен на пропускателната способност, в заявки в секунда, умножена по средната продължителност на една заявка.

Пример. 600 потребители, активни едновременно, всеки от които задейства заявка на всеки 20 секунди, правят 30 заявки в секунда. Ако всяка заявка трае 100 ms, сървърът има средно само 3 заявки в обработка. Предизвикателството е другаде: в пиковете и в бавните заявки.

Колко издържа един vCPU

Една заявка заема процесора, докато трае изчислението ѝ: изпълнение на кода, заявки към базата, изграждане на отговора. Затова един vCPU обработва най-много 1 000 ÷ t заявки в секунда, където t е времето за изчисление на една заявка в милисекунди. Времето, прекарано в чакане (на външно API, на диска), не заема процесора, но заема worker.

С тези порядъци 30 API заявки в секунда при 10 ms изчисление заемат 30 % от един-единствен vCPU. Същите 30 заявки в секунда към WordPress страници без кеш изискват 3 до 9 vCPU. Кешът на страниците служи точно за това: да премести една страница от четвъртия ред на таблицата към втория.

Колко издържа паметта

Всяка заявка в обработка се поема от worker, а worker процесите заемат памет, независимо дали работят или не. Често паметта, повече от процесора, определя броя на заявките, обработвани паралелно:

• PHP-FPM: по един процес на заявка в обработка, по 40 до 80 MB всеки. pm.max_children задава тавана: 20 процеса заемат от 800 MB до 1,6 GB.
• Python (Gunicorn, Uvicorn): документацията на Gunicorn предлага да се започне от (2 × брой ядра) + 1 worker процеса, по 80 до 200 MB всеки. Асинхронният worker държи много заявки в изчакване на цената на един-единствен процес.
• Node.js: един процес държи хиляди връзки в изчакване, но използва само едно ядро; cluster режимът или PM2 стартира по един процес на vCPU.
• Базата данни: PostgreSQL отваря по един процес на връзка и приема 100 по подразбиране. Над няколко десетки активни връзки инструмент за споделяне на връзки като PgBouncer е по-доброто решение от увеличаването на max_connections.

Постоянните връзки (websockets, известия в реално време) се броят отделно: отворени непрекъснато, те заемат малко процесор и по няколко десетки килобайта памет всяка. Един Node.js сървър държи хиляди от тях в няколкостотин MB.

Истинските тесни места

В реално приложение сървърът рядко се насища там, където го очаквате. Най-честите причини, в реда, в който да ги търсите:

1. Бавна SQL заявка: липсващ индекс превръща заявка от 2 ms в заявка от 2 секунди, която задържа worker и връзка. pg_stat_statements в PostgreSQL или журналът на бавните заявки в MySQL я посочва.
2. Каскадните заявки (проблемът N+1): страница, която изпраща по една заявка за всеки показан ред, изпраща стотици.
3. Синхронно външно извикване: API за плащания или за AI, което отговаря за 3 секунди, блокира синхронен worker за 3 секунди.
4. Тежки обработки в самата заявка: изпращане на имейли, преоразмеряване на изображения, генериране на PDF, които е по-добре да преместите в опашка от задачи.
5. Липсата на кеш: страниците, еднакви за всички посетители, се обслужват от кеш, а статичните файлове от уеб сървъра.

Проверката: тестът за натоварване

Порядъците дават първоначален размер; тестът за натоварване дава истинския. Принципът: симулирате все повече потребители върху копие на приложението и отбелязвате момента, в който времето за отговор рязко се влошава.

wrk -t2 -c50 -d30s --latency https://preprod.vashiyat-sayt.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.vashiyat-sayt.com/');
  sleep(15);
}

• Тествайте копие, а не продукцията, и уведомете хостинг доставчика си, ако тестът е насочен към сървър, който той стопанисва.
• Пускайте теста от друга машина, различна от тествания сървър, иначе инструментът отнема от собствените му ресурси.
• Гледайте 95-ия перцентил на времето за отговор, а не средното: това изпитват най-зле обслужените ви потребители.
• Наблюдавайте сървъра по време на теста: htop за процесора, free -h за паметта, журналите за грешките.

Когато натоварването расте

Редът, който струва най-малко и носи най-много:

1. Кеширайте каквото може да се кешира (страници, фрагменти, резултати от заявки) и коригирайте бавните заявки.
2. Настройте броя на worker процесите според наличната памет и процесор.
3. Преминете към по-голям размер: повече vCPU и памет, без да променяте нищо в приложението.
4. Преместете базата данни на собствен сървър.
5. Разпределете приложението на няколко сървъра зад балансьор на натоварването.

Първите три стъпки покриват огромното мнозинство от бизнес приложенията, сайтовете и API: няколкостотин потребители, активни едновременно, се обслужват от един добре настроен сървър.