Наверное, все знают, что один из лучших хостеров для 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, за помощь в решении сложной ситуации.
Увы, это уже намного сложнее 1. сам импорт содержит механизмы, которые могут быть отнесены заказчиком к его коммерческой тайне 2. как следствие, в импорте много специфики, которую тяжело тиражировать
Если вкратце - импорт происходит на основе CSV файлов, с определенной периодичностью. Обмен заказами возможен в обе стороны (изменения в заказе в 1С также выгружаются на сайт, в том числе состав заказа может изменяться). Обмен остатками и ценами происходит отдельно и намного чаще, чем обмен номенклатуры. Инфоблоки создаются "на лету". и много всяких других штук.
Спасибо за статью, Роман! Очень ценная практическая информация. Также увидели, как встроенные инструменты платформы помогают для снижения нагрузки. Чеклист контроля качества - помогает при оптимизации под нагрузку?
Невозможно создать бесконечно оптимизированную систему под любые нагрузки, можно лишь заложить запас прочности на некоторые отклонения. И дотянуть систему под конкретные ресурсы в случае их перерасходования. Если же реальная нагрузка в разы превышает номинальную заявленную в ТЗ (например, через месяц после запуска заказчик решил выгружать не 5000 товаров, а 50000), то это уже мало относится к некоему гарантийному случаю и надо искать некий компромисс.
Андрей, то есть вы в ТЗ закладываете некоторые параметры при, которых сайт обязан работать на выбранном тарифном плане? Количество хитов, количество выгружаемых товаров?
Спрашиваю, потому что для нас это проблема очень актуальна -- при возникновении проблем на сайте мы оптимизируем его бесплатно (так как считаем, что например настройка автокэширования итд, это вопрос качества) в результате несем большие издержки..
Спасибо, Роман! Тоже столкнулись с тем, что пришлось писать свой импорт остатков и цен.
Раньше выгружали и через CSV и прямыми запросами - действительно, все работает гораздо быстрее и нагрузку почти не дает. Потом решили сделать все стандартными средствами и получили кучу проблем - 1С обновляется из сторонней БД раз в час, после чего происходит полная выгрузка: около получаса, сайт просто замирает (VPS)/
Так что, со стандартными модулями нужно быть поаккуратней - знать объем выгрузки на данный момент и в перспективе, частоту обновления, знать про обновление 1С из сторонних источников...
А вообще, Роман, все, что вы описали - круто! Молодцы!
Ребята, я теперь от вас не отстану. Поделитесь скриншотом нагрузки на CPU и MySQL хостера? Падение сохранилось в течении следующей недели или резкое падение нагрузки 22 числа было обусловлено случайностью (смена сервера итд) и было разовым ?
Резкое падение нагрузки на CPU - следствие сброса статистики при переносах на другой сервер. Нагрузка на CPU при полноценном, активном импорте - около 200
Два с половиной года работы хостинга не вызывало нареканий. Единственное, что при смене тарифа на более дорогой в начале года не перенесли сайты на более "мощный сервер", но то что началось два месяца назад описанию не поддается. "Вы превысили нагрузку - отключаем площадку". Ругаться нет сил, переезжаем в мастерхост.
Вадим Хмелевой, скажите, прошло три месяца как вы переехали - что изменилось? сколько платите? какие ресурсы требуются? стало ли лучше? или хуже? Расскажите!
Друзья, никак не можем разобраться с проблемой очень медленного импорта из 1С в Битрикс. Выгрузка 30000 товаров происходит более 7 часов. Импорт стандартный, выгружаются основные параметры и несколько свойств - никаких картинок или описаний! Подскажите, куда рыть! Может быть кто-то решил для себя эту задачу - готовы расмотреть Ваши предложения.
Нагрузка БД (графики с серой подложкой) - таймвебовские. Before, After1, After2 - логирование в самих скриптах и эксель. Load - выборки из монитора производительности битрикса, агрегация через google spreadsheet (там проще с данными работать, чем в экселе) и визуализация в их же плэйграунде их же графиками.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».