Закрыть
E-mail:
Пароль:
Забыли пароль?
В каталоге проекта: 10 268 веб-студий, 897 CMS, 195 780 сайтов.
РегистрацияCMS MagazineВход
CMS Magazine CMS Magazine

Нагрузочное тестирование CMS для интернет-магазинов

В рамках исследования была протестирована устойчивость к нагрузкам 9 систем управления сайтами из ТОП10 самых популярных CMS для интернет-магазинов по версии CMS Magazine.

Авторы исследования: Loaddy.com

Предисловие редакции

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

Выбор CMS и сервера

В ноябре 2014 года нам поступило предложение провести сравнительное нагрузочное тестирование коробочных систем управления сайтами. Для тестирования были выбраны 9 систем управления сайтами из ТОП10 самых популярных CMS по версии CMSmagazine.ru.

Список CMS

 

Функиональность у всех систем схожая, и включает:

  • Категории товаров с неограниченной вложенностью, с изображениями и описаниями

  • Динамические характеристики с поддержкой зависимости цены от комплектации

  • Бренды товаров

  • Фильтры, сортировки и гибкий поиск по товарам

  • Сравнение товаров

  • Возможность продажи цифровых товаров

  • Покупка в один клик

  • Сопутствующие услуги

  • Автоматическая поддержка режима «С этим товаром покупают» и блок «похожие товары»

  • Выгрузка в Яндекс.Маркет

  • Синхронизация с 1С:Предприятие

  • Учет количества товаров на складе

  • Гибкая система скидок, скидочные купоны, назначение скидок по типам покупателей, скидки от суммы заказа, накопительные скидки и т.д.

  • Методы online-оплаты: WebMoney, Яндекс.Деньги, QIWI и пр.

  • Баланс покупателей с возможностью пополнения и оплаты с него

  • Валюты

  • Отложенные товары

  • Конструктор формы заказов

  • Списки ожиданий

Платформа для тестирования была любезно предоставлена хостиновой компанией IT-MCP. Это оказался VPS-сервер из дата-центра в Германии, с SSD-диском, 3,5GHz и 1,6Gb оперативной памяти.

Параметры хостинга Параметры виртуального сервера CMS отделены друг от друга

Установка CMS

Каждая система инсталлировалась в стандартном варианте, с поддержкой интернет-магазина, по возможности без демо-данных. Попутно были оценены размеры и объемы, занимаемые той или иной системой на сервере, от инсталла до готового сайта.

CMS Размер установщика Комментарии
AMIRO.CMS 26Mb Архив системы самостоятельно не устанавливается, необходимо дополнительно качать РНР-установщик.
1С-Битрикс 163Mb Были небольшие сложности с конфигурацией сервера, т.к. не все параметры площадки устраивали установщик. Но после некоторых манипуляций с правами и настройками на хостинге всё установилось без проблем.
CS-Cart 70Mb После копирования установщика сайт выпал в ошибку 500. Погуглив, пришлось кое-что править в .htaccess, чтобы запустить систему. На шаге ввода параметров БД инсталлятор заставил переименовать базу БД, удалить из имени дефис.
DIAFAN.CMS 4Mb Установилась быстро и без проблем
HostCMS 8Mb Установилась быстро и без проблем
NetCat 63Mb Архив NetCat на хостинге системным архиватором не распаковался. Пришлось переупаковать в zip и загрузить заново. Но после распаковки на сервере система установилась мгновенно буквально в 3 шага.
Shop-Script 7Mb Пакет Shop-Script архиватором хостинга также не распаковался, пришлось переупаковать. После распаковки сайт выпал в ошибку 500, пришлось править .htaccess, погуглив. Но затем система установилась достаточно быстро.
Simpla 13Mb Установилась быстро и без проблем
UMI.CMS 2kb Такой небольшой размер — это установщик, который закачивает на хостинг инсталляционные файлы (>100Mb) самостоятельно. Установилась быстро и без проблем.

После установки можно было оценить объем БД, занимаемый разными системами.

Объем БД, занимаемый разными CMS

Заполнение CMS товарами

Для тестирования был подготовлен CSV-файл с товарами, чуть более 1200 наименований. Название товара и его цена. Этот файл было необходимо импортировать в каждую систему.

CSV-файл для импорта товаров

HostCMS

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

Импорт товаров в HostCMS

Shop-Script

Shop-Script, как и HostCMS обладает прекрасным модулем импорта. Достаточно загрузить CSV-файл, указать чем является каждое найденное им поле и всё.

Импорт товаров в ShopScript

DIAFAN.CMS

В DIAFAN.CMS пришлось под CSV-файл «подогнать» модуль импорта, удалив лишние поля. Но достаточно быстро и просто, кликая мышкой. Товары импортировались неактивными, но благодаря групповым действиям в списке товаров их получилось активировать также очень быстро.

Импорт товаров в DIAFAN.CMS

1С-Битрикс

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

Импорт товаров в 1С-Битрикс

Simpla

Simpla требует, чтобы первой строкой в CSV-файле были названия полей со стандартными для системы именами. После правки CSV-файла, товары успешно и быстро импортировались.

Импорт товаров в Simpla

Импорт товаров в Simpla

CS-Cart

CS-Cart также требует, чтобы первой строкой в CSV-файле были определенные названия полей со стандартами системы. После чего товары успешно и быстро импортировались.

Импорт товаров в CS-Cart

UMI.CMS

В UMI.CMS система импорта не очень лаконичная и интуитивно понятная для новичка. Пришлось много гуглить, чтобы определить какого формата, с какими полями и с какими заголовками должен быть CSV-файл. Необходимо обязательно указывать колонку с уникальным id товара и&nbsnbsp;обязательно указывать активность товара, иначе после загрузки товаров их придется активировать вручную по одному, ведь групповых действий в системе нет. Плюс ко всему, необходимо первыми тремя строками указывать системные имена полей, их тип и название.

Импорт товаров в UMI.CMS

Импорт товаров в UMI.CMS

Импорт товаров в UMI.CMS

AMIRO.CMS

Импорт в AMIRO.CMS с помощью встроенного модуля не удался. Система категорически отказывалась импортировать CSV-файл, либо выдавая ошибку о неверном имени столбца, либо зависая на 00:00. В итоге в AMIRO.CMS товары пришлось импортировать напрямую в таблицу БД, сформировав дамп.

Импорт товаров в Amiro.CMS

Импорт товаров в Amiro.CMS

NetCat

В NetCat импорт товаров вроде как предусмотрен, но чтобы настроить его, предлагается платно обратиться к любому из партнеров-разработчиков. Пришлось импортировать товары также через PHPMyAdmin, напрямую в БД.

Импорт товаров в NetCat

 

После импорта товаров на каждом сайте на первую страницу списка товаров были выведены по 12 элементов на страницу. Таким образом, каждая CMS формирует страницу с одинаковым количеством товаров из одинакового общего количества в БД.

  • AMIRO.CMS
  • 1С-Битрикс
  • CS-Cart
  • DIAFAN.CMS
  • HostCMS
  • NetCat
  • Shop-Script
  • Simpla
  • UMI.CMS
От редакции



На каких CMS чаще всего делают интернет-магазины в России? Ответ на этот вопрос вы найдете в cоответствующем рейтинге.

Также предлагаем ознакомиться с актуальными данными по остальным типам сайтов (порталы, корпоративные и промо-сайты) и конкретным видам CMS (коробочные коммерческие CMS, студийные CMS, Open-source CMS).

Анализ скорости генерации CMS одной страницы

Для измерения скорости генерации одной страницы был использован сервис webpagetest.org. У каждой системы была взята одна и та же страница — та самая страница каталога товаров, первая, где у всех выводится по 12 товаров. Результаты тестирования сервисом WebPageTest весьма обширны, подробны, и для всех сайтов отличаются друг от друга, ведь дизайн везде разный. Но время полной загрузки страницы нас не интересует и вот почему.

Сначала немного теории. Время загрузки страницы состоит из двух частей: собственно, времени генерации HTML-источника страницы и времени дальнейшей подгрузки содержимого страницы, т.е. img+css+js+прочее, всего того, что указано в HTML-источнике. Отдача физических файлов (картинок, css-файлов и пр.) не использует ресурсы сервера (память, процессор), не использует SQL-сервер. Это просто чтение файла. Более того, браузеры кешируют многие файлы, поэтому при повторной загрузке сайта и выводе кешированной картинки сервер вообще почти не задействуется. Зато формирование HTML-источника — это то самое, на что сервер тратит свои ресурсы. Построение страницы производит интерпретатор PHP-скриптов. Делается это при этом очень активно использовании ресурсов сервера: процессора и оперативной памяти, с обращениями к SQL-серверу. И самое узкое место в быстродействии таких связок — это SQL запросы. Чтобы не было проблем, кроме правильной структуры и индексирования БД, должны быть правильно сформированы запросы. Плюс ко всему, интерпретатор PHP не всегда может корректно освободить используемые данные, поэтому обязательным является самостоятельное закрытие соединения с БД (mysql_close). Так же нужно рационально использовать память во время работы скрипта c БД, используя mysql_free, иначе результирующие данные запроса так и останутся в памяти до конца работы интерпретатора.

По своей сути СУБД mySQL — это сервер, который принимает, обрабатывает запросы и затем отдает результаты. Поэтому самое очевидное, что нужно делать для увеличения быстродействия системы — снижение количества SQL запросов по максимуму. Частая проблема в многих CMS — это циклы. Например, простой запрос SELECT id FROM shop WHERE act=1 WHILE { SELECT img FROM shop_img WHERE shop_id = id } - если в таблице 100 записей, и на сайте будет 100 пользователей, будет 101*100=10100 запросов к БД. Надо помнить, что mySQL — это отдельный сервер, запросы к нему идут в бинарном виде по протоколу TCP. Это означает, что РНР-скрипт пошлет 10100 TCP-запросов на порт 3306, забивая сетевую карту сервера их обработкой. А TCP-соединение в UNIX — это файловый дескриптор, объект ядра. 10100 объектов ядра по, как минимум, 4 байта (для хранения его id) 4 * 10100 = 10 кб данных, которые стоят в очереди. И это только один простой запрос выборки id товаров и их картинок. А если у нас на странице сайта выходят товары, похожие товары, комментарии, отзывы о товарах, статистика, дополнительные характеристики товаров и т.д.? Это сотни запросов в десятки таблиц, с возможными циклами. Поэтому, если давать рекомендации, рассматривая наш простой запрос выборки товаров и их картинок, лучше сначала запросить товары SELECT id FROM shop WHERE act=1, сохранить результаты и затем сделать отдельный запрос за картинками SELECT img FROM shop_img WHILE shop_id IN (1,2,3...100) — это всего 2(!) запроса к mySQL от каждого пользователя и всего 2*100=200 запросов к БД, вместо 10100, со всеми вытекающими.

Не менее важное в быстродействии — это использование CMS кеширования. Не браузерного кеширования и не серверного, а внутрисистемного для CMS. Кеширования как результатов запросов, так и внутренних данных скриптов. Это можно достичь разными способами, и желательно использовать несколько. Начиная от статических переменных внутри функций (как локальные хранилища), заканчивая файловым кешем, когда результаты большинства SQL-запросов сохраняются CMS в текстовые файлы и затем используются вместо повторных запросов. И если циклы, неоптимизированные запросы к SQL и отсутствие алгоритмов кеширования не особо заметны при нескольких одновременных посетителях, то когда посетителей он-лайн на сайте 100 и больше, временная разница колоссальна.

Теперь вернемся к нашим графикам на WebPageTest. Самое интересное для нас — это первая строка.

  • DNS Lookup — это время поиска домена в DNS-зонах и определение ip сервера, где лежит сайт

  • Initial Connection — время соединения с сервером и запрос страницы

  • Time to First Byte — время, которое тратится на то, чтобы дождаться получения первого байта сформированного кода HTML-страницы.
    Это как раз то самое время, которое тратит сервер на обработку запросов и команд при работе CMS.

  • Content Download — время на скачивание готовой HTML-страницы

Все остальные строки ниже — это уже ресурсы физического характера: файлы, картинки, css и пр. Это всё имеет отношение к дизайну сайта, а не к CMS. Так как если положить этот же дизайн в виде статических HTML+ресурсы, и дать нагрузку даже в 10.000 посетителей, сервер не повиснет. А вот динамически сформировать такой же HTML даже для 100 одновременных посетителей и не обрушить хостинг — уже задачка для некоторых CMS.

Итак, что мы имеем для каждой CMS? Смотрим зеленую полоску в первой строке и её время.

  • Simpla — 0.16 сек
  • AMIRO.CMS — 0.17 сек
  • DIAFAN.CMS — 0.22 сек
  • Shop-Script — 0.22 сек
  • HostCMS — 0.26 сек
  • NetCat — 0.28 сек
  • 1C-Битрикс — 0.37 сек
  • UMI.CMS — 0.38 сек
  • CS-Cart — 0.51 сек

Как видно, время формирования HTML-источника страницы примерно равное у всех CMS и укладывается в 0.2-0.4 секунды (кроме CS-Cart, у которой 0.5 секунд). В принципе, это всё неплохие результаты для систем управления сайтами и времени динамического формирования страницы. Это время занимает обработка РНР-кода с SQL-запросами и построение HTML-источника. К сожалению, точно узнать, сколько из этого времени занимает обработка РНР-кода, а сколько SQL-запросов, невозможно. Однако это можем проверить это методом нагрузочного тестирования.

Нагрузочное тестирование CMS

Для нагрузочного тестирования был выбран сервис Loaddy.com. Алгоритм активности посетителей был следующий:

  • Входная страница пользователя — первая страница каталога товаров;
  • Далее либо переход на другие страницы каталога товаров по пагинатору;
  • Либо открытие карточки товара;
  • интервалы между действиями пользователей — 5 секунд.

Тестирование проводилось по очереди, на каждую CMS по 10 минут, интервалы между проверками — 1 минута. Сначала была дана нагрузка в 100 человек.

100 человек / 10 минут

  • Результаты тестирования:
CMS 100 чел./10 мин.
(результаты кликабельны)
AMIRO.CMS 100%
DIAFAN.CMS 100%
HostCMS 100%
Simpla 100%
Shop-Script 100%
NetCat 92.19%
UMI.CMS 56.37%
1С-Битрикс 2.91%
Cs-Cart 1.4%

CMS, которые показали менее 100% доступности, выбывают. Это CS-Cart, 1С-Битрикс, UMI.CMS и NetCat.

На оставшиеся CMS было запущено повторное тестирование, с нагрузкой 250 одновременных пользователей. Все остальные условия тестирвания идентичны.

250 человек / 10 минут

  • Результаты тестирования:
CMS 250 чел./10 мин.
(результаты кликабельны)
DIAFAN.CMS 100%
Simpla 100%
AMIRO.CMS 96%
Shop-Script 21.67%
HostCMS 1.7%

CMS, не выдержавшие при 100% доступности 250 пользователей on-line, выбывают в порядке уменьшения цифр доступности. Это HostCMS, Shop-Script и AMIRO.CMS.

Среди оставшихся CMS было проведено последнее тестирование с нагрузкой в 500 одновременных посетителей сайта.

500 человек / 10 минут

  • Результаты тестирования:
CMS 500 чел./10 мин.
(результаты кликабельны)
DIAFAN.CMS 57.63%
Simpla 40%

Результаты и выводы

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

Сводная таблица результатов

  CMS 100 чел./10 мин. 250 чел./10 мин. 500 чел./10 мин.
1 DIAFAN.CMS 100% 100% 57.63%
2 Simpla 100% 100% 40%
3 AMIRO.CMS 100% 96% -
4 Shop-Script 100% 21.67% -
5 HostCMS 100% 1.67% -
6 NetCat 92.19% - -
7 UMI.CMS 56.37% - -
8 1С-Битрикс 2.91% - -
9 Cs-Cart 1.4% - -

Устойчивость сайта при внезапных нагрузках — важный момент. Конечно, постоянная посещаемость в 500 одновременных он-лайн посетителей встречается, мягко говоря, не повсеместно. Это 3.000 посетителей в час или 72.000 уников в сутки, а при действии каждого посетителя раз в 5 секунд — более 8.000.000 хитов. Владельцы сайтов с такой постоянной посещаемостью выбирают выделенные сервера, а не VPS. Однако и владелец небольшого интернет-магазина может давать рекламу, привлекать посетителей, и при кажущейся надежности сайта, в пики рекламной кампании получить сайт-развалюху и несколько процентов от ожидаемых продаж. Поэтому для нагрузочного тестирования в качестве платформы был использован недорогой виртуальный сервер, рыночная стоимость которого находится в пределах 1000 рублей в месяц. Возможно, на выделенном физическом сервере, с индивидуальной настройкой каждой системы под ресурсы, результаты у выбывших CMS были бы достойнее, но большинство веб-сайтов в рунете хостятся на недорогих площадках и святое дело каждой CMS экономно использовать доступные ресурсы.

Олег Свирчев oleg@svirchoff.ru
Администратор сервиса Loaddy.com

Комментарий участника исследования

Илья Макаров

Компания: CS-Cart
Должность: Технический директор

 

Спасибо за проведенное исследование.

О сервисе loaddy.com

Первое, что смущает, это принцип, по которому сервис loaddy.com считает 100%-ую доступность (и, я надеюсь, что автор статьи, который является администратором этого сервиса, сможет рассказать об этом поподробнее).

Как пример, в тестах для Simpla (http://loaddy.com/result/363675975) среднее количество ответов 350 (график слева), и доступность 100%. На графике для Amiro (http://loaddy.com/result/557530040) среднее значение ответов ~250, и доступность так же 100%. Собственно, возникает вопрос как при равномерной нагрузке в 100 пользователей количество ответов на разных системах варьируется, но доступность все еще 100%. Получается, либо нагрузка неодинаковая, либо сервис как-то хитро считает «ответы».

Насколько я понимаю, сервис loaddy.com еще достаточно молодой, но текущих выдаваемых показателей недостаточно для объективной оценки. Кроме доступности, система должна дать ответы по другим важным показателям:

1) Ёмкость (измеряется в rps) — говорит нам: «выдерживаем X rps»;

2) Времена ответов — говорит нам: «P% ответов укладываются в K ms».

В следующий раз для нагрузочного тестирования предлагаю использовать Яндекс.Танк, JMeter или Siege.

Техническое обеспечение

К сожалению, недостаточно технической информации о сервере, на котором проходило тестирование, а это очень важно. Какой веб-сервер, есть ли какие-то кэшеры, параметры процессора (%us, %sy, %io, ...), памяти (free, used, cached), диска (util, r/s, w/s), сети (bandwidth, pcki, pcko) и т.д. К примеру, веб-сервер Apache может более-менее адекватно работать с легкими системами, но если речь идет про серьезные проекты, то Apache — это стопроцентная гарантия тормозов, и в таких случаях используют Nginx.

Размер имеет значение

Тут очень важно учитывать, что тестируемые CMS имеют различную функциональность, и это сильное влияет на объем исполняемого кода, количество запросов к базе данных и т.д. и в конечном итоге на время загрузки. CS-Cart — функциональный движок, и в нем очень много модулей и различного рода «фишек» включено по умолчанию, чтобы продемонстрировать клиенту все возможности программы. Все это, бесспорно, создает дополнительную нагрузку на сервер.

Реабилитация

К сожалению, в тестируемой версии CS-Cart кэш не был настроен правильно по умолчанию, и мы признаем это упущение. Мы исправим эту проблему в самом ближайшем релизе. Уже сейчас можно посмотреть, как правильный кэш в CS-Cart воспринимает нагрузку в 250 одновременных посетителей:

http://loaddy.com/result/498712117/

Как вы видите, доступность 100%. Причем, что важно, тестирование это проводилось на более слабом сервере без SSD дисков: ОС Ubuntu 14.04.1 LTS trusty x86, Intel® Pentium® CPU G620 @ 2.60GHz, 2.0 GB RAM DDR-2, HDD WD Caviar Blue 500.0 GB 3.0 Gb/s 7200 rps, NginX/1.6.2, PHP/5.6.3 (FPM), MySQL/5.5, Redis/2.2.6.

Для объективности мы готовы поставить автору статьи новую версию CS-Cart, где кэш сконфигрурирован должным образом сразу из коробки на тот же сервер, который был использован в статье, для повторного тестирования.

 

Рекомендуем:

  Все исследования


Комментарии (Facebook)


CMS Magazine CMS Magazine
© 2006-2016 CMS Magazine  Правовая информация  Статьи партнеров  Реклама
CMS Magazine – электронное СМИ. Эл № ФС 77-32705. Статьи партнеров
RSS-подписка комплексные решения
CMS Magazine CMS Magazine
CMS Magazine