Сергей Рыжиков. Директор "1С-Битрикс". Как настроить двухуровневую конфигурацию веб-приложения. Производительность. Нагруженный Форк

1. Как настроить двухуровневую
конфигурацию веб-приложения
Сергей Рыжиков
Директор
«1С-Битрикс»

2. Традиционное устройство
веб-приложения
Веб-приложение
Кэширование
на диск
База данных

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

19. Производительность

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% быстрее!