В декабре 2014 специалисты сервиса loaddy.com провели нагрузочное тестирование систем управления сайтами, результаты которого были опубликованы на CMS Magazine. Тогда исследование получило определенный резонанс, особенно среди участников тестирования. Представители разных CMS высказывали некоторые замечания, критикуя методологию проведения тестов, но в главном отмечали, что для высоких нагрузок каждая система должна оптимизироваться и настраиваться.
Поэтому было решено провести второй тур нагрузочного тестирования с учетом пожеланий участников, и более того, позволить участникам настроить свои системы по своему усмотрению.
Второй тур нагрузочного тестирования CMS для интернет-магазинов
В данном тестировании было решено воспользоваться услугами хостинг-компании AdminVPS.ru. Выбрана именно эта компания по следующим причинам:
1) У них используется KVM виртуализация. О ее преимуществах будет написано ниже.
2) Опыт работ с их серверами показал, что внутренних и внешних проблем во время тестирования не будет. Все работает стабильно.
3) Они бесплатно выдали сервера на весь период тестирования, а также выдали их на ноде, которая была загружена на 10%, за что им большая благодарность.
Каждому представителю CMS был выделен одинаковый VPS-сервер с любой ОС на выбор. По умолчанию это был образ Centos с предустановленной панелью управления ISPmanagerLite для удобства администрирования. Данный образ был изначально оптимизирован хостером для работы всех CMS и успешно используется для обычных клиентов.
Каждый участник из списка тестируемых CMS имел право выполнить любые оптимизации сервера, вплоть до полной переустановки ОС. Только две системы не выделили представителей для настройки своих продуктов, это ShopScript и 1С-Битрикс, однако они были готовы контролировать процесс и консультировать по всем возникающим вопросам.
К сожалению, с CMS ShopScript возникли проблемы, система не устанавливалась. После консультации оказалось, что нужно проделать группу манипуляций с установщиком, система установилась. Однако, при заполнении товарами ShopScript неожиданно выпала в серверную ошибку, которую авторы CMS никак не прокомментировали. Тогда было принято решение вообще исключить ShopScript из тестирования.
Специально для 1С-Битрикса была установлена последняя пятая версия 1С-Битрикс окружения на Centos 6. Все дополнительные пожелания 1С-Битрикс были учтены, а именно были отключены контроль активности и Проактивная защита.
В этот раз от каждой CMS требовалось создать интернет-магазин, как если бы его сделали под клиента. То есть, у сайта должен быть дизайн, наполнение категориями, карточки товаров с изображениями, цены и пр. Дизайн и статика в нагрузке на сервер играют минимальную роль, и об этом будет сказано еще раз чуть ниже.
Подготовка к тестированию
Железо
В качестве сервера был выбран сервер следующей конфигурации:
Cтрана: Германия
CPU: 3400 Mhz (1 ядро)
RAM: 1024 Mb
SSD диск: 10 gb
Программное обеспечение
На сервере по умолчанию установлена связка Nginx + Apache в многопоточном режиме itk. Это значительно экономит ресурсы сервера и отдает статику из кеша сервера. Таким образом, нагрузка от отдачи статических файлов занимает не более 2−4% от общей нагрузки сервера. PHP работает в режиме модуля веб-сервера. Любой представитель CMS мог настроить сервер по своему усмотрению на свой страх и риск.
По просьбе 1С-Bitrix была дополнительно установлена VM Bitrix v5, которая специально оптимизирована под их систему.
Соседи
Вероятность влияния соседей по физической ноде исключены по следующим причинам:
- Данная нода не была нагружена в момент проведения тестирования. Время в большинстве случаев было специально выбрано ночное.
- Использовалась закрытая система виртуализации KVM, которая минимизирует влияние других . Даже если каким-то чудом на ноде была нагрузка ночью, ее влияние на наши тестирование минимальны.
- Везде стояли SSD диски в RAID10, поэтому проблема IOPS также исключена. WA% (задержки ввода-вывода) составляло не более 0.4−0.5% во время тестирования.
Статика
Сервис Loaddy.com не скачивает статические файлы по одной простой причине. Это не нагружает как php, так и базу данных, что нам в принципе и надо. Вы спросите почему? Многочисленные тестирования показали, что:
- Пользователь скачивает 80−90% статики при первом открытии сайта, а потом запросы кешируются в его браузере.
- Нагрузка на сервере от отдачи статистических файлов минимальна и не влияет на общую производительность сервера. По крайней мере, если это связка apache + nginx, которую мы использовали в тестировании, то при такой настройке всё отдается из кеша, что не влияет на конечную нагрузку на сервер.
В новой версии Loaddy.com появился новый показатель скорости загрузки всего сайта. В нашем тестировании его использование нецелесообразно, т.к. кол-во статики и других элементов на сайте может сильно отличаться. Мы же будем тестировать, как и в прошлый раз, показатель TTFB (Time To First Byte) и конечно показатель доступности. TTFB показывает, сколько требуется времени серверу, чтобы сгенерировать ответ на запрос пользователя. Доступность — это 100% минус отношение количества ответов кодом выше 400, т.е. ошибкам сервера к успешным ответам от сервера (кодом ниже 400).
Тестирование
Нагрузочное тестирование проводилось с помощью онлайн-сервиса Loaddy.com.
В процессе тестирования на каждом сайте открывались 3 страницы, которые чаще всего посещают клиенты, а именно:
- Главная страница сайта
- Страница категории товаров
- Страница карточки товара
Все страницы посещались в хаотическом порядке. Как правило, две последующие ссылки категории и карточки товара открывались в 30−40 процентном отношении каждая и около 10−20% главная страница. Это эмулирует наиболее естественное поведение пользователя, который открывает один раз главную страницу сайта и потом ищет товар по категориям. Нагрузка происходила следующим образом: каждые 10 секунд на сайт переходит определенное количество посетителей в хаотичном порядке.
В отличие от первого тестирования, где проводилось тестирование только с «равномерной нагрузкой», на этот раз мы запланировали дополнительный режим тестирования «возрастающая нагрузка». Плюс возрастающей нагрузки в том, что можно получить конкретное число пользователей, при которых сайт перестает отвечать. Таким образом, можно будет понять, какая система наиболее экономно расходует ресурсы сервера из тех, что одновременно выбыли при равномерной нагрузке.
100 человек / 10 минут
Первый тест показал, что только NetCat не справилась с нагрузкой. В предыдущем тестировании NetCat также выбыла при посещаемости в 100 человек, однако в этот раз показатели даже чуть меньше, но сопоставимые. Возможно, дело в производительности нового сервера, у которого чуть меньше памяти, чем в прошлый раз. Остальные CMS с нагрузкой справились достойно. Налицо положительные доработки аутсайдеров прошлого тестирования, систем CS-Cart (1,4% доступности) и 1С-Битрикс (2,91%), в этот раз показавшие 100%.
8) NetCat — 73,6% - выбывает (http://loaddy.com/result/473686884/)
Увеличиваем нагрузку до 200 посетителей.
200 человек / 10 минут
Тут уже выбыла CMS 1С-Bitrix с результатами 73% доступности. Все остальные CMS с нагрузкой 200 человек справились на 100%. Стоит заметить, что CS-Cart показала результат — 99,84%, тем не менее, это практически 100% и вполне целесообразно списать 0.16% на погрешность и протестировать систему в следующем этапе.
7) 1С-Bitrix — 73,51% - выбывает (http://loaddy.com/result/343115949/)
Нужно отметить, что первоначальные цифры результатов тестирования 1С-Битрикс при нагрузке 200 человек были несколько хуже. Представители системы проверили результаты и посоветовали включить «композитный режим», что намного улучшило показатели. Но тем не менее, за цифру в 200 человек 1С-Битриксу перешагнуть не удалось.
Дополнительные пристальные проверки 1С-Bitrix повторно показывали, что система с нагрузками не справляется. По мнению авторов исследования это может быть из-за существенного объема HTML-источника загружаемых страниц (в несколько раз больше других участников), что в свою очередь является следствием загрузки всех подряд модулей по умолчанию (повторимся, мы не учитываем размер статических фалов, css, js и прочих).
Не понятно, почему разработчики Битрикса до сих пор не прислушиваются к повальным жалобам пользователей на прожорливость своей CMS. Если бы не «все сразу» в модулях 1С-Битрикс, то возможно эта CMS работала бы лучше многих других. Пользователям системы 1С-Битрикс же можно только рекомендовать обязательно включать «композитный режим» и отключать антивирус и защиту от атак, тогда можно достичь более-менее приличной производительности. К слову, в тестировании использовалась редакция «Бизнес»
500 человек / 10 минут
Для оставшихся систем была дана нагрузка в 500 посетителей. К сожалению, на этом этапе СS-Сart всё-таки подтвердила свой предыдущий результат и почти сразу «упала» с ошибкой базы данных. Несмотря на результат 98,11%, ошибка базы видна по времени ответа, которое почти равно нулю. При ручной проверке и заходе на сайт в момент тестирования оказалось, что результат 98.11% обеспечивала «заглушка» с сообщением об ошибке в БД, которая в CS-Cart отдает код ответа 200.
Остальные CMS успешно выдержали нагрузку. Очевидно, старания представителей систем по оптимизации своих детищ не прошли зря.
6) СS-cart — 0% - выбывает (http://loaddy.com/result/349296747/)
750 человек / 10 минут
Среди оставшихся CMS (DIAFAN.CMS, Amiro.CMS, HostCMS, Simpla, UMI.CMS) была выполнена проверка восприимчивости нагрузки в 750 посетителей и все справились с ней хорошо. Еще раз нужно отметить, что при правильной оптимизации и настройке CMS, можно на порядок улучшить производительность сайтов. Это доказывают результаты настоящего тестирования.
При тестировании с нагрузкой в 750 человек была небольшая проблема с UMI.CMS — упал MySQL-сервер. Возможно была какая-то проблема с настройкой конфигурации баз данных со стороны разработчиков UMI, тем более, что они выбрали режим работы php-fpm, либо какой-то случайный сбой. Тем не менее, повторные тесты при 750 посетителях не показали падения БД, поэтому оставляем UMI.CMS в строю.
1000 человек / 10 минут
Следующая проверка была с нагрузкой 1000 посетителей. Честно признаться, не ожидалось, что хоть какая-то CMS дойдёт до таких результатов, даже после тонкой настройки систем разработчиками. Однако факт есть факт, 5 CMS успешно работали под нагрузкой 1000 (тысяча) одновременных посетителей.
К сожалению, UMI.CMS подтвердило проблему с БД и упала сразу.
Поскольку, 100% показала только одна CMS, на этом этапе тестирование было решено остановить тестирование.
5) UMI.CMS — 0,24% (http://loaddy.com/result/770697358/)
4) Simpla — 79,46% - (http://loaddy.com/result/690145202/)
3) HostCMS — 96,6% (http://loaddy.com/result/730390176/)
2) Amiro — 97,56% (http://loaddy.com/result/271678480/)
1) DIAFAN — 100% (http://loaddy.com/result/457084395/)
Результаты нагрузочного тестирования
Победителем безоговорочно оказалась DIAFAN.CMS. Она успешно выдержала нагрузку в 1000 посетителей, причем со скоростью ответа как у html-страницы. Было даже подозрение, что разработчики не настраивали систему, а просто сделали html-каркас, т.к. таких быстрых ответов на практике авторов исследования не было.
Однако переписка с разработчиками DIAFAN.CMS, их объяснения использованных алгоритмов кеширования, поверхностный анализ исходного кода и многочисленные пристальные тестирования именно этой CMS не оставили ни одного сомнения — она явный фаворит. Никакого HTML-каркаса, все запросы проходили через ядро DIAFAN.CMS, и системой можно было пользоваться под нагрузкой, весь функционал сайта работал, в частности можно было спокойно положить товары в корзину и оформить заказ.
Для перепроверки результатов, было решено дать на все сайты возрастающую нагрузку с 100 до 1000 посетителей. Шаг между возрастанием — 10 посетителей. На графиках можно увидеть, когда начинаются проблемы с ответами и как при этом изменяется время ответа и скорость загрузки сайта. Если скорость загрузки сайта равна нулю, значит сработал тайм-аут, который равен 15 сек.
Результаты:
- DIAFAN.CMS — 100% (http://loaddy.com/result/16221637/)
- Amiro.CMS — 99,16% (http://loaddy.com/result/281428664/)
- HostCMS — 98,82% (http://loaddy.com/result/850228761/)
- Simpla — 95,13% (http://loaddy.com/result/688409729/)
- UMI.CMS — 82−99,99%* (http://loaddy.com/result/618012088/)
- CS-Cart 45%* (http://loaddy.com/result/541326022/)
- NetCat — 35% (http://loaddy.com/result/205218383/)
- Bitrix — 2.8% (http://loaddy.com/result/797184071/)
UMI.CMS показала почти 100% на всем протяжении возрастающей нагрузки вплоть до 1000 посетителей, однако, если обратить внимание на график, видно, что на 1360 сек. скорость загрузки падала до 0, что означает, что сайт загружался дольше 15 сек. или вовсе не загружался. Также время ответа (Time To First Byte) достаточно высокое, по сравнению с другими претендентами. Однако спустя пару секунд сайт «отмирал». Можно считать, что у UMI.CMS начинаются проблемы при 820 посетителях (82%).
В случае с СS-Сart сложно точно выяснить, на каком этапе падает сайт, т.к. заглушка коннекта к БД от самой CMS отдает ответ с кодом 200. Однако, можно предположить, что это происходит на 680 секунде, когда время ответа сильно возрастает (график справа) и затем снова падает. То есть, CS-Cart выдерживает примерно 450 посетителей, что является очень хорошим результатом, особенно по сравнению с предыдущим тестированием.
Что касается 1С-Bitrix и NetCat, они поменялись местами по сравнению с предыдущим тестированием. Но если посмотреть графики, то у обоих абсолютно неадекватное поведение на нагрузку. Bitrix падает сразу, NetCat падает тоже сразу, но потом иногда выдает успешные ответы чередуясь с ошибками.
Выводы и рекомендации разработчикам CMS
Хотелось бы обратить внимание разработчиков каждой CMS на следующие моменты:
1С-Bitrix — не стоит подключать все модули сайта по умолчанию и подгружать их при каждом открытии страницы. Размер ответа при тестировании показывает, что это влияет только отрицательным образом на работоспособность сайта.
Amiro.CMS — отличная CMS с точки зрения оптимизации кода и работы под нагрузкой, но лучше также, как и Bitrix уменьшить размер ответа Body. Сейчас он превышает в среднем раз в 5 размер ответа других CMS.
HostCMS — если внимательно изучить график ответов сайта, то можно заметить, что основные падения появляются на первых 10 секундах нагрузки. Возможно, какой-то механизм кеширования срабатывает не так четко, как это нужно. В остальном, все работает идеально.
DIAFAN.CMS — никаких сомнений, что разработчики данной CMS умеют работать с кешем. Хорошие показатели даже по сравнению с обычными html-сайтов.
В целом, данное тестирование — это только соревнование, как спорт ради рекордов. В реальной жизни нагрузки, подобные 1000 одновременных посетителей, очень редки. Все CMS из первой пятерки подходят для массового использования, если они «из коробки» достойно держат такие нагрузки. Остальным же рекомендуется заняться оптимизацией кода и выявлением узких мест. Для кого-то причиной медлительности системы может быть неоптимизированное расходование ресурсов сервера, а для большинства — банальное включение в CMS всего подряд «из коробки» для показа преимуществ перед другими. Ведь многие пользователи не будут выключать лишний неиспользуемый функционал и в итоге хостеры их просто будут выгонять с серверов за нагрузку, причиной которой будет модуль в CMS, который даже не используется.
