Оптимизация работы проекта

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

Были проведены следующие мероприятия:

• Настроен сбор логов на серверах. При этом обработка awk показала наличие долгих очень медленных хитов.
• Настроен сбор аналитики на серверах проекта, чтобы стало видно, насколько загружены сервера и какой у веб-системы резерв. Результат показал, что система не загружена.
• Установлен XHProf и настроено сохранение трейсов в файлы с административной частью. Результат показал несколько проблемных мест: проблемы с запросами к базе данных, медленный старт сессии.

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

  Нагрузочное тестирование веб-кластера

Было проведено нагрузочное тестирование веб-кластера, при котором были получены достаточно хорошие результаты: при нагрузке 25 сайтов одновременно (они в одной базе данных - многосайтовость на веб-кластере), с помощью Яндекс.Танк система уверенно держит ~600 запросов в секунду (52 млн. хитов в сутки) на одной базе данных и трех веб-интерфейсах за балансировщиком при требуемых в ТЗ 300 хитах в сек.

Но при этом были отмечены следующие риски и даны рекомендации:

• Нагрузка проводилась всего 15 минут, а рекомендуется не менее суток, поскольку:
  • периодическая, раз в N часов (по-разному), активность пула буферов InnoDB по вытеснению измененных страниц на диск может потребовать донастройки либо серьезно замедлит скорость работы кластера;
  • крон-задачи в операционных системах серверов могут выполняться ночью (и не только) и способны вызывать коллапс, если заранее не позаботиться;
  • аналогично с агентами Bitrix Framework.
• Очень мало свободной памяти на БД, а при нагрузке она довольно интенсивно наполняется. Таким образом, скоро БД перестанет помещаться в ОЗУ и начнет работать очень медленно. Рекомендуется увеличить ОЗУ до такого значения, при котором БД поместится в него - до 32/64 ГБ и выше. Конечно, делать это нужно при наличии технической возможности, но для такого крупного проекта это лучше не откладывать.
• По результатам нагрузки непонятно, какие типы запросов выполнялись к базе данных – выборки, обновления, вставки или удаления. Рекомендуется протестировать, как выполняются обновления.
• Рекомендуется провести тестирование с подключенным slave-сервером БД.

  Технический бриф

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

Предприняты были следующие меры:

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

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