В одной из прошлых статей я рассказывал, как заставил MariaDB и PHP перестать насиловать жесткий диск и перенес буферы в оперативную память. Это дало отличный результат, но для меня этого было мало.
Последнюю неделю блог молчал не просто так. Я занимался тем, что в инженерных кругах называется «устранением накладных расходов». Я выжал максимум из конфигов, но уперся в архитектуру взаимодействия процессов. Даже если база данных работает мгновенно, данные всё равно должны дойти до веб-сервера. И вот здесь кроется «узкое горлышко», о котором забывают 90% администраторов.
Сегодня я расскажу, как перевел сервер на чистые Unix-сокеты, отказался от TCP-стека внутри локалхоста и получил время отклика (TTFB) в 9 миллисекунд на обычном HDD.
Проблема: Лишние посредники (TCP Overhead)
По умолчанию WordPress, Redis и база данных общаются через сетевой интерфейс 127.0.0.1 (localhost). С точки зрения удобства это нормально. С точки зрения физики — это абсурд.
Когда PHP запрашивает данные у Redis по TCP:
- Данные упаковываются в пакет.
- Проходят через сетевой стек ядра Linux (хоть и виртуальный).
- Считаются контрольные суммы.
- Происходит рукопожатие (Handshake).
- Данные распаковываются получателем.
Зачем мне сетевой протокол, если и PHP, и Redis, и база данных живут на одной материнской плате, в одной планке оперативной памяти? Это лишние такты процессора и лишние микросекунды, которые складываются в миллисекунды.
Решение 1: Unix Domain Sockets
Я полностью переписал конфигурацию сервера, переведя всё общение на Unix Sockets.
Сокет — это специальный файл в ядре системы. Процессы пишут в него напрямую, минуя сетевой стек.
- Redis: Теперь работает через
/var/run/redis/redis.sock. - MariaDB: Работает через
/var/run/mysqld/mysqld.sock. - PHP-FPM: Общается с Apache через системный сокет.
Результат: Я срезал уровень абстракции. Данные переливаются из процесса в процесс со скоростью копирования памяти (memcpy). Zero Copy в действии.
Решение 2: Тотальная статика (RAM-First)
Второй шаг — изменение логики кэширования.
Ранее кэш страниц лежал файлами на диске. Даже с тюнингом Linux (о котором я писал в прошлой статье), Apache всё равно совершал системный вызов open() к файловой системе.
Я внедрил схему, при которой «горячий» контент (HTML-страницы, которые вы читаете прямо сейчас) живет исключительно в Redis Object Cache и системных буферах Linux.
Теперь цепочка выглядит так:
- Пользователь запрашивает страницу.
- Apache проверяет наличие свежего кэша.
- Linux отдает файл мгновенно из оперативной памяти (buff/cache).
- HDD в этот момент находится в режиме IDLE. Головки диска запаркованы.
Решение 3: Дисциплина планировщика
Последний гвоздь в крышку гроба тормозов — отключение WP-Cron.
Стандартный крон WordPress — это паразитная нагрузка. Он срабатывает, когда на сайт заходит живой человек, заставляя PHP выполнять фоновые задачи вместо того, чтобы быстро отдать контент.
WP-Cron уничтожен.
Вместо него работает системный crontab, который запускает обслуживание строго по расписанию, независимо от трафика.
Итог: 9 мс
Цифры говорят громче слов.
Стандартное время ответа (TTFB) для динамического сайта на HDD — 150-300 мс.
После предыдущего тюнинга я получил 80 мс.
Сегодняшний замер показывает стабильные 9-11 мс.
Я добился того, что бюджетный сервер на Xeon E3 с механическими дисками отдает контент быстрее, чем облачные инстансы на NVMe за сотни долларов. Я обманул физику, исключив механику из уравнения чтения.
Система работает. Логи чистые. Диски холодные.
Работаем дальше.
Как думаешь, что может пойти позже не так?
Ведь сколько раз было такое, когда ты сделал всё круто, всё летало, а потом выяснилось что это была ошибка. Как думаешь, это верх эволюции тюнинга, или есть ещё куда стремиться?
Тут важно понимать разницу между «подкрутить» и «перестроить».
Раньше я тоже занимался тюнингом, но это было либо неполным решением, либо попыткой замаскировать архитектурные ограничения софтверными надстройками. Я пытался оптимизировать то, что в своей основе было избыточным. Это давало результат, но я всё равно упирался в невидимый потолок.
В этот раз подход другой — фундаментальный. Вместо того чтобы оптимизировать прохождение данных через сетевые протоколы, я просто убрал эти протоколы там, где они не нужны. Unix-сокеты напрямую соединяют процессы в памяти. Это не «еще одна настройка», это исправление того, что изначально работало неэффективно.
Для этого железа (Xeon E3 + HDD) это финальная точка. Дальше софтом физику не обманешь — только апгрейд самого кремния. Но теперь я уверен, что из этих дисков и процессора выжато всё до последней капли.