Аудит производительности сервера

Что входит

Анализируем производительность сервера и приложения: профилирование, узкие места в БД и коде, рекомендации по конфигурации и кешированию.

Обращение звучит просто: сайт тормозит. За этим стоят разные вещи, и до замеров они неразличимы. Иногда медленно открывается только каталог с фильтрами, иногда сайт стоит в час пик и оживает ночью, иногда админка работает нормально, а посетители видят десятисекундную загрузку. Наращивание мощности сервера в такой ситуации помогает редко: если время уходит в один тяжёлый запрос к базе, вдвое больший процессор ускорит его на проценты, а счёт вырастет вдвое.

Начинаем с замеров, а не с рекомендаций. Профилируем реальные запросы и смотрим, где именно уходит время: ожидание базы, работа кода, отдача статики, обращения к внешним сервисам. Дальше разбираем базу данных: медленные запросы, отсутствующие индексы, выборки, которые вытягивают всю таблицу ради одного поля. Смотрим кэширование, потому что на Битриксе большая часть выигрыша обычно лежит именно там: отключённый композитный кэш и страницы, собираемые заново на каждый запрос. Проверяем конфигурацию сервера, версию PHP, настройки веб-сервера и то, как отдаются картинки и скрипты. К каждой находке считается оценка выигрыша, чтобы не тратить неделю на правку, дающую сто миллисекунд.

В отчёте находки идут с числами: сколько времени занимает сейчас, сколько станет после правки, сколько работы это потребует. После внедрения делаем контрольные замеры на тех же страницах и в то же время суток, потому что сравнение утреннего замера с вечерним ничего не доказывает. Обычный результат для запущенного проекта — ускорение в несколько раз без замены сервера.

Этапы работы

1. 01Профилирование нагрузки
2. 02Анализ БД, кода и конфигурации
3. 03Рекомендации по оптимизации
4. 04Контрольные замеры после правок

Частые вопросы

Зависит ли аудит от платформы?

Метод один и тот же для любого стека, отличается набор типовых мест. На Битриксе первым делом проверяют композитный кэш, настройки модуля и тяжёлые компоненты. На WordPress основное время обычно съедают плагины и темы, вызывающие лишние запросы на каждой странице. Для самописных проектов больше внимания уходит на профилирование кода и запросов.

Сайт станет быстрее без замены сервера?

В большинстве случаев да, и это первое, что мы проверяем. Замена сервера имеет смысл, когда ресурсы действительно исчерпаны, а код и база уже приведены в порядок. Если проблема в отсутствующем индексе или отключённом кэше, более мощное железо просто сделает ту же неэффективную работу быстрее, и через полгода вы вернётесь с той же жалобой.

Кто вносит правки?

Как удобнее. Мы можем выполнить оптимизацию сами или передать отчёт вашим разработчикам: он написан так, чтобы по нему можно было работать без нас. В обоих случаях делаем контрольные замеры после внедрения, потому что аудит без проверки результата остаётся списком гипотез.

Как понять, в чём именно причина?

По распределению времени в замерах. Если время уходит на ожидание ответа от приложения, дело в коде или базе. Если страница формируется быстро, а грузится долго, вопрос к размеру страницы, картинкам и скриптам. Если сайт быстр ночью и медленный днём, речь о нехватке ресурсов под нагрузкой. Эти три случая лечатся по-разному, и разделить их можно только измерением.