![php-fpm.conf
; рестартовать при ошибках
emergency_restart_threshold = 1
emergency_restart_interval = 10
[www1]
listen=/opt/php/var/run/php1.sock
# echo 10240 > /proc/sys/net/core/somaxconn
listen.backlog = 10240
pm = static
pm.max_children = 5
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 5](https://image.slidesharecdn.com/1-131020030601-phpapp02/85/1-1-13-320.jpg)
![php-fpm.conf
request_slowlog_timeout = 5
slowlog = /opt/php/var/log/www.slow_access.log
; не open_basedir в php.ini !!!
chroot = /var/www/chroot
php_admin_value[memory_limit] = 256M
security.limit_extensions = .php
[www2]
; ---------- // ---------------; разные chroot для виртхостов
; разные лимиты](https://image.slidesharecdn.com/1-131020030601-phpapp02/85/1-1-14-320.jpg)
(1 часть) 1С-Битрикс. Как настроить двухуровневую конфигурацию веб-приложения. Производительность.
- 1. Как настроить двухуровневую конфигурацию веб-приложения Сергей Рыжиков Директор «1С-Битрикс»
- 3. Одноуровневая схема Каждый запрос – обычно отдельный процесс Любой процесс может обработать любой запрос (статика, скрипт) Каждый процесс – десятки и сотни Мб Пока не закончен запрос, процесс не принимает новый
- 4. Узкие места 1. Отдача контента – медленные каналы 2. Производительность PHP (в том числе – запросы к внешним ресурсам и т.п.) 3. Обмен с БД (пропускная способность канала, latency, объем данных в приложении; использовать ли persistent connection?) 4. Скорость работы БД 5. Отдача статики – много памяти на простую задачу
- 5. Если оставить все «по умолчанию»? По умолчанию MaxClients в Apache 2.x – 256 Если PHP может занять 64 Мб (на самом деле – см. memory_limit в php.ini) – весь веб-свервер может занять 16 Гб RAM 256 потенциальных коннектов к MySQL Память для одного коннекта: read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size swap, OOM, деградация производительности всей системы
- 6. Двухуровневая схема Frontend – чаще всего nginx Backend – Apache, PHP-FPM
- 7. Некоторые ключевые моменты настройки Backend 192.168.1.1:8888 + Можно обращаться снаружи мимо фронтенда - Могут возникнуть лишние редиректы 127.0.0.2:80 - Нельзя обращаться снаружи мимо фронтенда + Нет проблем с неправильным портом
- 8. Backend StartServers 10 MinSpareServers 10 MaxSpareServers 20 MaxClients 20 MaxRequestsPerChild 500 Проверить лог – нет попаданий статики
- 9. Frontend # cat /proc/cpuinfo | grep "processor" | wc -l worker_processes 8; # max_clients = worker_processes * worker_connections events { use epoll; worker_connections 10240; } http { # по умолчанию - 1m client_max_body_size 1024m;
- 10. Frontend # больше - больше памяти, меньше - чаще пишем на диск client_body_buffer_size 4m; # максимально быстро получаем ответ от бэкенда proxy_buffering on; gzip gzip_proxied gzip_static gzip_types gzip_min_length on; any; on; application/x-javascript text/css; 1100;
- 11. А без Apache? PHP-FPM http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html Найти все .htaccess и перенести логику в конфиг nginx upstream backend { server unix:/opt/php/var/run/php1.sock; server unix:/opt/php/var/run/php2.sock; server unix:/opt/php/var/run/php3.sock; }
- 12. А без Apache? PHP-FPM location ~ .php$ { root /var/www/chroot/var/www/html; fastcgi_intercept_errors on; fastcgi_pass backend; fastcgi_index index.php; include fastcgi_params; fastcgi_param DOCUMENT_ROOT /var/www/html; fastcgi_param SCRIPT_FILENAME /var/www/html/$fastcgi_script_name; fastcgi_param SERVER_NAME $host; fastcgi_split_path_info fastcgi_param PATH_INFO } ^(.+.php)(.*)$; $fastcgi_path_info;
- 13. php-fpm.conf ; рестартовать при ошибках emergency_restart_threshold = 1 emergency_restart_interval = 10 [www1] listen=/opt/php/var/run/php1.sock # echo 10240 > /proc/sys/net/core/somaxconn listen.backlog = 10240 pm = static pm.max_children = 5 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 5
- 14. php-fpm.conf request_slowlog_timeout = 5 slowlog = /opt/php/var/log/www.slow_access.log ; не open_basedir в php.ini !!! chroot = /var/www/chroot php_admin_value[memory_limit] = 256M security.limit_extensions = .php [www2] ; ---------- // ---------------; разные chroot для виртхостов ; разные лимиты
- 15. Прекомпиляторы Zend Optimizer+ (Zend Server) – самый быстрый… и самый «непрозрачный» eAccelerator APC extension=apc.so apc.enabled=1 apc.max_file_size=5M apc.shm_size=256M apc.ttl=7200 apc.num_files_hint=55000 apc.stat=0 ; аккуратно!
- 16. apc.php
- 17. Итог Система стабилизирована по памяти Нет деградации системы при возрастающей нагрузке – обслуживаем максимум запросов, остальные ожидают в очереди Можем попробовать persistent connections для базы – у нас фиксированное число процессов Не тратим память на отдачу статики Не занимаем backend медленными запросами клиентов Используем сжатие – быстрее отдаем на медленных каналах Разгружаем процессор за счет прекомпиляции PHP
- 18. Двухуровневая схема Frontend – чаще всего nginx Backend – Apache, PHP-FPM
- 20. Варианты масштабирования до 10.0 1. Разделение на два сервера: веб-сервер + база данных. 2. Увеличение мощности оборудования (чем мощнее – тем дороже; рост стоимости не пропорционален). 3. Выделение кеша на один внешний сервер через memcached. 4. Переход на Oracle (минимальная лицензия +5000$ за процессор). 5. Создание Oracle RAC (Real Application Cluster). Проект – около 150 000$ (оборудование + лицензия + «общая полка»). Очень мало специалистов. Для большинства клиентов производительности достаточно, но не решены проблемы отказоустойчивости, резервирования, сетевой доступности.
- 21. 1С-Битрикс: Веб-кластер «1С-Битрикс: Веб-кластер» - это комбинация технологий: • • • • • Вертикальный шардинг (вынесение модулей на отдельные серверы MySQL) Репликация MySQL (Oracle и MS SQL в дальнейшем) и балансирование нагрузки между серверами Распределенный кеш данных (memcached) Непрерывность сессий между веб-серверами (хранение сессий в базе данных) Кластеризация веб-сервера: – Синхронизация файлов – Балансирование нагрузки между серверами
- 22. 1С-Битрикс: Веб-кластер Тестовый веб-кластер – в «облаке» Amazon
- 23. Шардинг Аккаунты a-m База данных MySQL 1 База данных MySQL База данных MySQL 1 База данных MySQL База данных MySQL 2 База данных MySQL 2 Аккаунты n-z Вертикальный шардинг Горизонтальный шардинг
- 24. Вертикальный шардинг Разделение одной базы данных вебприложения на две и более базы данных за счет выделения отдельных модулей, без изменения логики работы веб-приложения: • Веб-аналитика • Поиск 1. Эффективное распределение нагрузки. 2. Масштабирование. 3. Разделение больших объемов данных.
- 25. Репликация и балансировка нагрузки MySQL • Гибкая балансировка нагрузки SQL • Простота администрирования • Дешевое и быстрое неограниченное масштабирование • Он-лайн бэкап • Не требуется доработка логики веб-приложения
- 26. Масштабирование при росте нагрузки MySQL Веб-сервер «1С-Битрикс: Веб-кластер» SQL-балансировщик 1С-Битрикс База данных MySQL MASTER База данных MySQL SLAVE 1 База данных MySQL SLAVE … MySQL replication, mixedmode База данных MySQL SLAVE N
- 27. Репликация и балансировка нагрузки MySQL
- 28. Распределенный кеш данных (memcached) • Высокая эффективность - за счет централизованного использования кэша вебприложением • Надежность - за счет устойчивости подсистемы кешировния к выходу из строя отдельных компонентов • Неограниченная масштабируемость - за счет добавления новых memcachedсерверов. memcached 1 30% memcached 2 memcached 3 40% 30% Веб-кластер «1С-Битрикс» Веб-сервер Веб-сервер Веб-сервер
- 29. Распределенный кеш данных (memcached)
- 30. Непрерывность сессий между веб-серверами Пользовательская сессия должна быть "прозрачной" для всех серверов веб-кластера. 1. После авторизации на одном из серверов пользователь должен считаться авторизованных и для всех других серверов. 2. И наоборот - окончание сессии на любом сервере должно означать ее окончание на всех серверах сразу.
- 31. Задача: масштабирование при росте нагрузки Высокая посещаемость Нагрузка на CPU <50% Балансировщик нагрузки Веб-сервер Нода 1 «1С-Битрикс: Веб-кластер» Веб-сервер Авто-синхронизация База данных MySQL Нода 2 «1С-Битрикс: Веб-кластер» 1) Нагрузка равномерно распределяется между нодами веб-кластера 2) Сервера приложений не перегружены и работают в устойчивом штатном режиме
- 32. Задача: масштабирование при росте нагрузки Очень высокая посещаемость Балансировщик нагрузки Нода 1 «1С-Битрикс: Веб-кластер» Нода 2 «1С-Битрикс: Веб-кластер» База данных MySQL … Нода N «1С-Битрикс: Веб-кластер»
- 33. Задача синхронизации файлов Веб-сервер 1 Веб-сервер 2 ? /var/www
- 34. Синхронизация дисковых систем Два типа: 1. Синхронный: • Общая «дисковая полка» (дорого, не резервирует данные) • Сетевые средства – NFS (очень медленно) • OCFS2 • DRDB 2. Асинхронный (синхронизация локальных дисков) • rsync • csync2
- 35. Почему мы выбрали csync2? • Быстрый доступ к файлам приложения за счет использования локальных хранилищ. • Высокая скорость работы. • Низкое потребление ресурсов (CPU, дисковые операции). Два этих фактора позволяют запускать процесс синхронизации максимально часто, поэтому данные на серверах становятся идентичными практически в "реальном времени". • Простота настройки для обмена данными между любым количеством серверов. • Возможность синхронизации удаления файлов. • Защищенный обмен данными между хостами (SSL).
- 36. Тип 2: синхронизация локальных дисков Нода 1 «1С-Битрикс: Веб-кластер» Нода 2 «1С-Битрикс: Веб-кластер» Csync2 Csync2 /var/www /var/www Нода 3 «1С-Битрикс: Веб-кластер» Csync2 /var/www
- 37. Способы балансирование нагрузки • DNS сервер с несколькими записями типа A и разными IP адресами и коротким TTL • NGINX на отдельном оборудовании • Аппаратный маршрутизатор с балансированием нагрузки • Балансировка силами дата центра (Amazon EC2)
- 38. Балансировщик (клиентские запросы по HTTP) Веб-сервер 1 memcached 1 MySQL master Веб-сервер 2 MySQL slave memcached 1
- 39. 14000000 12000000 10000000 8000000 2007 год 6000000 2010 год 4000000 2000000 0 "Старт" "Бизнес" +110% +430% За три года – на 430% быстрее!