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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Валюты

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

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

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

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

Установка CMS

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

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

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

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

HostCMS

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

Shop-Script

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

DIAFAN.CMS

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

1С-Битрикс

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

Simpla

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

CS-Cart

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

UMI.CMS

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

AMIRO.CMS

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

NetCat

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

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

AMIRO.CMS

1С-Битрикс

CS-Cart

DIAFAN.CMS

HostCMS

NetCat

Shop-Script

Simpla

UMI.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% доступности, выбывают. Это CS-Cart, 1С-Битрикс, UMI.CMS и NetCat.

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

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

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

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

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

Более 1000 агентств готовы провести тестирование интернет-магазина под нагрузкой, на удобство и корректность обработки данных. Всего пара кликов на тендерной площадке Workspace и ваш проект под пристальным вниманием агентств.

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

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

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

Устойчивость сайта при внезапных нагрузках — важный момент. Конечно, постоянная посещаемость в 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, где кэш сконфигрурирован должным образом сразу из коробки на тот же сервер, который был использован в статье, для повторного тестирования.