Magento performance

Post on 16-Apr-2017

3.192 views 0 download

Transcript of 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

Дефолтная конфигурация сервера

Ваша задача: Обеспечить максимальную скорость работы

приложения на сервере.

Задача дефолтной конфигурации: Обеспечить максимальное кол-во поддерживаемых

приложений.

Дефолтная конфигурация сервера

Magento with default server con-figs

0

1

2

3

4

5

6

3.5

5.12

Response time (secs)Transaction rate (trans/sec)

Выбор ОС

BSD: FreeBSD, OpenBSD, etc

Debian: Debian, Ubuntu

Gentoo, Slackware

RHEL

Выбор связки веб-сервер + php

Nginx + Apache + mod_php

Apache + mod_php

Nginx + php-fpm

Выбор связки веб-сервер + php

Apach

e+mod

_php

Ng.+Ap.+

mod_p

hp

Nginx+

php-f

pm0

2

4

6

8

10

3.34 3.372.08

5.79 5.75

9.47

Response time (secs)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.*

PHP 5.3.13 PHP 5.4.30

2

4

6

8

10

12

2.08 1.95

9.4710.14

Response time (secs)Transaction rate (trans/sec)

Opcode cacher. Must have

Open Source APC Xcache eAccelerator

Propietary ionCube Zend Server

Opcode cacher. Must have

PHP 5.4.3 PHP 5.4.3 with APC

02468

101214161820

1.95 1.13

10.14

17.43

Response time (secs)Transaction rate (trans/sec)

Что еще можно сделать?

Изменить кол-во child-process в PHP-FPM

Перенести пользовательские сессии в memcached

Перенести кэш в apc или memcached

Установить более высокие значения в конфигурационных параметрах php - realpath_cache_size и realpath_cache_ttl

Подведем небольшие итоги

Before

optim

izatio

n

After o

ptimiza

tion

0

5

10

15

20

25

3.51

5.12

19.79

Response time (secs)Transaction rate (trans/sec)

Какие инструменты не дали ожидаемого результата

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. Версии и ответвления

MySQL 5.1

MySQL 5.5

MariaDB Percona Server

0

5

10

15

20

25 23

6 6 6

CPU us. Avg.

CPU us. Avg.

Масштабирование системы

Вертикальное Предполагает увеличение ресурсов на сервере

Горизонтальное Предполагает увеличение кол-ва серверов

Масштабирование 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

Михаил Жалевич

Ведущий программист