От скорости сайта зависит многое: количество отказов, брошенных корзин. Согласно исследованию Google, большинство посетителей не ждёт загрузки больше 3 секунд и уходит к конкурентам. Бывает, что сайт тормозит только в момент пиковых нагрузок (часы наибольшей посещаемости, периоды акций) и вы теряете всех, кого так тщательно привлекали.
От чего зависит скорость сайта на Битриксе?
- оптимизация компонентов сайта
- набор модулей
- оптимизация серверного ПО
- достаточное количество ресурсов сервера
С оптимизацией компонентов сайта вам поможет разработчик. Но если есть навыки администрирования, можно перейти на nginx+php-fpm и оптимизировать настройки.
В большинстве случаев, чтобы повысить производительность, нужен анализ текущей нагрузки на сервер. Такое умеют наши администраторы. Но есть и базовые настройки, которых достаточно, чтобы улучшить производительность Битрикс на большинстве серверов. Америку не открываем, если вы хорошо знакомы с *nix, едва ли вы обнаружите что-то новое.
В качестве ОС будем использовать минимальную версию Debian 9. В конце сравним показатели получившейся конфигурации с BitrixVM.
Веб-сервер — Nginx
Лучшим решением будет использование в качестве веб-сервера Nginx. Он шустро работает со статичным контентом и не плодит форков, как это делает apache2. Форки apache2 часто оказываются причиной перерасхода сервером оперативной памяти, потому выбор Nginx снижает требования к объему RAM.
Ставим и конфигурируем Nginx:
apt install nginx
upstream php {
server 127.0.0.1:9000;
}
server {
root /var/www/html/;
server_name _;
listen 80 default_server;
index index.php;
location / {
try_files \$uri \$uri/ /bitrix/urlrewrite.php?\$args;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass php;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME \$document_root/\$fastcgi_script_name;
}
location ~* \.(js|css|png|jpg|jpeg|gif|ico)\$ {
expires max;
log_not_found off;
}
}
Важно! Это только базовая конфигурация, для специфичных функций могут понадобится дополнительные настройки. Наиболее совместимую конфигурацию можно взять из битрикс-окружения. Это учитывается в нашем GT-рецепте.
Сервер БД
В качестве сервера БД используем MariaDB 10.1 из репозитория ОС. Практика показывает, что для нашей задачи гнаться за последними версиями MySQL/MariaDB совершенно не обязательно — значительной разницы в производительности нет.
Важно! После развертывания сайта нужно выполнить «Проверку системы» с исправлением ошибок структуры БД, а также «Оптимизацию БД», оба действия выполняются в админке Битрикс. Эти операции создадут индексы и устранят фрагментацию, что благотворно скажется на производительности.
Ставим и конфигурируем MariaDB:
apt install mariadb-server
cat <<-\EOF >/etc/mysql/mysql.conf.d/server.conf
[mysqld]
innodb_buffer_pool_size=384M #это значение нужно подбирать исходя из размера innodb таблиц
innodb_buffer_pool_instances=1 # По одному пункту на каждый Гб innodb_buffer_pool_size
innodb_flush_log_at_trx_commit=2
innodb_flush_method=O_DIRECT
query_cache_type=1
query_cache_size=16M
query_cache_limit=4M
key_buffer_size=256M
join_buffer_size=2M
sort_buffer_size=4M
tmp_table_size=128M
max_heap_table_size=128M
thread_cache_size=4
table_open_cache=2048
max_allowed_packet=128M
transaction-isolation=READ-COMMITTED
performance_schema=OFF
sql_mode=""
EOF
PHP-FPM
Ещё одна причина отказа от apache2 — использование php-fpm, наиболее быстрого режима работы php-интерпретатора. Наиболее производительной на текущей момент является php7.3, однако в официальном репозитории Debian 9 мы имеем php7. Из соображений связности с предыдущей статьей про производительность Битрикс тут мы тоже будем использовать php7 из репозитория Debian.
Ставим и конфигурируем php-fpm:
apt install php-fpm php-opcache php-mysqli php-gd php-curl php-xml php-mbstring php-json
cat <<-\EOF >/etc/mysql/mysql.conf.d/server.conf
;###Bitrix optimize
date.timezone=Europe/Moscow
short_open_tag=1
max_input_vars=10000
mbstring.func_overload=2 ;Этот пункт нужен если используется utf8
mbstring.internal_encoding=utf-8 ;Этот пункт нужен если используется utf8
upload_max_filesize=64M
post_max_size=64M
opcache.max_accelerated_files=100000
realpath_cache_size=4096k
memory_limit=512M
pcre.jit=0
opcache.revalidate_freq=0
EOF
cat <<-\EOF >/etc/php/7.0/fpm/php.ini
[www]
user = www-data
group = www-data
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 5
EOF
Governor
Этот пункт актуален только для выделенных серверов. Планировщик частоты процессора нужен для работы функций энергосбережения. Более низкие частоты процессора требуют меньше напряжения. В нашем случае потребности экономить электричество нет, потому нужно переключить планировщик в режим performance.
Настраиваем и применяем:
apt install cpufrequtils echo 'GOVERNOR="performance"' > /etc/default/cpufrequtils cpupower frequency-set --governor performance
Сравниваем производительность
Производительность получившейся конфигурации:
Производительность в окружении BitrixVM:
Если вы оптимизировали сервер по инструкции, но производительность всё равно не устраивает — нужно провести диагностику нагрузки и решить, что вам требуется:
1. Обратиться к разработчику для оптимизации кода
2. Найти дополнительные варианты оптимизации
Например, перенести сессии в оперативную память, настроить Nginx кеширование, заблокировать нежелательных ботов.
3. Добавить ресурсов сервера
Даже в случае с идеально написанным сайтом и не менее идеально оптимизированным сервером в какой то момент узким местом окажутся ресурсы.
Недостаток оперативной памяти не позволит полностью задействовать процессор, а избыток памяти при полностью загруженном работой процессоре не принесёт никакой пользы. Если узким местом оказывается пропускная способность сети — пришло время задуматься о переходе на выделенные серверы с гигабитным каналом.
