Еволюція автентифікації та захисту доступу
Еволюція кібербезпеки: від перших паролів до ключів доступу (passkeys) та Zero Trust. Дізнайтеся, як захистити дані від фішингу та чому SMS-коди вразливі.
Затримка (latency) - це час, за який ваша система обробляє один конкретний запит від початку до кінця. Пропускна спроможність (throughput) показує інше - обсяг роботи, яку сервер встигає виконати за секунду, наприклад, кількість запитів (RPS) чи фінансових транзакцій (TPS). Це дві абсолютно різні осі координат швидкодії. У складних розподілених системах вони майже завжди заважають одна одній. Чому це має хвилювати бізнес? Кожні 100 мс додаткової затримки на сайті коштують Amazon близько 1% продажів. Звичайні мілісекунди апаратного часу конвертуються у реальний прибуток або збитки.
Що таке Latency (затримка) і Throughput (пропускна здатність)?
Затримка визначає, як швидко інтерфейс реагує на клік користувача. Пропускна спроможність показує, скільки навантаження система витримає, коли на сайт одночасно зайде натовп покупців. Обидві метрики жорстко обмежені можливостями заліза та законами фізики.
Latency - затримка одного запиту
Затримка - це чистий час очікування. Секундомір запускається, коли користувач тисне на кнопку, і зупиняється, коли сервер повертає йому останній байт інформації. У вебі цей показник міряють мілісекундами (мс), у процесорах - наносекундами. Уявіть автомагістраль між двома містами: затримка - це час, за який один автомобіль долає весь цей шлях. Що менша цифра, то "миттєвіше" працює додаток. Загальний час подорожі пакета туди й назад (Round-Trip Time, RTT) складається з чотирьох частин:
- Propagation delay (Затримка поширення): Швидкість подолання фізичної дистанції в кабелі. Навіть у найкращому оптичному волокні світло не може рухатися швидше за фізичні ліміти.
- Transmission delay (Затримка передачі): Час, необхідний для запису всієї пачки бітів у канал. Він залежить від загальної ширини пропускання (bandwidth).
- Processing delay (Затримка обробки): Час, який залізо витрачає на розбір заголовків, перевірку сертифікатів безпеки SSL/TLS та виконання коду.
- Queuing delay (Затримка черги): Час простою у чергах, коли сервери перевантажені й запит чекає на обробку.
Throughput - пропускна спроможність
Пропускна спроможність - це показник масштабу. Вона фіксує обсяг успішно виконаної роботи за фіксовану секунду. На рівні вебсерверів її міряють у RPS, для баз даних - у TPS. Якщо повернутися до аналогії з шосе, то пропускна спроможність - це кількість автівок, які встигають проїхати повз пост спостереження за годину. Цей показник завжди нижчий за теоретичну стелю вашої лінії зв’язку через службові дані протоколів та неминучі втрати пакетів у мережі.
Bandwidth, Response Time, RPS/TPS, Concurrency - як вони пов'язані?
Щоб уникнути термінологічної каші, розмежовуйте ці поняття:
- Bandwidth (пропускна здатність): Гранична ширина вашого каналу, теоретичний максимум. Вимірюється в Gbps або Mbps.
- Response Time (час відгуку): Реальний час, який відчуває користувач. Це чиста затримка плюс час очікування в чергах на обробку.
- RPS/TPS: Реальний потік запитів (RPS) або транзакцій баз даних (TPS), який система обробляє щосекунди.
- Concurrency (паралелізм): Кількість запитів, які перебувають в обробці (in-flight) одночасно в цю саму мілісекунду.
| Параметр | Latency (Затримка) | Throughput (Пропускна спроможність) |
|---|---|---|
| Що вимірює | Швидкість реакції на індивідуальну дію | Загальна продуктивність під навантаженням |
| Одиниці виміру | Мілісекунди (мс), наносекунди (нс) | RPS, TPS, MB/s, Gbps |
| Коли критично | HFT-трейдинг, геймінг, e-commerce, IoT | Batch-обробка, бекапи, Data Warehousing |
| Аналогія | Час приготування страви для 1 гостя | Кількість страв, виданих кухнею за вечір |
Закони, що пов'язують latency і throughput
Ці дві метрики зв'язані жорсткою математикою. Якщо ігнорувати ці закони під час проектування архітектури, перше ж серйозне навантаження каскадно обвалить ваші сервери.
Little's Law (Закон Літтла)
Закон Літтла визначає баланс у системах черг. Його класична формула \( L = \lambda W \) говорить: середня кількість запитів у системі дорівнює швидкості їх надходження, помноженій на час обробки. На практиці це спрощують до рівняння: Throughput = Concurrency / Latency.
Завдяки цій формулі архітектори рахують ліміти пулів підключень. Наприклад, якщо ваш сервіс отримує 1000 RPS, а середня затримка обробки запиту становить 0.05 секунди (50 мс), вам потрібно утримувати у постійно активному стані щонайменше \( 1000 \times 0.05 = 50 \) паралельних потоків чи з'єднань з базою даних. Плюс обов’язковий запас під сплески трафіку.
Теорія масового обслуговування (Queueing theory)
Теорія черг показує, чому продуктивність падає нерівномірно. Поки процесор завантажений до 70%, затримка залишається стабільною й передбачуваною. Але варто перейти цю межу й наблизитися до 80%, як черги починають накопичуватися лавиноподібно.
Саме цим пояснюється ефект, коли додаток чудово працював при 500 RPS, а на 550 RPS раптово помирає. Пропускна спроможність просто вперлася у свій ліміт, а затримка злетіла вертикально вгору, викликаючи таймаути на клієнті.
Закон Амдала (Amdahl's law)
Закон Амдала визначає межу прискорення систем при паралельній обробці. Його суть проста: якщо у вашому коді є частина, яку фізично неможливо розпаралелити, саме вона стане пляшковою шийкою. Граничне прискорення виражається формулою \( S_{max} = 1 / f \), де \( f \) - послідовна частина програми.
Якщо 5% вашого коду вимагає монопольного блокування бази даних, ви можете додати хоч тисячу процесорних ядер, але додаток ніколи не прискориться більш ніж у 20 разів (\( 1 / 0.05 = 20 \)). Повільний серійний запис у базу даних нівелює ефект від найпотужнішого кластера серверів.
Перцентилі latency: чому «середнє» бреше?
Орієнтуватися на середнє значення затримки - найпоширеніша помилка моніторингу. Середня цифра красиво маскує проблеми окремих користувачів, створюючи ілюзію швидкого інтерфейсу.
Що таке p50, p95, p99 та p99.9?
Перцентилі ділять загальний масив запитів на групи швидкості. Наприклад, показник p99 (99-й перцентиль) означає час, у який вклалися 99% клієнтів. Останній 1% - це так звана "хвостова затримка" (tail latency).
Якщо система обробила 99 швидких запитів за 10 мс і лише один застряг на 4 секунди, середнє значення покаже цілком прийнятні 50 мс. Моніторинг зелений, розробники спокійні. Проте один клієнт із сотні чекав цілих 4 секунди. Метрика p99 одразу виведе ці 4000 мс на графік і покаже реальну деградацію сервісу.
Tail latency на масштабі (The Tail at Scale)
Згідно з класичним дослідженням Джеффа Діна та Луїса Баррозо, опублікованим у дослідженні ACM "The Tail at Scale", у великих мікросервісних системах хвостова затримка швидко масштабується. Якщо ваш запит паралельно звертається до 100 різних серверів, і кожен з них має p99 затримку в 1 секунду, то загальна ймовірність отримати затримку понад секунду на клієнті становить \( 1 - 0.99^{100} = 63\% \).
Повільна робота одного компонента з ланцюжка перетворюється на медіанний (p50) досвід для більшості користувачів. Боротися з цим допомагають методи резервування запитів (request hedging), коли система дублює повільний запит на інший інстанс, не чекаючи таймауту.
Trade-off між latency і throughput - типові сценарії
Ви не можете викрутити обидві метрики на максимум одночасно. Спроба покращити одну майже завжди б'є по іншій.
Batching, buffering та pipelining
Пакетна обробка (batching) чудово піднімає throughput. Сервер збирає тисячі дрібних записів у один великий блок і записує його на диск за один підхід, значно економлячи ресурси. Проте за це доводиться платити затримкою: кожен індивідуальний запис змушений чекати у буфері, поки накопичиться весь пакет для відправки.
Caching та асинхронна обробка
Кеш миттєво знижує затримку для повторних запитів. Черги повідомлень (на кшталт RabbitMQ) дозволяють вебсерверу швидко прийняти завдання й віддати клієнту статус "Прийнято" (низька latency), а важку обробку відкласти на потім. Пропускна спроможність зростає, але кінцева синхронізація даних (eventual consistency) відбувається з затримкою.
Connection pooling
Встановлення нового мережевого підключення вимагає тривалого узгодження (TCP/TLS handshake). Пул з'єднань тримає пул заздалегідь відкритих сокетів. Це один із небагатьох патернів, що працює в обидва боки: він прибирає затримку на створення нових підключень та дозволяє утримувати високий throughput без зайвих витрат процесорного часу на криптографію.
HTTP/2 vs HTTP/1.1 та gRPC vs REST
Протоколи передачі даних мають власний оверхед. Старий HTTP/1.1 змушував відкривати окреме з'єднання під кожен файл, що призводило до блокування запитів. HTTP/2 вирішив це завдяки мультиплексуванню багатьох потоків в одному сокеті.
Сучасний gRPC використовує бінарний формат Protocol Buffers і працює виключно поверх HTTP/2. У порівнянні з класичним текстовим JSON у REST API, gRPC значно швидше серіалізує дані, знижуючи затримку обробки на мікросервісах і витримуючи більший потік запитів.
| Характеристика | HTTP/1.1 | HTTP/2 |
|---|---|---|
| Мультиплексування | Ні (1 запит = 1 TCP-з'єднання) | Так (Усі запити через 1 з'єднання) |
| Формат даних | Текстовий (Text) | Бінарний (Binary) |
| Стиснення заголовків | Ні (Gzip лише для payload) | Так (HPACK) |
| Проблема Head-of-Line | Присутня на рівні HTTP | Вирішена на рівні HTTP (залишається у TCP) |
| Характеристика | REST | gRPC |
|---|---|---|
| Транспортний протокол | Переважно HTTP/1.1 | Виключно HTTP/2 |
| Формат Payload | JSON / XML (Текст) | Protocol Buffers (Бінарний) |
| Оптимізація Latency | Низька (повільна серіалізація) | Висока (нативна серіалізація коду) |
| Тип комунікації | Unary (Запит-відповідь) | Unary, Bi-directional streaming |
Приклади з реальних архітектур
Вибір технологій завжди залежить від специфіки вашого продукту. Те, що добре для збору аналітики, знищить інтерфейс інтернет-магазину.
Бази даних - OLTP (latency) vs OLAP (throughput)
Транзакційні бази (OLTP, на кшталт PostgreSQL) заточені під низьку затримку. Вони швидко записують та оновлюють окремі рядки (наприклад, баланс користувача чи статус замовлення). Аналітичні бази (OLAP, як ClickHouse) орієнтовані на throughput. Вони сканують мільярди рядків за секунду, щоб порахувати квартальний звіт. Якщо ви спробуєте запустити важкий аналітичний звіт прямо на транзакційній базі, вона просто заблокує дискові операції, і живі покупці отримають величезні затримки.
| Характеристика | OLTP (Transaction) | OLAP (Analytical) |
|---|---|---|
| Головна метрика | Latency (p99 < 10ms) | Throughput (GB/s сканування) |
| Тип запитів | INSERT/UPDATE одиничних рядків | SELECT з агрегацією мільйонів рядків |
| Архітектура зберігання | Row-oriented (по рядках) | Column-oriented (колонкова) |
CDN, мікросервіси та API gateway
Мережі доставки контенту (CDN) долають географічні обмеження швидкості світла. Вони кешують картинки та скрипти на серверах, розташованих максимально близько до користувача, прибираючи затримку поширення сигналу. Мікросервіси спрощують життя командам розробників, але збільшують затримку через постійні запити всередині мережі. API Gateway допомагає збалансувати цей потік, розподіляючи навантаження та відсікаючи занадто активних клієнтів (rate limiting) для захисту внутрішнього throughput.
Як вимірювати latency і throughput - інструменти
Неможливо контролювати те, що ви не вмієте вимірювати. Продуктивність інфраструктури потребує регулярного аудиту та симуляції критичних навантажень.
APM і моніторинг
Системи APM (Datadog, New Relic) та зв'язка Prometheus із Grafana дозволяють бачити стан заліза в реальному часі. Головне правило: збирайте метрики у вигляді гістограм (Histogram). Якщо ви просто усередните вже готові значення p99 з різних серверів, ви отримаєте абсолютно хибні дані.
Навантажувальне тестування
Ці інструменти штучно створюють великий потік запитів (throughput), щоб зафіксувати момент, коли затримка (latency) почне виходити за межі норми. Зверніть увагу: різні утиліти по-різному трактують момент завершення запиту (хтось рахує чистий час відповіді сокета, хтось - повний парсинг сторінки браузером).
| Інструмент | Мова скриптів / Рантайм | Найкраще підходить для... |
|---|---|---|
| k6 (Grafana) | JavaScript / Go-рантайм | Сучасний стандарт, інтеграція з CI/CD |
| JMeter | Java / GUI | Легасі-системи, тестування складних TCP протоколів |
| Gatling | Scala / Java | Симуляція мільйонів користувачів (висока concurrency) |
| Locust | Python | Команди, що пишуть на Python, розподілене тестування |
| wrk | Lua | Надлегкий бенчмаркінг API з консолі |
Вплив швидкості системи на бізнес
Для бізнесу мілісекунди - це не абстрактні цифри на графіках моніторингу. Це реальні гроші, які ви або заробляєте, або віддаєте конкурентам.
Конверсія і дохід - класичні кейси
Досвід найбільших світових платформ доводить: що швидше працює інтерфейс, то краще купують клієнти.
- Amazon: Базові дослідження швидкодії довели, що кожні додаткові 100 мілісекунд затримки коштують Amazon 1% продажів у річному еквіваленті.
- Walmart: Технічні тестувальники Walmart виявили чітку закономірність: прискорення завантаження сторінок всього на 1 секунду збільшує конверсію магазину на 2%, а оптимізація на кожні 100 мс приносить 1% додаткового прибутку.
- Deloitte: У відомому дослідженні Deloitte "Milliseconds Make Millions" аналітики довели, що покращення швидкості мобільного сайту на 0.1 секунди піднімає конверсію в ритейлі на 8.4% та збільшує середній чек на 9.2%.
- Pinterest: Розробники Pinterest змогли скоротити час очікування інтерфейсу на 40%, що дало зростання реєстрацій на 15% і пропорційно підняло обсяг органічного SEO-трафіку.
Core Web Vitals (LCP, INP, CLS) і SEO
Google офіційно включив параметри швидкодії (Page Experience) у фактори ранжування. Повільні сторінки втрачають безкоштовний органічний трафік та дорожчають у платній рекламі Google Ads через падіння показника Quality Score.
- Largest Contentful Paint (LCP): Час завантаження основного контенту. Сторінка має повністю відмалюватися швидше ніж за 2.5 секунди.
- Interaction to Next Paint (INP): Оцінює швидкість реакції інтерфейсу на клік користувача. Поріг "good" вимагає показника менше 200 мс на 75-му перцентилі реальних сесій.
- Cumulative Layout Shift (CLS): Показник стабільності макета (чи не "пливуть" картинки та блоки під час завантаження). Норма - менше 0.1.
У звітах про бізнес-вплив Core Web Vitals на web.dev наведено кейс компанії redBus. Оптимізація показника INP на 72% дозволила їм підняти продажі приблизно на 7%.
Психологія очікування - межі response time
Три класичні психологічні пороги сприйняття часу, сформульовані Робертом Міллером ще у 1968 році, залишаються незмінними й сьогодні:
- 0.1 секунди: Користувач відчуває, що система реагує миттєво. Його увага повністю сфокусована на процесі.
- 1.0 секунда: Пауза помітна, але потік думок не переривається. Користувач відчуває контроль над інтерфейсом.
- 10 секунд: Межа утримання уваги. Якщо сайт не завантажився за цей час, людина просто закриває вкладку. За аналітикою Akamai щодо швидкодії інтернет-магазинів, понад 53% мобільних користувачів йдуть із сайту, якщо він вантажиться довше 3 секунд.
ROI оптимізації та вартість простою
Перевантаження черг та падіння пропускної спроможності ведуть до найгіршого - повного простою сервісу. За даними щорічного опитування ITIC, година даунтайму обходиться середнім та великим компаніям у понад \$300,000. Липневий збій Crowdstrike у 2024 році завдав компаніям зі списку US Fortune 500 прямих фінансових втрат на суму близько \$5.4 млрд.
Уявімо інтернет-магазин із річним оборотом у 1 000 000 грн. Наразі його сторінки завантажуються в середньому за 3 секунди. Якщо оптимізувати фронтенд та налаштувати кешування, скоротивши час завантаження всього на 1 секунду (до 2 секунд), то за рахунок прогнозованого зростання конверсії на 7–10% компанія може отримати від 70 000 до 100 000 грн додаткового виторгу на рік. При цьому загальні витрати на залучення рекламного трафіку залишаться незмінними.
Шлях до швидкої інфраструктури: впровадження культури продуктивності
Оптимізація швидкодії - не разова акція технічної команди. Це безперервний процес, який потребує іншого підходу на рівні управління продуктом. Щоб не втратити відвойовані мілісекунди, варто запровадити «бюджет продуктивності» (performance budget) - набір жорстких обмежень, за межі яких не має права виходити жоден новий реліз. Скажімо: розмір завантажуваних скриптів - не більше 150 КБ, а LCP на реальних пристроях - завжди в межах 2 секунд. Якщо нова фіча ламає ці метрики, її реліз блокується автоматично - хоч би якими привабливими здавалися маркетингові переваги.
Такий підхід ставить продакт-менеджерів і розробників в одну систему координат. Замість того щоб без кінця нарощувати важкі скрипти аналітики та непродумані віджети, команда вчиться шукати компроміс - кожну нову інтеграцію тут зважують за тим, у скільки обійдеться вповільнення. І лише коли швидкість стає повноцінною продуктовою характеристикою, нарівні з дизайном та функціоналом, компанія отримує стійку довгострокову перевагу - таку, яку нелегко скопіювати чи перекупити на конкурентному ринку.
Часто задавані питання (FAQ)
Чим відрізняється latency від throughput?
Latency - це швидкість обробки одного конкретного запиту (міряється в мілісекундах). Throughput - це загальний обсяг роботи, яку система здатна виконати за фіксований час (міряється в запитах на секунду, RPS).
Чи можна оптимізувати і latency, і throughput одночасно?
Зазвичай вони перебувають у стані компромісу: пакетна обробка підвищує загальний throughput, але погіршує latency для окремого користувача. Проте такі технології, як кешування в пам'яті (Redis) та пули з'єднань, допомагають покращити обидва показники одночасно.
Чому р99 важливіший за середню latency?
Середнє арифметичне значення повністю маскує поодинокі довгі затримки. Показник p99 демонструє час відгуку для найповільнішого 1% користувачів. Саме цей відсоток клієнтів найчастіше залишає покинуті кошики й закриває вкладку сайту.
Що таке Little's Law?
Закон Літтла описує роботу систем черг за формулою: Throughput = Concurrency / Latency. Ця математична модель дозволяє інженерам розрахувати необхідну кількість паралельних з'єднань до бази даних чи вебсервера.
Як швидкість сайту впливає на продажі?
Amazon зафіксував втрату 1% продажів за кожні 100 мс затримки. Walmart додав 2% конверсії за 1 секунду прискорення. Дослідження Deloitte показує зростання retail-конверсії на 8.4% при прискоренні всього на 0.1 с.
Що таке INP і який поріг «good»?
Interaction to Next Paint (INP) - метрика Core Web Vitals, що вимірює швидкість реакції інтерфейсу на дії користувача. Щоб отримати оцінку «good» від Google, затримка має бути меншою за 200 мс на 75-му перцентилі сесій.
Який інструмент обрати для навантажувального тестування?
k6 ідеально підходить для інтеграції у CI/CD процеси та написання тестів на JS/Go. JMeter - стандарт для перевірки складних корпоративних протоколів. Gatling найкраще симулює мільйони одночасних сесій. Locust зручний для Python-команд, а wrk - для швидких консольних тестів API.
Bandwidth і throughput - це одне й те саме?
Ні. Bandwidth - це теоретична ширина вашого мережевого каналу (ліміт труби). Throughput - це фактична швидкість передачі корисних даних. Через службовий оверхед мережевих протоколів throughput завжди буде меншим за bandwidth.
Втрачаєте клієнтів через високу Latency?
Уповільнення роботи вашої бази даних чи 1С безпосередньо впливає на лояльність клієнтів та дохід. Не дозволяйте технічним затримкам знищувати ваш бізнес. Перенесіть ваші проекти на відмовостійкі хмарні сервери від ІТЕЗ із гарантованим аптаймом SLA 99.98%, щоденним резервним копіюванням та супершвидкими накопичувачами SAS SSD без штучного обмеження швидкості (throttling). Ви отримаєте прямий зв'язок з вашим персональним інженером техпідтримки 24/7 без будь-яких тікет-систем та заплутаних нарахувань.
