Предыдущие статьи в серии “Ускоряем Magento”:

• Часть 1 – К чему стремиться
• Часть 2 – Настройка веб-сервера

Целью этих тестов является показать преимущества той или иной конфигурации и настроек. Чтобы обеспечить возможность легко воспроизвести эти тесты или сравнить с другими конфигурациями позднее, мы решили провести тестирование в на виртуальных серверах в “облаке”. Следует заметить, что тесты на “реальном железе” дают намного лучшие результаты, что мы продемонстрируем в следующих статьях, сравнив несколько конфигураций физических серверов и виртуальную среду.

Тесты запускали на серверах в “облаке” Rackspace Cloud Servers – www.rackspacecloud.com. Запускаемые копии серверов использовали базовый образ операционной системы CentOS 5.3 x86_64, предоставляемый сервером (вы сможете выбрать любую другую из более чем 15 различных образов операционных систем). После запуска ОС производилась установка всех обновлений (yum update), устанавливались Apache, PHP и MySQL. Установочные пакеты PHP и MySQL для CentOS взяты из RPM-репозитория Remi – rpms.famillecollet.com. Все тесты проводились на Magento с тремя различными наборами данных – Magento Sample Data (~130 продуктов) и тестовые каталоги с 10 и 80 тысячами продуктов.

При тестировании измерялось количество запросов в секунду, которое может обработать система при запросах к стартовой странице и при запросах в течение “стандартной сессии посетителя”. Список страниц, которые входят в “стандартную сессию посетителя” приведён ниже на странице.

На всех графиках используются следующие обозначения для Magento с каталогами разного размера:

• sd – Magento Sample Data
• 10k – Magento с 10 тысячами продуктов
• 80k – Magento с 80 тысячами продуктов

Каждый тест запускался с разным количеством параллельных потоков – 10, 20, 50 и 100 параллельных подключений.
Для тестирования использовалась утилита siege – www.joedog.org/index/siege-home и набор простых shell-скриптов для запуска тестов в разных конфигураций и обработки полученных результатов.

Список ссылок “стандартной тестовой сессии посетителя” для Magento Sample Data:

BASEURL=http://server.test/
$(BASEURL)
$(BASEURL)electronics/cell-phones.html
$(BASEURL)electronics/cell-phones.html?price=2%2C100
$(BASEURL)electronics/cell-phones.html?price=2%2C100&color=23
$(BASEURL)electronics/cell-phones/samsung-mm-a900m-ace.html
$(BASEURL)checkout/cart/add/product/20/
$(BASEURL)apparel.html
$(BASEURL)cn-clogs-beach-garden-clog.html
$(BASEURL)checkout/cart/
$(BASEURL)checkout/onepage/
$(BASEURL)catalogsearch/result/?q=ink&x=0&y=0
$(BASEURL)apparel.html?cat=17
$(BASEURL)apparel.html?price=1%2C100&cat=17
$(BASEURL)the-get-up-kids-band-camp-pullover-hoodie.html
$(BASEURL)checkout/cart/add/product/39/
$(BASEURL)apparel/shirts.html


Список ссылок тестовой сессии для Magento с 10 и 80 тысячами продуктов:

BASEURL=http://server.test/
$(BASEURL)
$(BASEURL)category-3.html
$(BASEURL)category-3.html?cat=28
$(BASEURL)category-3.html?cat=28&price=2%2C1000
$(BASEURL)category-3/pr15031-50.html
$(BASEURL)checkout/cart/add/product/2489/
$(BASEURL)category-273.html
$(BASEURL)category-273/100-190-b7h.html
$(BASEURL)checkout/cart/
$(BASEURL)checkout/onepage/
$(BASEURL)catalogsearch/result/?q=345&x=0&y=0
$(BASEURL)category-273.html?cat=427
$(BASEURL)category-273.html?cat=427&ab_host=303
$(BASEURL)category-273/r1256ap.html
$(BASEURL)checkout/cart/add/product/1354/
$(BASEURL)category-273/category-309.html


Тестовые наборы данных:

Стандартный набор тестовых данных Magento Sample Data (~130 продуктов) доступен на странице загрузки по адресу www.magentocommerce.com/download

Тестовые базы данных с 10 тысячами и 80 тысячами продуктов можно скачать по следующим ссылкам:

• http://www.magentocommerce.com/downloads/assets/sample-db/magento_10k.sql.bz2
• http://www.magentocommerce.com/downloads/assets/sample-db/magento_80k.sql.bz2

Предыдущие статьи в серии “Ускоряем Magento”:

• Часть 1 – К чему стремиться

Хотя существует несколько способов настройки выполнения PHP-скриптов под Apache: как модуль (mod_php) или как FastCGI/CGI (например, с помощью mod_fastcgi или mod_fcgid), наиболее часто используется все-таки первый (mod_php).

Кроме mod_php в конфигурационном файле Apache по умолчанию включена загрузка почти всех доступных модулей, несмотря на то, что не все их них требуются для работы Magento. Это становится особенно актуально в многосерверной конфигурации, когда различные узлы занимаются выполнением разных задач, и могут быть сконфигурированы для оптимального выполнения конкретной задачи.

Минимально необходимый перечень модулей Apache для работы Magento:

• mod_expires
• mod_deflate
• mod_mime
• mod_dir
• mod_rewrite
• mod_authz_host
• mod_authz_user – может понадобиться для ограничения доступа к тестовой среде с помощью аутентификации по паролям, но редко используется на “боевом” сервере.

*Примечание: Мы рассматриваем настройку веб-сервера только с точки зрения Magento. Если у вас на том же сервере запущены другие веб-приложения, будьте осторожны при использовании приведенных рекомендаций.

Уменьшение количества загружаемых модулей (закомментировав соответствующие строчки “LoadModule” в httpd.conf) позволяет несколько уменьшить объем памяти используемый веб-сервером, что может позволить обрабатывать больше одновременных соединений при том же объеме установленной памяти.

Важным параметром настройки Apache является задание оптимального количества запускаемых процессов Apache. На данный момент режим mpm_worker все еще не может быть рекомендован для безопасного использования совместно с PHP, а процесс создания новых процессов Apache в режиме mod_prefork является “дорогой” операцией. Лучше всего работает создание необходимого количества процессов Apache сразу же при запуске веб-сервера. Это количество может быть определено практическим путем при максимальной загрузке сервера.

Обратите внимание, что значения параметров ServerLimit и MaxClients нельзя увеличивать бесконечно. Они должны иметь значения, выставленные в зависимости от доступного количества физической памяти, для того, чтобы система не начала вытеснять “лишние” процессы Apache в раздел подкачки (что приведет к резкому “проседанию” сервера при увеличении нагрузки до определенного значения).

Параметр MaxRequestsPerChild можно оставить со значением по умолчанию (4000).

Использование пула постоянных соединений (keep-alive) хотя и улучшает скорость получения контента веб-браузером, но под высокой нагрузкой приводит к неоправданному перерасходу ресурсов сервера, поэтому KeepAlive всегда должен быть выставлен в off.

Следующим важным параметром является использование сжатия контента. Несмотря на то, что это немного увеличивает использование вычислительных ресурсов сервера, выигрыш от быстрой отдачи контента броузеру и освобождение процессов для обработки следующих запросов с лихвой компенсируют эти “затраты”. Функциональность по компрессии контента предоставляется модулем mod_deflate. В Magento в файле .htaccess приведены все необходимые директивы для включения компрессии, нужно просто раскомментировать соответствующие строки, чтобы уменьшить время загрузки страниц броузером. Вот пример части .htaccess, которая у вас получится в релузьтате:

    # Insert filter on selected content types only
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript

    # Netscape 4.x has some problems...
    BrowserMatch ^Mozilla/4 gzip-only-text/html

    # Netscape 4.06-4.08 have some more problems
    BrowserMatch ^Mozilla/4\.0[678] no-gzip

    # MSIE masquerades as Netscape, but it is fine
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

    # Don't compress images
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

    # Make sure proxies don't deliver the wrong content
    Header append Vary User-Agent env=!dont-vary

Кроме того, можно избежать дополнительных затрат по сканированию всех директорий в пути к запрашиваемому скрипту или файлу, внеся все параметры из файлов .htaccess в основной httpd.conf файла в соответствующие разделы <Directory>.

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

Мы постараемся в каждой статье подробно разобрать каждый из аспектов оптимизации. Все статьи будут проиллюстрированы результатами проведенных нами тестов.

Итак, вот пример сравнения производительности двух кофигураций:

• Слева – настройки сервера и Magento по умолчанию
• Справа – оптимизированные настройки среды и самой Magento

Пояснение о процессе тестирования:

Все тесты проводились на виртуальном сервере в вычислительном облаке для того, чтобы обеспечить максимальную повторяемость результатов без привязки к конкретному оборудованию. В заключительной статье мы сравним производительность Magento, установленной на виртуальном сервере и реальном “железе”, так как по результатам нашего тестирования реальное “железо” может значительно превосходить виртуальный “облачный” сервер.

Тесты запускались на виртуальном сервере в облаке Rackspace Cloud Servers используя образ операционной системы CentOS 5.3 x86_64, подготовленный компанией Rackspace. Создавая экземпляры виртуальных серверов вы сможете выбрать практически любой из распространенных дистрибутов (RHEL/CentOS/Debian/Ubuntu/Gentoo/Arch и другие). PHP и MySQL были установлены из бинарных пакетов репозитория Remi. Конфигурационные файлы Apache и MySQL мы приведем при разборе соответствущих настроек.

Все тесты прогонялись на трех типах (размерах) каталога продуктов в Magento: Magento Sample Data с ~100 продуктов, каталог с 10 000 (10 тысяч) продуктов, и каталог с 80 000 (80 тысяч) продуктов.

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

На графиках используются следующие сокращения по оси X:

• sd – Magento sample data
• 10k – магазин с 10 тысячами продуктов
• 80k – магазин с 80 тысячами продуктов

Каждый из тестов запускался при разной нагрузке (concurrency – количестве одновременных соединений): 10, 20, 50 и 100 одновременных соединений.

Оранжевым цветом отмечены столбцы соответсвующие количеству запросов в секунду при усредненной сессии посещений, зеленым – количество запрос в секунду к стартовой странице.

В статье “Тестирование производительности” мы более подробно остановимся на используемых инструментах и используемой методике тестирования.

Magento – это приложение PHP/Zend, интенсивно использующее ресурсы центрального процессора. С момента выхода версии 1.1.6, каждая новая версия включала в себя некоторые механизмы, призванные улучшать производительность платформы. Основной целью является уменьшение потребления ресурсов для данного e-магазина (попросту говоря – меньше процессорного времени), для того чтобы обслуживать большее количество пользователей на том же самом аппаратном обеспечении.

Одним из путей достижения лучшей производительности является оптимизация скорости генерации страниц PHP. На широко распространенных “LAMP” серверах обычно используется Apache с модулем mod_php, или, иногда, с модулем fast_cgi.

Zend (компания, поддерживающая PHP), выпустила специализированный продукт – Zend Server, который включает в себя стэк веб-приложений, и, помимо некоторых других возможностей, увеличивает скорость работы путем кэширования страниц, и реорганизации и ускорения байт-кода.

Apache в связке Zend Server являются альтернативой обычному Apache с mod-php для запуска Magento. Целью этого исследования является исследование и оценка улучшений производительности за счет использования данного ПО.

Большое спасибо Yoav Kutner (CTO компании Varien) за предоставленные заполненные тестовые каталоги для версий Magento 1.2 и 1.3. Также спасибо лаборатории Zend за помощь в конфигурации и тонкой настройке Zend Server, а также за полное объяснение механизма работы данного решения.

Используемые методы и инструменты

Бенчмарки делались с помощью утилиты siege (версия 2.66-2), с различным количеством одновременных потоков (5, 10, 20 and 40). Каждый поток открывал соединение с веб-сервером, запрашивал страницу и начинал все сначала после того, как страница была считана.

Тесты запускались по 5 минут каждый, и расчитывалось среднее количество полученных страниц для этого бенчмарка.

Проводились два типа тестов: первый – простой, мы просто загружали главную страницу в цикле, как можно быстрее.

Второй тест базировался на логах загрузки всех элементов броузером при посещении страницы (включая css, js, картинки). Так как загрузка одной страницы обычно вызывает загрузку нескольких элементов, отображаемое число будет значительно больше, чем количество страниц, реально видимых пользователю. На 18 страниц, просмотренных пользователем, приходится 91 скачанный элемент, среднее соотношение примерно 1 к 5.

Все результаты были получены на одном и том же “железе” и операционной системе, для целей тестирования. Обратное проксирование не использовалось. Во время запуска тестово был активен АРС кеш байт-кода. Это было стандартное окружение по умолчанию, без применения тонких настроек.

Железо:

2 процессора: Quad-Core AMD Opteron™ Processor 2376 (2.3GHz), 8GB RAM

Софт:

ОС: Linux (2.6.27.10-grsec) Debian (Lenny)
Веб-сервер: Apache2 (2.2.9-10+lenny2)
PHP (mod-php): mod-php5 (5.2.6.dfsg.1-1+lenny3) / php-apc (3.0.19-2)
PHP (Zend Server): zend-pe (1.0.0-1+b47) / mod-php5-zend-pe (5.2.9+b75)

Репозитории:

deb http://ftp.fr.debian.org/debian/ lenny main
deb http://security.debian.org/ lenny/updates main
deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb http://repos.zend.com/deb/pe pe non-free

Тестирование разных версий Magento

Эти тесты были выполнены в каталоге с более чем 80 000 (далее – 80k) продуктов.

Графики показывают среднее количество запросов в секунду, успешно обработанных сервером во время пятиминутного теста.

Загрузка главной страницы

Magento 1.3 собирает главную страницу гораздо быстрее, чем версия 1.2. Включенный Flat-каталог не сильно помогает в отображении главной страницы, и даже, похоже, замедляет процесс ее сборки при большой нагрузке. Производительность версии 1.3 в два раза выше чем 1.2 при небольших нагрузках, и на 33% больше при больших нагрузках.

При “стандартной” загрузке мы можем отметить 40%-ный прирост производительности в версии 1.3 по отношению к версии 1.2, по крайней мере для домашней страницы.

Полный цикл посещения

График показывает небольшое увеличение в версии 1.3 по сравнению с 1.2, механизм flat-каталога дает общее улучшение, которое существенно увеличивает производительность.

Резюмируя, можем привести такие значения:

Версия 1.2 -> 1.3 : +66%
Версия 1.3 -> 1.3+FС : +20%

Apache + mod-php по сравнению с Apache + Zend Server

Zend Server (далее ZS) предлагает несколько встроенных технологий для увеличения производительности приложений:

• Zend Optimizer+ выполняет оптимизацию и кэширование байт-кода. Это увеличивает скорость PHP-приложений путем исключения процесса чтения скриптов с диска и их компилирования. Zend Optimizer+ запускается автоматически, и установка вашего приложения поверх Zend Server (ZS) – это всё, что вам нужно сделать чтобы насладиться его преимуществами. Во время тестов с ZS, кэш APC был деактивирован, так как Zend optimizer+ делает ту же работу.
• Zend Page Cache позволяет кэшировать PHP страницы целиком. Кэширование страниц значительно увеличивает производительность веб-приложений, в то же время поддерживая динамические возможности с помощью системы правил кэширования, построенной на параметрах запросов и данных сессий пользователей. Кэширование страниц также имеет преимущество в том, что не требует никаких изменений в коде, и может быть настроено через интерфейс Zend Server. Только “pro”-версия включает в себя эту часть ПО, которая однозначно изменяет производительность к лучшему, в чем мы и убедимся через минуту.
• Zend Data Cache это набор функций API, позволяющих разработчику сохранять и управлять данными (PHP строки, массивы и другие данные) и даже выдавать элементы либо из кэша диска, либо из кэша разделяемой памяти. Zend Data Cache позволяет настроить тонкое кэширование там, где полное кэширование страниц невозможно. Предлагаемый API легок в использовании в существующем коде, и во многих случаях разработчик может пропускать существующие участки кода, просто оборачивая их API кэширования. Эта возможность может быть использован путем незначительной доработки исходного кода ПО Varien.

Примечание: Zend Optimizer+ и Zend Data Cache доступны в бесплатной версии Zend Server, в то время как Zend Page Cache требует покупки лицензии Zend Server (полное сравнение Zend Server и Zend Server Community Edition доступно на http://www.zend.com/en/products/server/editions).

Настройка Zend Server для Magento

В бенчмарке были определены 2 правила кэширования:

Первое правило кэширует файлы JavaScript, которые динамически подключаются к каждому запросу Magento. Это простое правило привело к значительному улучшению времени отклика.

Второе правило кэширует все веб-страницы, посещенные пользователями, у которых нет товаров в корзине и нет истории посещений (когда корзина не пустая, либо сохранена история пользователя – нет смысла в кэшировании страницы). Как вы видите на картинке внизу, это было сделано с помощью проверки переменных $_SESSION и разделению по $_SERVER['REQUEST_URI'] в дополнение к QUERY_STRING.

Наконец, Zend Optimizer+ был включен для оптимизации и кэширования PHP байт-кода.

Как видите, Zend Page Cache оказался очень мощной функцией. Он требует тонкой и тщательной настройки, но взгляните результаты:

Главная страница / каталог из 80 000 продуктов

Загрузка на главной странице не сильно повлияла на результаты, хотя при большой нагрузке на сервер (40 параллельных заросов), Zend Server (с или без page cage) немного лучше чем mod_php, но практически никакого реального влияния на тест. Выигрыш в 5% и даже меньше не является серьезным фактором и лежит в пределах статистической ошибки тестов.

Полное посещение / 80k продуктов

График говорит сам за себя, при любой нагрузке Zend Server с Page Cache и включенным flat каталогом в Magento действительно улучшают производительность.

Сравнивая 1.3 + flat каталог с такой же конфигурацией, но с установленной бесплатной версией ZS вместо APC, наш сервер получил до 15% больше производительности.

Если же использовать полный Zend Server (с лицензией, в который включено кэширование страниц) на версии 1.3 с flat каталогом, сервер получил до 30% прироста производительности!

Mod PHP + APC -> ZS: +15%
Mod PHP + APC -> ZS с лицензией: +30%

Время отклика

Главная страница / 80k продуктов

Этот график показывает время отклика на домашней странице во время загрузки. При значительной нагрузке, ZS дал до 35% сокращения времени отклика во время загрузки.

Полное посещение / 80k продуктов

Кэширование страниц сокращает время отклика во время полного посещения сайта даже под очень тяжелой нагрузкой. Выгоды от использования кэширования страниц в любом случае существенны, даже при стандартной загрузке. Можем засчитать 35%-ный выигрыш при серьезной загрузке в случае использования любой (бесплатной или лицензированной) версии ZS.

При средней и легкой загрузке, кэширование страниц дает гораздо больший эффект чем может дать бесплатная версия ZS. Этот неожиданный результат, вероятно, является следствием того, что механизм кэширования показал себя неэффективным при большой нагрузке, так как система использует свои ресурсы по-другому.
У нас не было времени проверить, что именно является причиной – процессор, Линукс или сам ZS, однако тесты были проделаны несколько раз с одинаковыми результатами.

Таким образом, запомните, что выгоды механизма кэширования страниц в ZS будут становиться все менее эффективными по мере роста загрузки сервера. При обычной нагрузке, алгоритм Page Cache дал уменьшение времени загрузки до примерно 40%.

Дополнительный технические детали тестов

Тестовые данные

Все тесты были проведены с готовыми тестовыми данными (предоставленными компанией Varien)

Описание тестов

Тест главной страницы

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

Тест полного посещения

У нас есть список запросов, основанный на посещении сайта с помощью реального браузера. Каждый одновременный поток загружает каждый элемент один за другим так быстро как только сможет, и перегружается после удаления его cookies.

Список запрашиваемых страниц для базы данных из 80k продуктов (с информацией POST где возможно) здесь.

Планируемые тесты

Mage компилятор

Во время подготовки этих тестов, вышла версия 1.3.1.1, включающая модуль Mage_Compiler, и сразу за ней готовилась к выпуску версия 1.3.1.2, так что мы просто не успели включить некоторые тесты в этот обзор. Просто предположим, что весь механизм предназначен для уменьшения работы по вводу-выводу, с помощью включения большинства классов в несколько сборных файлов. Если ваши сервера использовали для работы в основном RAM, вы не ощутите значительного прогресса в производительности. Однако, если в серверах мало RAM, либо они в основном используют диски, вы убедитесь в выгодах использования данных возможностей!

Nginx

У нас не было достаточно времени для оценки результатов тестов с Nginx + PHP. Это решение давало результаты, промежуточные между Magento 1.3 + FC и Magento 1.3 + Zend Server (без Page cache). Так что эта комбинация достигала средних значений производительности, в отличие от Magento 1.3 + Zend Server или еще более продвинутых вариантов.

Выводы

Во-первых, позвольте заявить, что никакие электроны не были заряжены и не пострадали во время этих тестов. Возможно один или два СТО были вынуждены пострадать от кофейных вливаний, но чего только не сделаешь ради лучшего будущего E-commerce!

Если хотите более профессионального заключения, то можем сказать, что использование бесплатной версии ZS сказывается только положительно и действительно может заменить APC.

При использовании лицензированной версии ZS, механизм Page Cache очень эффективен, и может сократить используемые ресурсы железа на 25% для поддержания тех же возможностей хостинга. В некоторых случаях это может обернуться прямым сокращением расходов на сервера.

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

И последнее – настраивая сервер со всеми оптимизациями и используя приведенные рекомендации, на базе dual AMD 2376 с 8 Gb RAM, использующий ZS и кэширование страниц, вы сможете достичь уровня до 40 000 уникальных посетителей в день, что соответствует 2 500 одновременных сессий Magento при максимальной загрузке (при вынесении базы данных на отдельный сервер, и использовании обратного прокси типа Squid или Varnish перед веб-сервером).

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

И напоследок примерное суммарное сравнение производительности упомянутых конфигураций:

Эта статья доступна также на английском и французском языке.

Права: Оригинал этой статьи опубликован под лицензией Creative Commons “Attribution-Noncommercial-Share Alike 3.0″ License. Только три компании (NBS System, Zend и Varien) могут использовать её в коммерческих целях.