Даже если во время разработки веб-проекта постоянно думать об оптимизации и производительности и следить за тем, что:

• компоненты не выполняют в режиме автокеширования запросы к базе данных;
• в кеше компонентов не сохраняются лишние данные и объем кеша не превышает 1МБ;
• в теле компонентов не выполняются интенсивные вычисления и не практикуется интенсивное использование больших объемов оперативной памяти (подобные операции не должны выполнятся в момент построения страницы для передачи в бразуер Посетителя; рекомендуется их выносить в периодические cron-операции, выполняемые в фоновом режиме или по технологии асинхронных очередей)

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

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

Для получения близких к реальным условиям эксплуатации результатов, желательно загрузить в веб-проект ожидаемый объем тестовых данных. Например, если в системе ожидается 2 миллиона учетных записей, 100 000 товаров в 10 000 разделах и форум, хранящий миллион сообщений с посещаемостью 500 000 хитов в сутки - необходимо импортировать в веб-проект тестовые данные в данном объеме. Также, что очевидно, следует проводить нагрузочные испытания на серверном оборудовании идентичном или максимально приближенном к реальному.

Сценарии нагрузочного тестирования различаются по степени сложности и варьируются от кратковременного коллективного тестирования веб-проекта сотрудниками компании ("коллеги, сегодня с 16 до 16:10, пожалуйста, походите по сайту, выполняя следующие действия …") до комплексных имитаций пользовательских цепочек на сайте с использованием таких инструментов, как JMeter, WAPT и т.п. Вот пример методики организации и проведения нагрузочного тестирования. В "крайнем" случае, при недостатке времени, можно провести "экспресс" нагрузочное тестирование после запуска веб-проекта в эксплуатацию и оперативно исправить возникшие недостатки.

1. Убеждаемся, что веб-проект заполнен тестовыми данными в объеме, приближенном к реальным условиям эксплуатации и тестирование проводится на аппаратной конфигурации ,приближенной к реальной.
2. На административной странице в разделе "Настройки > Производительность > Панель производительности" нажимаем "Тестировать производительность" в течение 10 минут (или более, для получения более качественных результатов).
   1. Создается нагрузка на веб-решение: или по сайту ходят сотрудники компании, выполняя заранее описанные действия, или хотят реальные пользователи, или нагрузку создает инструмент типа JMeter, WAPT и т.п. Желательно, чтобы уровень нагрузки и ее характер был приближен к реальному. Например, если ожидается миллион хитов в сутки, нужно постараться создать данную нагрузку.
   2. Во время нагрузки на веб-проект необходимо самостоятельно пройти по нескольким цепочкам и визуально оценить следующее:
      • страницы веб-проекта открываются быстро, не зависают
      • изображения веб-страницы загружаются визуально быстро.
      Фактически, просматривая в браузере веб-проект, находящийся под нагрузкой, вы смотрим на него и оцениваем производительность "глазами клиента".
3. После завершения нагрузочного теста анализируем результаты на вкладке "Разработка" (Настройки > Производительность > Панель производительности):
   • Просматриваем список "20 самых нагружающих страниц".
   • Результаты в колонке "Среднее время (сек)", отображающие время построения страницы на сервере, не должны превышать 0.5 сек. Результаты в 1 и более секунды говорят либо о недостаточно оптимизированной веб-странице/конфигурации PHP, либо о недостаточной производительности аппаратной конфигурации - в общем, требуют вмешательства и исправления.
   • В колонке "Ошибки разработки" не должно быть сообщений об ошибках. Найденные ошибки требуют исправления.

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