Нагрузка на аккаунт на серверах Timeweb: пример успешного снижения

Наверное, все знают, что один из лучших хостеров для 1С-Битрикс - это Timeweb Очень много как партнеров 1С-Битрикс, так и просто сайтов работают на этом хостинге.

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

В целом линейка тарифов у Timeweb достаточно сбалансирована до определенного уровня - пока сайт не начнет генерировать высокую нагрузку на тариф Eterno[B]. После этого владельцу сайта необходимо либо переходить на Premium тариф, либо выбирать VPS а затем выделенный сервер. Как правило, это случается всегда неожиданно и владелец сайта психологически не готов платить после 825 рублей/месяц например, 4000 рублей/месяц.

В последнее время многие партнеры 1С-Битрикс высказывают нарекания в сторону Timeweb из-за "неожиданного" и "необоснованного" роста нагрузки на аккаунты клиентов. Несомненно, бывает всякое, однако, хочу поделиться нашим опытом снижения нагрузки на достаточно крупный интернет-магазин.


Итак, в сентябре 2011 мы запустили проект для одной из ведущих региональных компаний на российском рынке информационных технологий - компании НЭТА. Все было хорошо, нагрузка на сервер была совсем маленькой  - в октябре 2011 нагрузка на процессор колебалась от 100 до 200 единиц, а нагрузка на базу - менее 30 единиц. И как вдруг раз - и со 2-го ноября нагрузка на базу резко возрастает - до 20 000 единиц!

Первая реакция - "Что случилось?" и "Так не может быть! Это сбой подсчета статистики!". Думаю, что такая реакция была бы у любого разработчика.
Естественно, что первым делом мы подумали, что выросла посещаемость. Но нет - прирост был не очень значительным, и это не должно было сильно повлиять. Вторым - что Timeweb ошибается. Здесь важно рассказать о том, как считается нагрузка на аккаунт.

Для мониторинга за нагрузкой CPU используются данные утилиты sa. В качестве показателей нагрузки mysql используется процессорное время, затраченное за выполнение sql-запроса (используются percona'вские версии mysql)

Предположение, которое сразу же высказал нам Timeweb - что нагружает импорт - требовалось проверить. После обсуждения директор Timeweb, Дмитрий Тарасов, сделал нам предложение, от которого сложно было отказаться - выделил нам на время тестирования отдельный сервер, на котором мы могли бы проверить все свои предположения. Сервер был настроен также, как и стандартный хостинг-сервер, и у нас были те же самые права. Т.е. у нас не было паролей от root (ни от сервера, ни от MySQL).

Сначала мы решили проверить, не вызван ли рост нагрузки тем, что на старом сервере другие аккаунты стали "есть" больше ресурсов и в результате у всех выросла нагрузка. Увы (или к счастью) это не так, и статистика Timeweb действительно не зависит от загрузки сервера.

Далее наступила очередь импорта-экспорта данных. Сайт очень активно обменивается данными с 1С, и, как мы понимаем теперь, скорее всего в ноябре объем реально обмениваемых данных резко вырос.
Оптимизация скриптов импорта позволила выявить несколько мелких и часто незаметных ошибок:
- выполнение запроса в цикле
- выборка по неточному совпадению (в паре мест использовался Like вместо точного совпадения)
В результате загрузка была снижена в более чем 5 раз!

Дополнительно, мы включили в импорт проверку на изменение данных. Теперь, если данные не изменились, система не обновляла их.
Это позволило снизить нагрузку еще сильнее. Итоговая нагрузка на MySQL снизилась более чем в 10 раз!


Красный - нагрузка на MySQL до оптимизации
Синий - после устранения недочетов импорта
Зеленый - после доработки импорта (убрали обновление неизмененных данных)

Дополнительно мы решили оптимизировать загрузку страниц. Важно отметить, что проект непростой - у компании несколько городов с несколькими магазинами в каждом городе. Цена на товар зависит от города, а наличие в городе зависит от наличия в магазинах. В итоге на вид простая главная страница генерировала достаточно много запросов к базе данных (когда был хит мимо кэша). Оптимизация кэширования и работы компонентов позволила выиграть от 30 до 50% скорости загрузки страниц, и, хотя это и было необязательно, это снимет много потенциальных проблем в будущем.

Результат оптимизации страниц:

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

Результат борьбы с нагрузкой вы можете увидеть на рисунке:


На графике хорошо виден всплеск нагрузки на MySQL в начале ноября и последующий спад в зеленую зону после оптимизации. Падение нагрузки на CPU в крайнем справа значении графика - это из-за переноса на другой сервер (сбросилась статистика).

В целом по результату оптимизации мы сделали такие выводы:
1. Для интернет-магазинов в стоимость включать проверку не только под нагрузкой на посещаемость, но и уточнение объемов и частоты обмена данными
2. Механизмы расчетов, которые изучаются в курсе "Численные методы" в университете, нужно применять и в вебе. Пока сайт маленький или данных немного - работает любой способ. Затем, при росте объема данных, рост нагрузки может стать квадратичным из-за маленькой ошибки в вызове скрипта (например, где-то стоит маленький полный перебор).
3. Статистика Timeweb не врет.
4. Теперь у нас есть администрируемый Timeweb сервер со спецтарифами для "тяжелых" клиентов.

Важно отметить еще несколько вещей, которыми я руководствовался при принятии решений:
1. VPS и сервер в Германии - не панацея. Связано это с необходимостью администрировать сервер и VPS. Я являюсь поклонником shared хостинга, потому что в этом случае за нашими сайтами следят профессионалы. И они быстрее заметят проблему, потому что это - их работа.
В случае VPS или своего сервера затраты на администратора будут очень значительными.
2. Сами мы хостингом заниматься не хотим. Это очень дорого и требует значительных вложений, прежде всего в сотрудников - администраторов и поддержку.

Всю работу по оптимизации сайта выполнял Андрей Нейман, наш технический директор

Благодарности:
Дмитрию Тарасову, директору Timeweb, за помощь в решении сложной ситуации.