Наверное, все знают, что один из лучших хостеров для 1С-Битрикс - это Timeweb Очень много как партнеров 1С-Битрикс, так и просто сайтов работают на этом хостинге.
Для моей компании Timeweb в настоящее время является основным хостинг-партнером - у нас размещено на нем более 220 аккаунтов клиентов. Мы работаем с Timeweb в режиме интегратора и не скрываем для наших заказчиков, что хостинг предоставляет именно Timeweb, а мы являемся только агентами.
В целом линейка тарифов у Timeweb достаточно сбалансирована до определенного уровня - пока сайт не начнет генерировать высокую нагрузку на тариф Eterno[B]. После этого владельцу сайта необходимо либо переходить на Premium тариф, либо выбирать VPS а затем выделенный сервер. Как правило, это случается всегда неожиданно и владелец сайта психологически не готов платить после 825 рублей/месяц например, 4000 рублей/месяц.
В последнее время многие партнеры 1С-Битрикс высказывают нарекания в сторону Timeweb из-за "неожиданного" и "необоснованного" роста нагрузки на аккаунты клиентов. Несомненно, бывает всякое, однако, хочу поделиться нашим опытом снижения нагрузки на достаточно крупный интернет-магазин.
[spoiler] Итак, в сентябре 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, за помощь в решении сложной ситуации.
ну по производительности Таймвеб хорош. По стабильности - не очень. То и дело мне приходят от яндекс.метрики сообщения недоступности сайтов. Раз в полгода стабильно умирает на несколько часов из-за какой-нибудь аварии. Думаю, что это проблемы роста - не хватает рук всё контролировать, вот и сыпется. Но сам я там уже года два, всех своих клиентов стараюсь туда переводить сразу, чтобы из-за дурацкого хостинга на свебе или hc.ru не было претензий ко мне, что сайт умер.
На разработанных нами интернет-магазинах сейчас в канун нового года наблюдается сезонный взрыв посещаемости (рост в 2-4 раза) и продаж. Соответственно наблюдается нагрузка на сервер хостера.
Оптимизация скриптов импорта позволила выявить несколько мелких и часто незаметных ошибок: - выполнение запроса в цикле - выборка по неточному совпадению (в паре мест использовался Like вместо точного совпадения) В результате загрузка была снижена в более чем 5 раз!
Вы используете стандартный обмен с 1С ? Если он действительно может нагружать хостера в 5 раз меньше, то Битрикс должен в срочном порядке ввести правки в свои скрипты и выпустить обновления! Так как до 25% нагрузки на сервер хостера это именно обмен с 1С.
Роман, нагрузку определяют посещаемость и количество страниц сайта, поделитесь этой информацией по данному проекту?
Внесу свой вклад в пост Романа добавив немного нашей статистики:
Красноярский интернет-магазин ~1000 уникальных посетителей в сутки ~3000 хитов в сутки ежедневно из 1С выгружается порядка 18000 товаров (каждый имеет свою страницу на сайте)
Сайт размещен у нашего любимого хостера ТаймВеб и последние 2 недели мы ведем борьбу за понижение нагрузки чтобы вписаться в отведенные хостером лимиты. Ситуация на данный момент следующая:
Нам интересно экспертное мнение коллег, адекватна ли нагрузка на сервер хостера оказываемая проектом при известных вводных данных?
у меня чуть меньше нагрузка, но на площадке 4 сайта, один из них тяжелый аж пипец - 25 гб занимает, в инфоблоках порядка 100 тысяч разных записей, примерно столько же картинок всяких, а трафик всего 700 уников / 4500 хитов в сутки. Я борюсь с этой нагрузкой и вижу, что есть перспективы для ее снижения в разы, только вот руки не доходят сделать, проекты-то свои.
Стандартный тормозит из-за своей же гибкости и универсальности. Если его несколько кастомизовать под конкретную задачу, можно добиться не десятикратного, но всё же существенного прироста скорости работы. Значительного ускорения можно добиться лишь отказом от использования большинства api-вызовов и прямыми обращениями в БД
Если вопрос был ко мне, то: для обмена сайта с 1С Предприятие 8.2 используется стандартный модуль битрикс (т.е. — XML). Периодичность для всех товаров — раз в сутки. Сегодня сменили тарифный план на Премиум, когда новогодний ажиотаж спадет — перейдем обратно на Eterno[B].
Было бы здорово, если бы вы в следующей статье описали нестандартный функционал взаимодействия 1с и битрикс в данном интернет магазине, очень интересно.
Пост хороший, спасибо. А вот работа Таймвеб последние пару месяцев вызывает множество нареканий... минут 15-20 сайт показывает 502 ошибку примерно раз в два-три дня
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».