Почему NVMe не всегда ускоряет сайт: смотрим на latency, p95/p99 и профиль нагрузки

В сфере искусственного интеллекта произошло заметное событие. nmazikov 4 минуты назад Почему NVMe не всегда ускоряет сайт: смотрим на latency, p95/p99 и профиль нагрузки Уровень сложности Средний Время на прочтение 12 мин Охват и читатели 0 Серверная оптимизация * Серверное администрирование * Высоконагруженные системы * Хранение данных * IT-инфраструктура * FAQ У дисковой подсистемы слишком хорошая репутация в тарифных таблицах и не самая однозначная в инженерных обсуждениях. В первом случае нам продают гигабайты в секунду, во втором часто говорят, что для веба диск почти не важен. Я работаю контент-маркетологом в Scalehost и по работе регулярно разбираю темы, связанные с производительностью веб-проектов.

Вопрос “нужен ли сайту NVMe или это просто маркетинговая галочка” возникает так часто, что мне захотелось собрать его в один технически внятный разбор. На практике обе крайности слишком упрощают картину. Для веб-проекта важно как он ведет себя на мелком random I/O, при параллельных запросах и под нагрузкой.

Технические детали

Когда начинают вылезать не средние значения, а хвосты задержек. Предлагаю разобрать, какие дисковые метрики действительно коррелируют с TTFB и стабильностью отклика. Почему для веба важнее latency и tail latency, чем красивые цифры последовательного чтения.

И в каких сценариях переход с SATA на NVMe реально дает эффект, а в каких почти не влияет на поведение сайта. Почему для веба важнее latency и поведение под нагрузкой, чем последовательные MB/s Когда в описании сервера пишут “до 3 500 МБ/с” или “до 7 000 МБ/с”, почти всегда речь идет о последовательном чтении больших блоков данных. Для диска это понятный сценарий.

Он читает длинный непрерывный участок и тратит минимум усилий на переключение между операциями. Веб-проект работает немного иначе. Динамическая страница редко упирается в один длинный поток чтения.

Отраслевые последствия

Намного чаще сервер обрабатывает множество коротких и разнородных операций. Например, прочитать несколько файлов, обратиться к индексам базы данных, записать что-то в журнал, отработать временные файлы и параллельно обслужить другие запросы. В такой нагрузке на первый план выходит не пиковая скорость интерфейса, а то, насколько быстро диск отвечает на отдельные операции и насколько хорошо держит параллельный I/O без резкого роста задержек.

Поэтому для веба полезнее смотреть не только на мегабайты в секунду, а на три других вещи: latency - сколько времени занимает одна операция чтения или записи; queue depth - сколько операций диск может обрабатывать одновременно без заметной деградации; поведение под нагрузкой - насколько сильно растут задержки, когда запросов становится много. Разница между SATA и NVMe проявляется как раз здесь. SATA исторически создавался в логике более простого и ограниченного стека: небольшая глубина очереди, выше накладные расходы на каждый запрос, хуже масштабирование при росте параллельности.

Для одиночных или последовательных операций этого может быть достаточно. Но когда запросов много и они мелкие, диск начинает чаще “спотыкаться” о собственные ограничения.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.