Аудит производительности приложения и базы данных

У медленного приложения не всегда одна простая причина

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

Поэтому аудит не начинается со случайного добавления индексов или замены сервера. Сначала мы определяем важный для бизнеса сценарий, условия возникновения проблемы и повторяемый способ её измерения. Только после этого проверяем соответствующие части системы.

Когда такой аудит имеет смысл

Важная операция занимает всё больше времени

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

Система замедляется по мере роста компании

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

Возникают тайм-ауты и нестабильное время ответа

Одна и та же операция в одном случае выполняется быстро, а в другом останавливает процесс. Это особенно часто касается очередей, регулярных задач, интеграций, импортов и одновременно выполняемых операций.

Есть несколько гипотез, но нет доказательств

Один специалист предлагает более мощный сервер, другой перестройку базы данных, третий смену фреймворка. Аудит помогает отделить причину от симптома и правильно расставить очерёдность работ.

Сначала мы определяем, что значит «медленно» именно в этой системе

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

До начала измерений мы согласовываем:

• конкретный экран, действие или процесс;
• среду и условия, в которых возникает проблема;
• объём данных, число операций или нагрузку, необходимые для её воспроизведения;
• доступные измерения, технические журналы и ограничения доступа;
• способ проверки того, помогло ли будущее исправление.

Благодаря этому мы сравниваем одинаковые условия и не делаем выводы на основании одного случайного теста.

Пример: медленный отчёт не обязательно означает отсутствие индекса

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

Добавление индекса без проверки плана выполнения может ничего не изменить. Увеличение ресурсов сервера может лишь отложить проблему. Поэтому сначала мы воспроизводим ситуацию, собираем измерения и определяем, где действительно тратится время.

Это гипотетический пример метода анализа, а не описание конкретного проекта и не обещание, что у каждого приложения одна и та же проблема.

Что мы можем проверить

Точный объём согласовывается до начала работ. Не каждому приложению требуется проверка всех перечисленных областей.

Мы выполняем только измерения, безопасные для согласованной среды. Действия, способные изменить данные, повысить нагрузку или повлиять на пользователей, требуют отдельного решения и подходящих условий тестирования.

Как проходит аудит

1. Кратко оцениваем задачу

Разговор продолжительностью до 20 минут помогает понять симптом, его влияние на бизнес и необходимые доступы. Он бесплатный, но не заменяет диагностику, анализ кода или отчёт.

2. Согласовываем объём и безопасные условия

Определяем исследуемые сценарии, среду, материалы, ограничения и формат результата. Если требуется нагрузочный тест, отдельно согласовываем его масштаб и способ защиты работающей системы.

3. Воспроизводим проблему и фиксируем исходное состояние

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

4. Изолируем узкие места

Проверяем только уровни, включённые в согласованный объём. Сравниваем измерения, планы выполнения и поведение приложения, чтобы определить причины, подтверждённые данными.

5. Расставляем приоритеты и определяем способ проверки

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

Что вы получите

Состав результата определяется в предложении. Обычно он включает:

• описание исследованной области и условий измерения;
• исходное состояние на основе выполненных измерений;
• подтверждённые узкие места с доказательствами и приоритетом;
• краткосрочные рекомендации и изменения, требующие дальнейшей разработки;
• способ повторной проверки после внедрения исправлений;
• рекомендуемую очерёдность работ;
• отдельную оценку внедрения, если объём можно определить достоверно.

Итог передаётся в формате, согласованном до начала работ. Вы можете использовать его для дальнейшей работы с Domin Software или передать другому выбранному исполнителю при соблюдении конфиденциальности и без публичного распространения материалов.

Почему одного результата Lighthouse недостаточно

Lighthouse полезен для проверки загрузки конкретной страницы в лабораторных условиях. Однако сам по себе он не описывает работу базы данных, очередей, импортов, закрытых разделов и реальный опыт всех пользователей.

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

Для базы данных важен план выполнения, а не только список индексов

Инструменты баз данных позволяют увидеть, какой план выбран для запроса и что произошло при его выполнении. PostgreSQL и MySQL предоставляют для этого команды семейства EXPLAIN. Точные возможности зависят от системы и версии.

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

Методы диагностики подбираются под конкретную базу и среду. Мы не запускаем в рабочей среде затратные операции или операции, меняющие данные, без согласования безопасных условий.

Что не входит в базовый аудит

Если в предложении не указано иное, базовый объём не включает:

• внедрение рекомендованных исправлений;
• постоянный мониторинг и текущее сопровождение приложения;
• создание дополнительной инфраструктуры для крупных нагрузочных тестов;
• полный аудит безопасности или полный аудит приложения, созданного с помощью ИИ;
• гарантию конкретной оценки Lighthouse, времени ответа или числа обслуживаемых пользователей;
• исправление компонентов, которые невозможно безопасно проверить в согласованной среде.

Если анализ показывает необходимость более широкой перестройки, следующим шагом может стать модернизация приложения. Когда нужны постоянное сопровождение, мониторинг и поддержка изменений, подойдёт сопровождение приложений и интернет-магазинов. Внедрение отдельных рекомендаций можно оценить как отдельный этап разработки на PHP и Laravel.

Сроки, оценка и оплата

Стоимость аудита рассчитывается индивидуально, поскольку объём зависит от числа исследуемых процессов, технологий, доступных данных и условий тестирования.

Ориентировочный срок составляет от 5 до 10 рабочих дней после получения всех согласованных доступов и материалов. Точный срок фиксируется в предложении.

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

Часто задаваемые вопросы

Достаточно ли прислать результат PageSpeed Insights или Lighthouse?

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

Нужен ли вам доступ к рабочей системе?

Не всегда. Сначала мы определяем, где проблему можно безопасно воспроизвести. Предпочтительны тестовая среда или контролируемые измерения. Доступ к рабочей системе согласовывается только тогда, когда он необходим и может быть должным образом ограничен.

Включает ли аудит внедрение исправлений?

Не в базовом объёме. Сначала мы передаём диагностику и приоритеты. Внедрение можно оценить отдельно, а материалы можно передать другому исполнителю.

Решит ли добавление индекса проблему с базой данных?

Иногда правильный индекс помогает, но не для каждого запроса и не в любой ситуации. Сначала мы проверяем план выполнения, объём обрабатываемых данных и способ использования запроса приложением.

Какие технологии вы можете проверить?

Чаще всего мы работаем с приложениями на PHP и Laravel, интернет-магазинами и связанными с ними базами данных. Другой технологический стек оценивается до расчёта стоимости, чтобы не обещать анализ, который невозможно провести надёжно.

Возможен ли аудит без ранее настроенного мониторинга?

Да, если проблему можно воспроизвести и материалов достаточно для измерений. Если данных мало, сначала мы можем рекомендовать их безопасный сбор. Такое ограничение будет ясно указано в результате.

Что отправить в начале

В форме опишите:

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

Не отправляйте через форму пароли, API-ключи, копии базы данных или данные клиентов. Безопасный способ передачи необходимых материалов мы согласуем отдельно.

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

CTA: Описать проблему производительности

Технические источники

• Google: Web Vitals - разделение полевых данных и лабораторной диагностики, а также ограничения измерения INP в обычном лабораторном тесте.
• Google: начало измерения Web Vitals - причины различий между лабораторными результатами и данными реальных пользователей.
• PostgreSQL: Using EXPLAIN - план выполнения и фактические данные о выполнении, доступные при анализе запроса.
• MySQL 8.0: Obtaining Execution Plan Information - план выполнения и измерения EXPLAIN ANALYZE.