Нагрузочное тестирование CMS для интернет-магазинов
В рамках исследования была протестирована устойчивость к нагрузкам 9 систем управления сайтами из ТОП10 самых популярных CMS для интернет-магазинов по версии CMS Magazine.
Источник: Loaddy.com
Предисловие редакции
В рамках исследования авторами не настраивались встроенные в системы управления механизмы кеширования. Задействование этих механизмов, а также оптимизация настроек веб-сервера, PHP и MySQL могли бы весьма существенно изменить устойчивость тестируемых сайтов к нагрузкам, и, соответственно, полученные результаты.
Выбор CMS и сервера В ноябре 2014 года нам поступило предложение провести сравнительное нагрузочное тестирование коробочных систем управления сайтами. Для тестирования были выбраны 9 систем управления сайтами из ТОП10 самых популярных CMS по версии CMSmagazine.ru.
Функиональность у всех систем схожая, и включает:
Категории товаров с неограниченной вложенностью, с изображениями и описаниями
Динамические характеристики с поддержкой зависимости цены от комплектации
Бренды товаров
Фильтры, сортировки и гибкий поиск по товарам
Сравнение товаров
Возможность продажи цифровых товаров
Покупка в один клик
Сопутствующие услуги
Автоматическая поддержка режима «С этим товаром покупают» и блок «похожие товары»
Выгрузка в Яндекс.Маркет
Синхронизация с 1С: Предприятие
Учет количества товаров на складе
Гибкая система скидок, скидочные купоны, назначение скидок по типам покупателей, скидки от суммы заказа, накопительные скидки и т.д.
Методы online-оплаты: WebMoney, Яндекс.Деньги, QIWI и пр.
Баланс покупателей с возможностью пополнения и оплаты с него
Валюты
Отложенные товары
Конструктор формы заказов
Списки ожиданий
Платформа для тестирования была любезно предоставлена хостиновой компанией IT-MCP. Это оказался VPS-сервер из дата-центра в Германии, с SSD-диском, 3,5GHz и 1,6Gb оперативной памяти.
Установка 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 товарами Для тестирования был подготовлен 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-файле были определенные названия полей со стандартами системы. После чего товары успешно и быстро импортировались.
UMI.CMS В UMI.CMS система импорта не очень лаконичная и интуитивно понятная для новичка. Пришлось много гуглить, чтобы определить какого формата, с какими полями и с какими заголовками должен быть CSV-файл. Необходимо обязательно указывать колонку с уникальным id товара и&nbsnbsp; обязательно указывать активность товара, иначе после загрузки товаров их придется активировать вручную по одному, ведь групповых действий в системе нет. Плюс ко всему, необходимо первыми тремя строками указывать системные имена полей, их тип и название.
AMIRO.CMS Импорт в AMIRO.CMS с помощью встроенного модуля не удался. Система категорически отказывалась импортировать CSV-файл, либо выдавая ошибку о неверном имени столбца, либо зависая на 00:00. В итоге в AMIRO.CMS товары пришлось импортировать напрямую в таблицу БД, сформировав дамп.
NetCat В NetCat импорт товаров вроде как предусмотрен, но чтобы настроить его, предлагается платно обратиться к любому из партнеров-разработчиков. Пришлось импортировать товары также через PHPMyAdmin, напрямую в БД.
После импорта товаров на каждом сайте на первую страницу списка товаров были выведены по 12 элементов на страницу. Таким образом, каждая CMS формирует страницу с одинаковым количеством товаров из одинакового общего количества в БД.
1С-Битрикс
DIAFAN.CMS
Shop-Script
Анализ скорости генерации 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 как использует ресурсы. Конечно, кто-то может себе позволить сразу и с запасом приобрести мощный выделенный физический сервер, однако если владельцы будущих сайтов не намерены платить ссотни долларов в месяц за хостинг-площадку, рекомендуется принять во внимание нижеследующую таблицу результатов данного тестирования.
Сводная таблица результатов
Устойчивость сайта при внезапных нагрузках — важный момент. Конечно, постоянная посещаемость в 500 одновременных он-лайн посетителей встречается, мягко говоря, не повсеместно. Это 3.000 посетителей в час или 72.000 уников в сутки, а при действии каждого посетителя раз в 5 секунд — более 8.000.000 хитов. Владельцы сайтов с такой постоянной посещаемостью выбирают выделенные сервера, а не VPS. Однако и владелец небольшого интернет-магазина может давать рекламу, привлекать посетителей, и при кажущейся надежности сайта, в пики рекламной кампании получить сайт-развалюху и несколько процентов от ожидаемых продаж. Поэтому для нагрузочного тестирования в качестве платформы был использован недорогой виртуальный сервер, рыночная стоимость которого находится в пределах 1000 рублей в месяц. Возможно, на выделенном физическом сервере, с индивидуальной настройкой каждой системы под ресурсы, результаты у выбывших CMS были бы достойнее, но большинство веб-сайтов в рунете хостятся на недорогих площадках и святое дело каждой CMS экономно использовать доступные ресурсы.
Олег Свирчев oleg@svirchoff.ruАдминистратор сервиса Loaddy.com
Полный текст статьи читайте на CMS Magazine
