Закрыть
E-mail:
Пароль:
Забыли пароль?
В каталоге проекта: 10 474 веб-студии, 904 CMS, 205 382 сайта.
Регистрация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 отделены друг от друга

Необходим сайт, мобильное приложение, услуги по SEO или контекстной рекламе? Тендерная площадка WORKSPACE поможет выбрать оптимального исполнителя. База проекта насчитывает более 10 500 агентств. Сервис работает БЕСПЛАТНО как для заказчиков, так и для исполнителей.

Установка 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