Як зменшити затримку сервера: 8 способів, які дійсно працюють

Затримка — це час між запитом і відповіддю. Для інтерактивних додатків затримка понад 100 мс сприймається як повільність, а після перевищення 500 мс користувачі починають відмовлятися від них. У цій публікації розглядається, що насправді спричиняє високу затримку, вісім методів її зменшення та які з них слід обрати залежно від вашого бюджету та архітектури.

Що спричиняє високу затримку

Три фактори впливають на затримку майже всіх серверів:

• Фізична відстань. Світло рухається по оптоволокну зі швидкістю, що становить приблизно дві третини швидкості у вакуумі. Існує жорстка межа часу проходження сигналу в обидва боки, яка визначається відстанню між клієнтом і сервером, і жодне налаштування не дозволить її подолати.
• Маршрутизація мережі. Пакети рідко проходять найкоротшим шляхом. Вони перескакують через транзитних провайдерів, інтернет-обмінні точки та точки пірингу, кожна з яких додає від мікросекунд до мілісекунд. Неякісний піринг може подвоїти або потроїти теоретичний мінімум.
• Обробка на стороні сервера. Після надходження запиту сервер все одно має його обробити: синтаксичний аналіз, запити до бази даних, введення-виведення з диска, логіка додатка. Один повільний запит може додати секунди, повністю затьмаривши мережеву частину.

Приблизні діапазони часу проходження туди-назад, про які варто знати:

• LAN: менше 1 мс
• У межах одного регіону: 10–30 мс
• Міждержавний (Схід-Захід США): 60–80 мс
• Трансатлантичний: 70–100 мс
• Транстихоокеанський: 130–180 мс
• Геостаціонарний супутник: 500 мс+ (послуги LEO, такі як Starlink: 20–50 мс)

8 способів зменшити затримку сервера

1. Наблизити обробку даних за допомогою периферійних обчислень

Периферійні обчислення запускають логіку додатків на серверах, фізично близьких до користувачів, а не в єдиному центральному центрі обробки даних. Для робочих навантажень, де кожен запит викликає обмін даними в обидва боки (інтерактивні API, ігри в реальному часі, інференція ШІ), це скорочує мережеву частину затримки до однозначних мілісекунд. Найкраще підходить для глобально розподілених користувачів із робочими навантаженнями, чутливими до затримки.

2. Кешуйте контент у CDN

CDN зберігає статичний і все більше динамічний контент на периферійних вузлах по всьому світу, тому користувачі отримують дані з найближчої копії, а не з вашого джерела. Це найпростіший спосіб отримати значну вигоду для будь-якого сайту, що обслуговує глобальний трафік, особливо для медіа, JavaScript, CSS та відповідей API, які можна кешувати. Сучасні CDN підтримують очищення в режимі реального часу та правила кешування, засновані на заголовках запитів.

3. Ізолюйте трафік за допомогою приватних VLAN

Приватні VLAN розділяють мережевий трафік на ізольовані підмережі, щоб не пов'язані між собою робочі навантаження не ділили домени мовлення. У поєднанні з політиками QoS вони гарантують пропускну здатність для сервісів, чутливих до затримок (VoIP, реплікація баз даних, відеодзвінки), незалежно від того, що ще працює на тій самій фізичній інфраструктурі. Це скоріше рішення для багатокористувацьких систем або великих локальних мереж, ніж для одиночних серверів.

4. Надайте пріоритет критичному трафіку за допомогою QoS

Правила якості обслуговування вказують мережевому обладнанню, які пакети отримують пріоритет під час перевантаження. Запити до баз даних та виклики API отримують швидкісний канал; резервне копіювання та масове реплікування отримують те, що залишилося. Дійсно ефективно на каналах, які періодично перевантажуються. Безглуздо на каналах, які ніколи не перевантажуються.

5. Оновлення до швидшого обладнання

Найбільші переваги на стороні сервера забезпечують кілька компонентів:

• NVMe-накопичувачі, що замінюють SATA SSD, для зниження затримки вводу-виводу в 10-100 разів
• Сучасні мережеві карти з підтримкою RSS, RDMA або DPDK для високої швидкості передачі пакетів
• Достатній обсяг оперативної пам'яті, щоб зберігати «гарячі» дані в пам'яті, а не зчитувати їх з диска
• Процесори з достатньою кількістю ядер та продуктивністю на ядро, щоб уникнути конфліктів при перемиканні контексту

Один сервер з правильно підібраними характеристиками часто перевершує кластер з погано підібраними характеристиками.

6. Розподіліть навантаження між серверами

Балансування навантаження розподіляє запити між декількома бекендами, щоб жоден окремий сервер не став вузьким місцем. Стандартні алгоритми (round-robin, least connections, weighted) працюють для бездержавних служб; для державних служб важливі sticky sessions. Географічне балансування навантаження через anycast або GeoDNS направляє користувачів на найближчий працездатний сервер, зменшуючи RTT для глобальної аудиторії.

7. Оптимізуйте додатки та бази даних

Часто це найбільший виграш. Типові причини:

• Відсутні або невикористані індекси бази даних
• Шаблони запитів N+1 через неправильне використання ORM
• Послідовний ввід-вивід, де паралельний працював би
• Відсутність кешу в пам'яті (Redis, Memcached) перед повторюваними читаннями
• Блокуючі операції на гарячих кодових шляхах

Перед оптимізацією проведіть профілювання. Такі інструменти, як py-spy, perf або відповідний APM, показують, де насправді витрачається час, а не де ви припускаєте, що він витрачається.

8. Постійний моніторинг

Неможливо виправити те, чого не бачиш. Відстежуйте RTT, втрату пакетів, джиттер та процентильні часи відгуку (p50, p95, p99). Зазвичай саме за p99 ховається поганий UX. Інструменти, про які варто знати: mtr для діагностики шляхів — smokeping; для аналізу тенденцій — Prometheus і Grafana; для часових рядів — APM (Datadog, New Relic, Sentry) для видимості на рівні додатків.

Порівняння 8 підходів

Як вибрати те, що підходить

Вибирайте те, чого у вас найменше:

• Обмежений бюджет. Почніть з оптимізації додатків та баз даних, додайте моніторинг, а потім управління пропускною здатністю. Це вимагає часу інженерів, а не інфраструктури.
• Обмежений час інженерів. CDN та оновлення обладнання дають великі переваги при мінімальних зусиллях на налаштування.
• Глобально розподілені користувачі. Спочатку CDN. Додайте периферійні обчислення для тих частин, які не можна кешувати.
• Робочі навантаження, для яких критична затримка (ігри в реальному часі, торгівля, інференція ШІ). Оновлення обладнання та розгортання на периферії разом. Одні лише прийоми з додатками не допоможуть вам досягти мети.
• Вже високий трафік. Перед тим, як масштабувати що-небудь інше, слід налагодити балансування навантаження та моніторинг.

Остаточні висновки

Найбільші вигоди можна отримати з двох джерел: скорочення фізичної відстані за допомогою CDN або периферійних вузлів та усунення неефективності на стороні сервера, яка перетворює 50 мс затримки мережі на 500 мс загального часу відгуку. Більшість команд недооцінюють другий фактор.

Для робочих навантажень, чутливих до затримки, мережа, що лежить в основі, має таке ж значення, як і код, що працює поверх неї. Виділені сервери FDC постачаються у мережі з якісним пірингом у понад 70 локаціях по всьому світу, з необмеженою пропускною здатністю та сучасним обладнанням (EPYC, NVMe). Це дає вам основу, яка не створює вузьких місць у тих речах, які ви не можете виправити в коді.