Начинаю с конкретного медленного сценария
«Всё тормозит» трудно исправить. Полезнее знать, кто и какое действие выполняет: менеджер открывает заказы, покупатель оформляет покупку или бухгалтер строит отчёт за год.
Разбираю путь запроса: что делает приложение, сколько времени занимает база данных, какие внешние сервисы вызываются и сколько информации возвращается в браузер. Проверяю не только обычный ответ, но и редкие долгие задержки.
До и после изменений сравниваем один сценарий при сопоставимых данных и нагрузке. Иначе прогретый кэш или случайно свободный сервер легко принять за исправленную проблему.
1. Страница задаёт базе слишком много вопросов
Например, список содержит 50 заказов. Приложение сначала получает заказы, а затем отдельно запрашивает покупателя для каждого. В простом случае получается 51 обращение к базе вместо нескольких заранее подготовленных выборок. Такую ситуацию называют N+1.
Другой вариант — обращений немного, но каждое заставляет просматривать большой объём данных. Тогда проверяю условия поиска, сортировку и план выполнения запроса: как именно база находит результат. Индекс может помочь, но добавлять его без проверки не стоит — у хранения и обновления индексов тоже есть цена.
Число обращений в примере объясняет проблему. Оно не обещает конкретного ускорения вашего проекта.
2. Для одного экрана загружается слишком много данных
На экране нужны последние записи, а сервер сначала получает всю историю, собирает большие объекты и только потом отбрасывает лишнее. Время и память уже потрачены. С ростом базы такой подход становится всё заметнее.
Проверяю, можно ли отбирать нужные строки и поля раньше, выдавать список страницами, обрабатывать выгрузку частями. Цель — не уменьшить данные любой ценой, а передавать ровно то, что требуется конкретной операции.
3. Пользователь ждёт чужой сервис
Сохранение заявки может зависеть от ответа CRM, почты, службы доставки или другого API. Если один участник отвечает долго, всё действие выглядит зависшим. Даже быстрый код на другом языке сам по себе не ускорит внешний сервис.
Разделяю обязательные действия и те, которые допустимо выполнить позже. Для ожидания задаются разумные ограничения по времени. Повторные попытки проектируются осторожно: после сетевого сбоя неизвестно, успел ли другой сервис выполнить действие. Повтор не должен создать второй заказ или платёж.
4. Тяжёлый отчёт выполняется прямо в ответ на клик
Пользователь нажимает «Скачать отчёт», и страница ждёт завершения долгих расчётов. Если результат не нужен немедленно, удобнее принять задачу, показать её состояние и дать готовый файл после завершения.
Для этого можно использовать очередь: список заданий, которые выполняются отдельно от открытия страницы. Важно проверять не только быстрый ответ кнопки, но и то, что задания действительно завершаются, ошибки видны, а повтор не портит данные. Перенос в очередь не делает сам расчёт быстрее.
5. Одна и та же работа выполняется снова и снова
Если несколько посетителей запрашивают один и тот же отчёт, каждый запрос может заново запускать одинаковый расчёт. Иногда результат можно временно сохранять — это называется кэшированием.
Нужно определить допустимую давность данных и момент обновления. Также важно учитывать права доступа: нельзя показать одному клиенту сохранённый результат другого. Бездумно кэшировать всё подряд — способ получить быструю, но неверную систему.
Повторы бывают и внутри одного расчёта: программа снова просматривает длинный список для каждой его строки. Предварительная подготовка нужных связей иногда полезнее добавления сервера или смены языка.
6. Запросы мешают друг другу
При одновременном изменении данных база иногда удерживает часть записей, чтобы операции не повредили друг другу. Если внутри такой операции приложение долго ждёт внешний API, другим пользователям тоже приходится ждать.
Проверяю, как долго заняты данные и что действительно нужно выполнить вместе. Сократить время ожидания важно, но нельзя ради скорости потерять правильность остатков, баланса или статуса заказа.
Что получите после диагностики
- Объяснение, какой участок создаёт задержку и чем подтверждается вывод.
- Приоритетные исправления с ожидаемым эффектом и ограничениями.
- План проверки скорости и правильности после изменений.
- Понимание, достаточно ли исправить PHP-код или нужна другая обработка данных, инфраструктура либо отдельный сервис.
Эти ситуации — типовые примеры. В вашем проекте причина может быть другой, поэтому обещание «ускорить в десять раз» без измерений не будет обоснованным. Работа с существующей системой начинается с аудита.
ЕЩЁ НЕСКОЛЬКО ОТВЕТОВ
Что важно уточнить
Может, проще купить сервер помощнее?
Иногда ресурсов действительно мало. Но сначала полезно понять, на что они расходуются. Дополнительная мощность может временно скрыть лишнюю работу, не устранив её причину.
После оптимизации данные не изменятся?
Правильность результата — обязательная часть проверки. Согласуем важные сценарии и сравним их до и после изменений. Особенно внимательно нужно проверять расчёты, права доступа и повторные запросы.
Когда нужно переписать часть на Go?
Когда измерения показывают, что остаётся конкретная тяжёлая задача и отдельный сервис оправдан по скорости, стоимости и поддержке. Иногда хватает исправления запроса или фоновой обработки на PHP.
Технические источники для тех, кто хочет глубже
Официальная документация по описанным механизмам: