Magento performance by Michael Zhalevich

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

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

3. Каких результатов нужно достичь?
Сервер:
 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 конкурентных запросов.

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

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

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

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

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

9. Выбор связки веб-сервер + 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)

10. 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;

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

12. 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

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

14. 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

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

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

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

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

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

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

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

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

23. БД 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

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

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

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

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

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

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

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

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

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

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