Magento performance

Максимальная производительность и масштабируемость Magento 15 июня 2012. Минск Михаил Жалевич

Немного теории. Performance  Обеспечение приемлемой скорости загрузки страницы.  0.1 – 1 – 10  Обеспечение приемлемой скорости загрузки страницы при одновременном пребывании в приложении N пользователей.

Каких результатов нужно достичь? Сервер:  CPU:Intel(R) Xeon(R) CPU X3320 @ 2.50GHz  Memory: 4GB  HDD: 1 HDD without raid Magento:  Magento Community Edition 1.7 Желаемый результат от одного сервера:  Время генерации страницы в пределах 0.1 – 1 секунды при нагрузке в 20 конкурентных запросов.

Немного теории. Чем измерять?  http_load  Apache HTTP server benchmarking tool – или ab  Siege  Apache JMeter

Дефолтная конфигурация сервера Ваша задача:  Обеспечить максимальную скорость работы приложения на сервере. Задача дефолтной конфигурации:  Обеспечить максимальное кол-во поддерживаемых приложений.

Дефолтная конфигурация сервера 6 5.12 5 4 3.5 3 Response time (secs) 2 Transaction rate (trans/sec) 1 0 Magento with default server configs

Выбор ОС  BSD: FreeBSD, OpenBSD, etc  Debian: Debian, Ubuntu  Gentoo, Slackware  RHEL

Выбор связки веб-сервер + php  Nginx + Apache + mod_php  Apache + mod_php  Nginx + php-fpm

Выбор связки веб-сервер + php 10 9.47 9 8 7 5.79 5.75 6 5 4 3.34 3.37 3 2.08 Response time 2 (secs) 1 0 Transaction rate (trans/sec)

PHP-FPM - FastCGI Process Manager  advanced process management with graceful stop/start;  emergency restart in case of accidental opcode cache destruction  "slowlog" - logging scripts that are executed unusually slow;

PHP: Остаться на php 5.3.*или переходить на php 5.4.* Плюсы перехода  PHP-5.4 быстрее  В дальнейшей работе можно использовать нововведения языка Минусы  Возможные проблемы с миграцией кода на новую версию

PHP: Остаться на php 5.3.*или переходить на php 5.4.* 12 10.14 10 9.47 8 Response time 6 (secs) Transaction rate 4 (trans/sec) 2.08 1.95 2 0 PHP 5.3.13 PHP 5.4.3

Opcode cacher. Must have Open Source  APC  Xcache  eAccelerator Propietary  ionCube  Zend Server

Opcode cacher. Must have 20 18 17.43 16 14 12 10.14 10 Response time (secs) 8 6 Transaction rate (trans/sec) 4 1.95 2 1.13 0 PHP 5.4.3 PHP 5.4.3 with APC

Что еще можно сделать?  Изменить кол-во child-process в PHP-FPM  Перенести пользовательские сессии в memcached  Перенести кэш в apc или memcached  Установить более высокие значения в конфигурационных параметрах php - realpath_cache_size и realpath_cache_ttl

Подведем небольшие итоги 25 19.79 20 15 Response time (secs) 10 Transaction rate 5.12 (trans/sec) 5 3.5 1 0 Before After optimization optimization

Какие инструменты не далиожидаемого результата  Memory file system  Facebook HIPHOP PHP  PHP Daemon

Конфигурация Nginx для Magento  Запретить доступ к каталогам Magento location /app/ { deny all; } location ~ /.ht { deny all; } location /.svn/ { deny all; }

Конфигурация Nginx для Magento  Отключить запись логов, там где они не нужны location /media/catalog/ { access_log off; } location /js/ { access_log off; }

Конфигурация Nginx для Magento  Включить сжатие для js и css location /media/js/ { gzip on; gzip_min_length 1000; gzip_disable "MSIE [1-6]."; expires 5d; access_log off; }

Конфигурация Nginx для Magento  Увеличить время ожидания ответа от FastCGI  fastcgi_read_timeout

БД MySQL. Версии и ответвления  MySQL  5.1 (5.1.49)  5.5 (5.5.25)  MariaDB (ver 5.5.24)  Percona Server (ver 5.5.24)

БД MySQL. Версии и ответвления CPU us. Avg. 25 23 20 15 10 CPU us. Avg. 6 6 6 5 0 MySQL MySQL MariaDB Percona 5.1 5.5 Server

Масштабирование системы  Вертикальное  Предполагает увеличение ресурсов на сервере  Горизонтальное  Предполагает увеличение кол-ва серверов

Масштабирование Magento  Априори распределенная архитектура. Web - сервер Приложение Статика БД

Масштабирование Magento  Шаг 1. Вынесение БД на отдельный(-ые) сервер(а).  Шаг 2. Увеличение кол-ва frontend серверов. Вынесение Magento backend’а на отдельный(-ые) сервер(а).  Балансировка нагрузки  Общий кэш приложения  Хранение пользовательских сессий  Хранение статики  Репликация MySQL

Масштабирование Magento.Балансировка нагрузки upstream backend { server backend1.example.com weight=5; server backend2.example.com:8080; server unix:/tmp/backend3; } server { location / { proxy_pass http://backend; } }

Масштабирование Magento.Общий кэш приложения. Хранениепользовательских сессий  Хранилище  Redis  Memcached Не нужно хранить пользовательские сессии и кэш в одном storage.

Масштабирование Magento.Хранение статики  Использовать для статики отдельный домен  Физически хранить статику на одном из frontend серверов либо на балансировщике нагрузки  К frontend серверам монтировать как sshfs или nfs

Масштабирование Magento.Репликация MySQL  Пока возможно вертикальное масштабирование MySQL, лучше нарастить мощность сервера БД.  Перед запуском репликации сделайте Code Review  Убедитесь, что никто не пишет в core_read  Убедитесь в отсутствии запросов вида «update t1 set updatet_at = NOW()»  Включите slow log, оптимизируйте все медленные (> 0.5 секунды) запросы на вставку/редактирование.  Используйте репликацию вида master-slave, либо цепочки репликаций master-slave

Мониторинг. Обеспечениеотказоустойчивости Системы мониторинга:  Nagios  Zabbix Отказоустойчивость:  Держите несколько резервных балансировщиков  Раз в сутки синхронизируйте на них статику  Используйте цепочки репликаций.  Используйте отложенную репликацию для создания резервных копий

Подведем итоги Оптимизация производительности – это…  всегда компромисс  всегда эксперименты  постоянный поиск и совершенствование

Михаил ЖалевичВедущий программистEmail: zhalevich@aheadworks.comSkype: cheshirskycode

Magento performance

by aheadWorks on Jun 20, 2012

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1,089

Statistics

Magento performance Presentation Transcript