Для работы портала необходимо настроить Push-сервер. Сервис запущен, необходимо сделать настройки.
Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://имя_сайта/bitrix/admin/settings.php?lang=ru&mid=pull
Подробнее...[/di] или с помощью конфигурационного файла. Покажем, как это делается вторым способом.
Чтобы выполнить все операции из этой главы, вам необходимо знать основы серверного администрирования. Хотя компания 1С-Битрикс тестировала установку на другие окружения, лучше не использовать их как основные платформы для эксплуатации продуктов Bitrix Framework.
Ниже приведен список всех пакетов, необходимых для установки коробочной версии Битрикс24. Для 1С-Битрикс: Управление сайтом список аналогичен, за исключением Push-сервера.
Конфигурация взята из виртуальной машины и может показаться избыточной, но фактически поддерживает все возможности, что и виртуальная машина.
Чтобы скачать и распаковать на сервере файлы конфигурации, можно выполнить команды:
Скопируйте файлы конфигурации в папку /etc/nginx/.
Чтобы заработала конфигурация, пропишите имена в локальных адресах.
Если сервисы расположены на другом хосте, укажите правильный IP-адрес.
По умолчанию в Astra сервер Apache использует 80 порт и поставлен на автозапуск. Поэтому перед запуском сервера Nginx на время выключите Apache (на данный момент он еще не настроен). Остановите Apache.
Запустите Nginx.
В данной версии централизованное хранилище PHP конфигурации — папка /etc/php/8.2 (для версии PHP 8.2):
В дефолтной конфигурации /sites-enabled/000-default.conf — это ссылка на файл в каталоге /sites-available.
Работа Push-сервера невозможна без сервиса Redis. Для этого в конфигураторе следует:
Nginx проксирует запрос на Push-сервис выбранного типа. Запросы получения сообщений sub
— публичные, проксируются со стандартных портов 80/443. Запросы публикации pub
— доступны только с внутреннего адреса сервера.
Nodejs-процессы делятся на два типа.
Push-сервер
Для работы портала необходимо настроить Push-сервер. Сервис запущен, необходимо сделать настройки.
Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://имя_сайта/bitrix/admin/settings.php?lang=ru&mid=pull
Подробнее...[/di] или с помощью конфигурационного файла. Покажем, как это делается вторым способом.
Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php, добавив следующую секцию:
return array (
'pull' => Array(
'value' => array(
'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
'nginx_version' => '4',
'nginx_command_per_hit' => '100',
'nginx' => 'Y',
'nginx_headers' => 'N',
'push' => 'Y',
'websocket' => 'Y',
'signature_key' => 'PUTTHEPRIVATEKEYHERE',
'signature_algo' => 'sha1',
'guest' => 'N',
),
),
...
Параметр
signature_key
должен содержать тот же ключ, который вы указали в /etc/sysconfig/push-server-multi в соответствующем параметре. Если все хорошо, то после перезапуска службы apache2:
systemctl restart apache2
Вы увидите запросы к Push-серверу:
Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols
Настройка окружения для SLES 15
В главе описаны настройки окружения для операционной системы SUSE Linux Enterprise Server 15 для установки на неё продуктов 1С-Битрикс24 коробочная версия
и 1С-Битрикс: Управление сайтом
. Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.
Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.
Установка и настройка ОС
Установка
Начнем с установки дистрибутива SUSE Linux Enterprise Server 15 (SLES 15). В процессе установки доступен выбор дополнительных модулей и расширений. Нам потребуется сервер с минимальной настройкой.
Внимание: Дальнейшая настройка будет показана именно на базе такой установки.
Также потребуется выполнить активацию подписки. Её можно произвести во время установки. Либо настроить уже после установки командой:
SUSEConnect -e EMAIL_ADDRESS -r REGISTER_CODE
Подписка привязывается к аккаунту. Поэтому при активации в качестве email_address и password указывайте те данные, с помощью которых Вы регистрировались на официальном сайте SUSE.
В качестве менеджера пакетов SUSE использует [dw]zypper[/dw][di]Zypper - консольный менеджер пакетов, основанный на библиотеке libzypp, используется в дистрибутиве GNU/Linux openSUSE.[/di].
- Обновите систему до последней стабильной версии.
zypper refresh
zypper update
- Подключите дополнительные расширения (официальные репозитории) для установки дополнительных пакетов:
# модули python
SUSEConnect --product sle-module-python2/15.2/x86_64
# для php и nodejs (push-server)
SUSEConnect --product sle-module-web-scripting/15.2/x86_64
Все доступные репозитории можно посмотреть c помощью команды:
SUSEConnect --list-extensions
По умолчанию SELinux не устанавливается для минимальной установки, поэтому каких-либо дополнительных настроек для его отключения не требуется.
Настройка портов
Обязательно нужно открыть порты:
- 22 – ssh доступ;
- 80 / 443 – http / https web-сервер;
Остальные порты для:
- ntlm
- сервера мгновенных сообщений;
- xmpp-сервера
нужно открывать, если только они используются. Можно выбрать произвольные порты, а можно те же, что используются в CentOS:
- 8890 / 8891 – http/https ntlm;
- 8893 / 8894 – http/https сервер мгновенных сообщений;
- 5222 / 5223 – http/https.
Установка пакетов
Ниже приведен весь список пакетов, который нам понадобится для 1С-Битрикс24 коробочная версия
. Для 1С-Битрикс: Управление сайтом
из этого набора не нужен только push-server.
Установка по шагам
- Установите apache 2.4 и php 7.2:
zypper -n install apache2
zypper -n install php7 php7 php7 \
php7 php7-opcache php7-zip php7-posix \
php7-zlib php7-openssl php7-mbstring \
php7-bz2 php7-curl php7-iconv \
php7-json php7-pecl php7-devel php7-sockets \
php7-gd apache2-mod_php7 php7-mysql
С 01.02.2023 ограничивается поддержка наших продуктов на PHP версии ниже 8.0. Рекомендуемая - 8.1 и выше. Поэтому после установки необходимо обновить PHP до версии не ниже 8.0.
- Установите Nginx 1.16:
zypper -n install nginx
- Установите MariaDB сервер 10.4 :
zypper -n install mariadb
- Установите Node (версия 14) и npm (push-server):
zypper -n install nodejs10
- Установите Redis:
zypper -n install redis
Конфигурация Nginx
Выполним конфигурацию Nginx.
- Рабочий каталог для сайта -
/var/www/html/bx-site
.
- Пользователь для web окружения - wwwrun.
Конфигурация nginx сервера:
/etc/nginx/nginx.conf # основной конфигурационный файл
|_conf.d/upstreams.conf # конфигурация для upstream серверов: apache && push-server
|_conf.d/maps-composite_settings.conf # переменные используемые для кеша
|_conf.d/maps.conf # дополнительные переменные
|_conf.d/http-add_header.conf # CORS заголовки
|_sites-available/*.conf # подключаем сайты
|_default.conf # сайт по умолчанию (настраиваем только 80 порт)
|_conf.d/bx_temp.conf # конфигурация BX_TEMPORARY_FILES_DIRECTORY
|_conf.d/bitrix.conf # дефолтная конфигурация сайта
|_rtc.conf # проксирование запросов на push-server (публикация)
Дефолтная конфигурация сайта:
conf.d/bitrix.conf # основные блоки со включенным по умолчанию кешем в файлах
|_conf.d/bitrix_general.conf # отдача статики, быстрая отдача для внешних хранилищ и прочее
|_conf.d/errors.conf # обработка ошибок
|_conf.d/im_subscrider.conf # проксирование запросов на push-server (получение)
|_conf.d/bitrix_block.conf # блокировки по умолчанию
Конфигурация взята из виртуальной машины и может показаться избыточной, но фактически поддерживает все те же возможности, что и виртуальная машина.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: sles15/nginx
.
Разместите их в директории /etc/nginx/
.
В сервисе используются имена для проксирования на определенные службы:
- httpd - проксирование запросов на apache;
- push - проксирование запросов на push-server.
Чтобы заработала конфигурация, необходимо прописать их в локальных адресах. Если сервисы расположены на другом хосте, укажите здесь правильный адрес:
echo "127.0.0.1 push httpd" >> /etc/hosts
Запустите сервис:
systemctl --now enable nginx
Добавьте правила для firewalld:
firewall-cmd --zone=public --add-service=https --permanent
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload
Конфигурация PHP
В данной версии установки хранилище конфигов централизованное: -- /etc/php7/conf.d
Минимально необходимо добавить такие настройки:
- для модуля OPCache (opcache.ini):
opcache.max_accelerated_files = 100000
opcache.revalidate_freq = 0
добавляем настройки в файл zx-bitrix.ini:
display_errors = Off
error_reporting = E_ALL
error_log = '/var/log/php/error.log'
; Set some more PHP parameters
enable_dl = Off
short_open_tag = On
allow_url_fopen = On
# Security headers
mail.add_x_header = Off
expose_php = Off
...
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для PHP расположены в папке: sles15/php.d
.
Разместите их в директории /etc/php7/conf.d/
.
Установите в качестве владельца пользователя и группу root:
chown root:root /etc/php7/conf.d/ -R
Конфигурация Apache
По умолчанию Apache настроен на дефолтный сайт в каталоге /var/www/html
.
Основное, что требуется сделать для настройки конфигурации Apache:
- изменить каталог для сайта на
var/www/html/bx-site
;
- изменить порт, который слушает сервис (так как в качестве внешнего сервиса используем nginx);
- импортировать настройки для сайта из виртуальной машины.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Apache расположены в папке: sles15/httpd
.
Разместите их в директории /etc/apache2/
.
Настроить требуется два файла:
vhosts.d/default.conf
- заменить каталог в описании сайта на var/www/html/bx-site
;
httpd/listen.conf
- указать для Listen порт 8090.
После этого запустите сервис:
systemctl --now enable apache2
Конфигурация MariaDB
Для конфигурации MariaDB требуется выполнить такие настройки:
- transaction-isolation изменить на
READ-COMMITTED
;
- innodb_flush_method установить равным
O_DIRECT
(желательная, но не обязательная настройка);
- innodb_flush_log_at_trx_commit установить равным 2 (желательная, но не обязательная настройка).
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для MariaDB находятся в папке: sles15/my.cnf.d
.
Разместите их в директории /etc/my.cnf.d/
.
Запустите сервис:
systemctl --now enable mariadb
Настройки сервис выполняются через mysql_secure_installation.
Конфигурация Redis
Данный сервис нам нужен для организации Push-сервера.
Основное, что нам важно установить в конфигурации:
- включить файловый сокет для работы;
- отключить сброс данных на диск (для работы Push-сервера нам не нужна эта возможность);
- группу пользователя.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Redis расположены в папке: sles15/redis
.
Разместите их в директории /etc/redis/
.
su -
usermod -g www redis
chown -R redis:www /etc/redis/ /var/log/redis/ /var/lib/redis/
mkdir /etc/systemd/system/redis@.service.d
echo -e '[Service]\nGroup=www' > /etc/systemd/system/redis@.service.d/custom.conf
systemctl daemon-reload
Запустите сервис
systemctl --now enable redis@default
Конфигурация Push-server
Схема работы:
----------------------- ---------------------------------------------------
| nginx: 0.0.0.0:80 | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
----------------------- ---------------------------------------------------
----------------------- ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
----------------------- ---------------------------------------------------
Nginx проксирует запрос на push-сервис выбранного типа. Запросы получения сообщений (например, sub) - публичные и проксируются со стандартных портов 80/443. Запросы публикации (pub) доступны только с внутреннего адреса сервера.
Nodejs-процессы делятся на два типа:
- Процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Слушают порты 8010-8015;
- Процессы, отвечающие за отправку сообщения в канал. Слушают порты 9010-9011.
Для запуска Push-сервера нам понадобятся:
- nodejs & npm ;
- архив сервиса и его модулей.
Для установки понадобится Python и утилита make:
zypper install python3 make wget -y
Выполните действия:
- Скачайте архив с репозитория repo.bitrix.info
wget https://repo.bitrix.info/vm/push-server-0.2.2.tgz
или с сайта архив push-server-0.2.2.tgz и разместите его в директории /opt
. Выполните установку:
su -
cd /opt
npm install --production ./push-server-0.2.2.tgz
Установка закончится строкой:
+ push-server@0.2.2
added 65 packages from 78 contributors and audited 65 packages in 45.77s
- Выполните (исключительно для удобства):
su -
ln -sf /opt/node_modules/push-server/logs /var/log/push-server
ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server
- Копируем файлы сервиса и основную конфигурацию:
su -
cd /opt/node_modules/push-server
cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
cp etc/sysconfig/push-server-multi /etc/sysconfig/push-server-multi
cp etc/push-server/push-server.service /etc/systemd/system/
ln -sf /opt/node_modules/push-server /opt/push-server
- Создайте временный каталог:
echo 'd /tmp/push-server 0770 wwwrun www -' > /etc/tmpfiles.d/push-server.conf
systemd-tmpfiles --remove --create
Отредактируйте конфигурационный файл /etc/sysconfig/push-server-multi
. В нём нужно исправить/добавить параметры:
- USER/GROUP - пользователь, под которым будет запущен сервис;
- SECURITY_KEY - cекретный ключ для подписи соединения между клиентами и пуш-сервером;
Примечание: Длина ключа не имеет значения. В ключе можно использовать только буквы латинского алфавита и цифры, спецсимволы запрещены. Но имейте в виду, что простой короткий ключ небезопасен. Можно генерировать его, например, таким образом:
cat /dev/urandom |tr -dc A-Za-z0-9 | head -c 128
- RUN_DIR - директория для хранения PID файлов процесса.
Пример настроек параметров:
GROUP=www
USER=wwwrun
SECURITY_KEY="SECURITYKEY123456"
RUN_DIR=/tmp/push-server
REDIS_SOCK=/var/run/redis/default.sock
- Каждый nodejs процесс будет запущен как отдельный процесс. Сгенерируйте конфигурации:
/usr/local/bin/push-server-multi configs pub
/usr/local/bin/push-server-multi configs sub
Сгенерированные конфигурации в формате [dw]json[/dw][di]push-server-sub-80XX.json
push-server-pub-90XX.json[/di] будут размещены в каталоге: /etc/push-server/
.
- Измените пользователя и путь к скрипту запуска в конфигурационном файле сервиса
/etc/systemd/system/push-server.service
:
[Service]
User=wwwrun
Group=www
ExecStart=/usr/local/bin/push-server-multi systemd_start
ExecStop=/usr/local/bin/push-server-multi stop
...
- Измените права доступа на каталог с логами:
chown wwwrun:www /opt/node_modules/push-server/logs /tmp/push-server -RH
- Переконфигурируйте:
systemctl daemon-reload
- Запустите сервис:
systemctl --now enable push-server
- Перейдите в конфигурацию push модуля (настройки сайта) и включите использование локального push-сервера (последняя версия).
Дополнительно нужно будет указать секретный ключ SECURITY_KEY, который мы настраивали выше в файле
/etc/sysconfig/push-server-multi
.
Конфигурация сайта
Сайт
Создайте рабочий каталог:
mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown www-data:www-data /var/www/html/bx-site -R
Аналогичным образом можно скачать нужный дистрибутив и установить его в каталог: /var/www/html/bx-site
.
Создайте базу данных и пользователя:
create database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';
Необходимо заменить PASSWORD на пароль, который будет использоваться для доступа к БД.
Push-server
Для работы портала необходимо настроить push-server. Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.
Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php
, добавив следующую секцию:
return array (
'pull' => Array(
'value' => array(
'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
'nginx_version' => '4',
'nginx_command_per_hit' => '100',
'nginx' => 'Y',
'nginx_headers' => 'N',
'push' => 'Y',
'websocket' => 'Y',
'signature_key' => 'PUTTHEPRIVATEKEYHERE',
'signature_algo' => 'sha1',
'guest' => 'N',
),
),
...
Обратите внимание, что signature_key должен содержать тот же ключ, который указан в /etc/sysconfig/push-server-multi
в соответствующем ключе. Если все хорошо, то после перезапуска apache2:
systemctl restart apache2
Вы увидите запросы к push-server:
Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols
Настройка окружения для RedHat8
В главе описаны настройки окружения для операционной системы RedHat8 для установки на неё продуктов 1С-Битрикс24 (коробочная версия)
и 1С-Битрикс: Управление сайтом
. Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.
Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.
Установка и настройка ОС
Установка
Для начала необходимо установить дистрибутив Red Hat Enterprise Linux 8 (RedHat8). В процессе установки выберите сервер с минимальными настройками.
Важно! Дальнейшая настройка будет показана на базе именно такой установки.
По завершении установки нужно активизировать подписку, иначе не будут работать установки и обновления системы:
subscription-manager register --username email_address --password password --auto-attach
Подписка привязана к аккаунту. В качестве email_address и password укажите тот, с помощью которого регистрировались на сайте RedHat.
Для авторизации можно вместо e-mail использовать логин, указанный при регистрации.
Для установки можно использовать только официальные репозитории от RedHat.
В качестве менеджера пакетов используется dnf. Обновите систему до последней стабильной версии. Отключите selinux
su -
dnf update -y
echo 'SELINUX=disabled' > /etc/sysconfig/selinux
reboot
Настройка портов
Обязательно нужно открыть порты:
- 22 – ssh доступ;
- 80 / 443 – http / https web-сервер;
Остальные порты для:
- ntlm
- сервера мгновенных сообщений;
- xmpp-сервера
нужно открывать, если только они используются. Можно выбрать произвольные порты, а можно те же, что используются в CentOS:
- 8890 / 8891 – http/https ntlm;
- 8893 / 8894 – http/https сервер мгновенных сообщений;
- 5222 / 5223 – http/https.
Установка пакетов
Ниже приведен весь список пакетов, который нам понадобится для 1С-Битрикс24 коробочная версия
. Для 1С-Битрикс: Управление сайтом
не нужен только push-server.
- Установите apache 2.4 и php 7.2:
dnf -y install httpd
dnf -y install php php php-cli php-common \
php-devel php-gd php-json php-mbstring \
php-mysqlnd php-opcache php-pdo php-pear \
php-pecl-apcu php-pecl-zip php-process php-xml php-ldap
С 01.02.2023 ограничивается поддержка наших продуктов на PHP версии ниже 8.0. Рекомендуемая версия PHP – 8.1 и выше. Поэтому после установки необходимо обновить PHP до версии не ниже 8.0.
- Установите nginx (1.14 версия):
dnf install nginx -y
- Установите MariaDB сервер (10.1 версия):
dnf install mariadb -y
- Установите node и npm (push-server):
dnf install nodejs -y
- Установите redis:
dnf install redis -y
Конфигурация Nginx
Выполните конфигурацию Nginx.
- Рабочий каталог для сайта -
/var/www/html/bx-site
.
- Пользователь для web окружения - nginx, группа apache.
Конфигурация nginx сервера:
/etc/nginx/nginx.conf # основной конфигурационный файл
|_conf.d/upstreams.conf # конфигурация для upstream серверов: apache && push-server
|_conf.d/maps-composite_settings.conf # переменные, используемые для кеша
|_conf.d/maps.conf # дополнительные переменные
|_conf.d/http-add_header.conf # CORS заголовки
|_sites-available/*.conf # подключаем сайты
|_default.conf # сайт по умолчанию (настраиваем только 80 порт)
|_conf.d/bx_temp.conf # конфигурация BX_TEMPORARY_FILES_DIRECTORY
|_conf.d/bitrix.conf # дефолтная конфигурация сайта
|_rtc.conf # проксирование запросов на push-server (публикация)
Дефолтная конфигурация сайта:
conf.d/bitrix.conf # основный блок с включенным по умолчанию кешем в файлах
|_conf.d/bitrix_general.conf # отдача статики, быстрая отдача для внешних хранилищ и прочее
|_conf.d/errors.conf # обработка ошибок
|_conf.d/im_subscrider.conf # проксирование запросов на push-server (получение)
|_conf.d/bitrix_block.conf # блокировки по умолчанию
Конфигурация взята из виртуальной машины и может показаться избыточной, но фактически поддерживает все те же возможности, что и виртуальная машина.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redhat8/nginx
.
Разместите их в директории /etc/nginx/
.
В сервисе используются имена для проксирования на определенные службы:
- httpd – проксирование запросов на apache;
- push – проксирование запросов на push-server.
Чтобы заработала конфигурация, необходимо прописать их в локальных адресах. Если сервисы расположены на другом хосте, укажите здесь правильный адрес:
echo "127.0.0.1 push httpd" >> /etc/hosts
Запустите сервис:
systemctl --now enable nginx
Добавьте правила для firewalld:
firewall-cmd --zone=public --add-service=https --permanent
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload
Конфигурация PHP
В данной версии установки централизованное хранилище конфигов: /etc/php.d
.
Минимальные настройки, которые необходимо добавить:
- для модуля opcache:
opcache.max_accelerated_files = 100000
opcache.revalidate_freq = 0
- добавьте настройки bitrexenv.ini:
display_errors = Off
error_reporting = E_ALL
error_log = '/var/log/php/error.log'
; Set some more PHP parameters
enable_dl = Off
short_open_tag = On
allow_url_fopen = On
# Security headers
mail.add_x_header = Off
expose_php = Off
...
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redhat8/php.d
.
Разместите их в директории /etc/php.d/
.
Конфигурация Apache
По умолчанию Apache настроен на дефолтный сайт в каталоге /var/www/html
.
Основные действия для настройки конфигурации Apache:
- изменить каталог для сайта на
var/www/html/bx-site
;
- изменить порт, который слушает сервис (так как в качестве внешнего сервиса будет использоваться nginx);
- импортировать настройки для сайта из виртуальной машины.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redhat8/httpd
.
Разместите их в директории /etc/httpd/
.
Необходимо настроить файлы:
conf.d/default.conf
– в описании сайта замените каталог на conf/httpd.conf
;
conf/httpd.conf
– в Listen замените порт на 8090;
conf.modules.d
– меняем на 00-mpm.conf.
Модуль php для apache работает только с менеджером процессов prefork. Включите его.
Запустите сервис:
systemctl --now enable httpd
Конфигурация MariaDB
Для конфигурации MariaDB выполните следующие настройки:
- transaction-isolation измените на
READ-COMMITTED
;
- innodb_flush_method установите равным
O_DIRECT
(рекомендованная, но не обязательная настройка);
- innodb_flush_log_at_trx_commit установите равным 2 (рекомендованная, но не обязательная настройка).
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redhat8/my.cnf.d
.
Разместите их в директории /etc/my.cnf.d/
.
Запустите сервис:
systemctl --now enable mariadb
Настройка сервиса выполняется через mysql_secure_installation.
Конфигурация Redis
Данный сервис необходим для организации Push-сервера.
Основные настройки, которые необходимо выполнить в конфигураторе:
- включить файловый сокет для работы;
- отключить сброс данных на диск (для работы Push-сервера эта возможность не нужна);
- установить группу пользователя.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redhat8/redis
.
Разместите их в директории /etc/redis/
и выполните команды:
su -
usermod -g apache redis
chown root:apache /etc/redis/ /var/log/redis/
mkdir /etc/systemd/system/redis.service.d
echo -e '[Service]\nGroup=apache' > /etc/systemd/system/redis.service.d/custom.conf
systemctl daemon-reload
Запустите сервис:
systemctl --now enable redis
Конфигурация Push-server
Схема работы:
----------------------- ---------------------------------------------------
| nginx: 0.0.0.0:80 | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
----------------------- ---------------------------------------------------
----------------------- ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
----------------------- ---------------------------------------------------
Nginx проксирует запрос на push-сервис выбранного типа. Запросы получения сообщений (например, sub) – публичные, проксируются со стандартных портов 80/443. Запросы публикации (pub) – доступны только с внутреннего адреса сервера.
Nodejs-процессы делятся на два типа:
- Процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Слушают порты 8010-8015;
- Процессы, отвечающие за отправку сообщения в канал. Слушают порты 9010-9011.
Для запуска Push-сервера необходимы:
- nodejs & npm;
- архив сервиса и его модулей.
Для установки понадобится Python и утилита make:
dnf install python3 make -y
Выполните следующие действия:
- Скачайте и установите архив push-server-0.3.0.tgz:
su -
cd /opt
wget https://repo.bitrix.info/vm/push-server-0.3.0.tgz
npm install --production ./push-server-0.3.0.tgz
Установка закончится строкой:
+ push-server@0.3.0
added 65 packages in 46.522s
- Для удобства дальнейшей работы выполните команды:
su -
ln -sf /opt/node_modules/push-server/logs /var/log/push-server
ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server
- Скопируйте файлы сервиса и основную конфигурацию:
su -
cd /opt/node_modules/push-server
cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
cp etc/sysconfig/push-server-multi /etc/sysconfig/push-server-multi
cp etc/push-server/push-server.service /etc/systemd/system/
ln -sf /opt/node_modules/push-server /opt/push-server
- Создайте временный каталог:
echo 'd /tmp/push-server 0770 apache apache -' > /etc/tmpfiles.d/push-server.conf
systemd-tmpfiles --remove --create
Отредактируйте конфигурационный файл /etc/sysconfig/push-server-multi
. В нём нужно исправить/добавить параметры:
- SECURITY_KEY - cекретный ключ для подписи соединения между клиентами и пуш-сервером;
Примечание: Длина ключа не имеет значения. В ключе можно использовать только буквы латинского алфавита и цифры, спецсимволы запрещены. Но имейте в виду, что простой короткий ключ небезопасен. Можно генерировать его, например, таким образом:
cat /dev/urandom |tr -dc A-Za-z0-9 | head -c 128
- RUN_DIR - директория для хранения PID файлов процесса;
- USER/GROUP - пользователь, под которым будет запущен сервис.
Пример настроек параметров:
GROUP=apache
SECURITY_KEY="SECURITYKEY123456"
RUN_DIR=/tmp/push-server
- Каждый nodejs-процесс будет запущен как отдельный процесс. Сгенерируйте конфигурации:
/usr/local/bin/push-server-multi configs pub
/usr/local/bin/push-server-multi configs sub
Сгенерированные конфигурации в формате [dw]json[/dw][di]push-server-sub-80XX.json
push-server-pub-90XX.json[/di] будут размещены в каталоге: /etc/push-server/
.
- В конфигурационном файле сервиса
/etc/systemd/system/push-server.service
измените пользователя:
[Service]
User=apache
Group=apache
ExecStart=/usr/local/bin/push-server-multi systemd_start
...
- Измените права доступа на каталог с логами:
chown wwwrun:www /opt/node_modules/push-server/logs /tmp/push-server -RH
- Переконфигурируйте:
systemctl daemon-reload
- Запустите сервис:
systemctl --now enable push-server
- Перейдите в конфигурацию Push-модуля (настройки сайта) и включите использование локального Push-сервера (последняя версия). Укажите секретный ключ, который настраивали ранее в файле
/etc/sysconfig/push-server-multi
.
Конфигурация сайта
Сайт
Создайте рабочий каталог:
mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown www-data:www-data /var/www/html/bx-site -R
Аналогичным образом можно скачать нужный дистрибутив и установить его в каталог: /var/www/html/bx-site
.
Создайте базу данных и пользователя:
create database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';
Необходимо заменить PASSWORD на пароль, который будет использоваться для доступа к БД.
Push-server
Для работы портала необходимо настроить push-server. Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.
Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php
, добавив следующую секцию:
return array (
'pull' => Array(
'value' => array(
'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
'nginx_version' => '4',
'nginx_command_per_hit' => '100',
'nginx' => 'Y',
'nginx_headers' => 'N',
'push' => 'Y',
'websocket' => 'Y',
'signature_key' => 'PUTTHEPRIVATEKEYHERE',
'signature_algo' => 'sha1',
'guest' => 'N',
),
),
...
Обратите внимание, что signature_key должен содержать тот же ключ, который указан в /etc/sysconfig/push-server-multi
в соответствующем ключе. Если все хорошо, то после перезапуска httpd:
systemctl restart httpd
Вы увидите запросы к push-server:
Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols
Настройка окружения для РЕД ОС 8
В главе описаны настройки окружения для операционной системы РЕД ОС 8, необходимые для установки 1С-Битрикс24 (коробочная версия) и 1С-Битрикс: Управление сайтом.
Чтобы выполнить все операции из этой главы, вам необходимо знать основы серверного администрирования. Хотя компания 1С-Битрикс тестировала установку на другие окружения, лучше не использовать их как основные платформы для эксплуатации продуктов Bitrix Framework.
Установка и настройка ОС
Скачайте дистрибутив РЕД ОС 8 с официального репозитория и установите его. В процессе установки выберите «сервер с минимальной настройкой», иначе получите десктопную версию.
Все последующие шаги описаны для сервера с минимальной настройкой.
В РЕД ОС применяется система управления программными пакетами DNF. С ее помощью установите обновления до последней версии. Отключите SELinux и перезапустите систему:
su -
dnf update
echo 'SELINUX=disabled' > /etc/sysconfig/selinux
reboot
Установка пакетов
Ниже приведен список всех пакетов, необходимых для установки коробочной версии Битрикс24. Для 1С-Битрикс: Управление сайтом список аналогичен, за исключением Push-сервера.
- Apache — версия 2.4.62
dnf install httpd
- PHP — версия 8.1.30
dnf install php php-cli php-common php-devel \
php-gd php-imap php-ldap \
php-mbstring php-mysqlnd php-opcache \
php-pdo php-pear php-pear-DB php-pecl-apcu \
php-pecl-mcrypt php-pecl-memcache \
php-process php-pspell php-xml php-zipstream
- NGINX — версия 1.26.2
dnf install nginx
- MariaDB-сервер — версия 10.11.6
dnf install mariadb-server mariadb
- Node и NPM (Push-сервер) — версия 20.15.1
dnf install nodejs npm
- Redis — 7.2.6
dnf install redis
Конфигурация Nginx
Настройте конфигурацию Nginx:
- рабочий каталог для сайта — /var/www/html/bx-site,
- пользователь для web-окружения — nginx, группа — apache.
Конфигурация сервера Nginx:
/etc/nginx/nginx.conf # основной конфигурационный файл
|_conf.d/upstreams.conf # конфигурация для upstream серверов: apache && push-server
|_conf.d/maps-composite_settings.conf # переменные, используемые для кеша
|_conf.d/maps.conf # дополнительные переменные
|_conf.d/http-add_header.conf # CORS заголовки
|_sites-available/*.conf # подключаем сайты
|_default.conf # сайт по умолчанию (настраиваем только 80 порт)
|_conf.d/bx_temp.conf # конфигурация BX_TEMPORARY_FILES_DIRECTORY
|_conf.d/bitrix.conf # дефолтная конфигурация сайта
|_rtc.conf # проксирование запросов на push-server (публикация)
Дефолтная конфигурация сайта:
conf.d/bitrix.conf # основный блоки со включенным по умолчанию кешем в файлах
|_conf.d/bitrix_general.conf # отдача статики, быстрая отдача для внешних хранилищ и прочее
|_conf.d/errors.conf # обработка ошибок
|_conf.d/im_subscrider.conf # проксирование запросов на push-server (получение)
|_conf.d/bitrix_block.conf # блокировки по умолчанию
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redos/nginx.
Загрузите папку redos/nginx в корневую папку сервера и выполните команду:
rsync -av redos/nginx/ /etc/nginx/
В сервисе используются имена для проксирования:
httpd
— проксирование запросов на Apache,
push
— проксирование запросов на Push-сервер.
Чтобы заработала конфигурация, пропишите имена в локальных адресах:
echo "127.0.0.1 push httpd" >> /etc/hosts
Если сервисы расположены на другом хосте, укажите правильный IP-адрес.
Запустите Nginx:
systemctl --now enable nginx
Конфигурация PHP
В РЕД ОС 8 централизованное хранилище PHP конфигурации — папка /etc/php.d.
Минимальные настройки, которые необходимо добавить:
- для модуля opcache:
opcache.max_accelerated_files = 100000
opcache.revalidate_freq = 0
- Настройки файла zx-bitrix.ini:
display_errors = Off
error_reporting = E_ALL
error_log = '/var/log/php/error.log'
; Set some more PHP parameters
enable_dl = Off
short_open_tag = On
allow_url_fopen = On
# Security headers
mail.add_x_header = Off
expose_php = Off
...
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для PHP расположены в папке: redos/php.d.
Загрузите папку redos/php.d в корневую папку сервера и выполните команду:
su -
rsync -av redos/php.d/ /etc/php.d/
Конфигурация Apache
По умолчанию Apache настроен на дефолтный сайт в каталоге /var/www/html.
Основные действия для настройки конфигурации Apache:
- изменить каталог для сайта на /var/www/html/bx-site,
- изменить порт, который слушает сервис (так как в качестве внешнего сервиса будет использоваться Nginx),
- импортировать настройки для сайта из виртуальной машины.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Apache расположены в папке: redos/httpd2.
Загрузите папку redos/httpd2 в корневую папку сервера и выполните команду:
su -
rsync -av redos/httpd2/ /etc/httpd/
В результате будет настроено три файла:
- conf.d/default.conf — в описании сайта заменен каталог на var/www/html/bx-site,
- conf/httpd.conf — изменено значение порта
Listen
на порт 8090,
- conf.modules.d/00-mpm.conf — заменен
mpm event
на prefork
.
Запустите Apache:
systemctl --now enable httpd
Конфигурация MariaDB
Для конфигурации MariaDB задайте настройки параметров:
transaction-isolation = READ-COMMITTED
,
innodb_flush_method = O_DIRECT
— рекомендованная, но необязательная настройка,
innodb_flush_log_at_trx_commit = 2
— рекомендованная, но необязательная настройка,
thread_cache_size = 4
.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для MariaDB расположены в папке: redos/my.cnf.d.
Загрузите папку redos/my.cnf.d в корневую папку сервера и выполните команду:
su -
rsync -av redos/my.cnf.d/ /etc/my.cnf.d/
Запустите сервис:
systemctl --now enable mariadb
Настройте сервис через mysql_secure_installation
.
mysql_secure_installation
.....
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n] y
... Success!
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] y
...
Конфигурация Redis
Работа Push-сервера невозможна без сервиса Redis. Для этого в конфигураторе следует:
- включить файловый сокет для работы,
- отключить сброс данных на диск, поскольку для работы Push-сервера это не требуется,
- установить группу пользователя.
Все конфигурационные файлы скачайте в архиве. Файлы для Redis расположены в папке: redos/redis.
Загрузите папку redos/redis в корневую папку сервера и выполните команду:
su -
rsync -av redos/redis/ /etc/redis/
Настройте права доступа:
su -
usermod -g apache redis
chown -R redis:apache /etc/redis /var/log/redis /var/lib/redis
[[ ! -d /etc/systemd/system/redis.service.d ]] && mkdir /etc/systemd/system/redis.service.d
echo -e '[Service]\nGroup=apache' > /etc/systemd/system/redis.service.d/custom.conf
systemctl daemon-reload
Запустите сервис Redis:
systemctl --now enable redis
Конфигурация Push-server
Схема работы
----------------------- ---------------------------------------------------
| nginx: 0.0.0.0:80 | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
----------------------- ---------------------------------------------------
----------------------- ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
----------------------- ---------------------------------------------------
Nginx проксирует запрос на Push-сервис выбранного типа. Запросы получения сообщений sub
— публичные, проксируются со стандартных портов 80/443. Запросы публикации pub
— доступны только с внутреннего адреса сервера.
Nodejs-процессы делятся на два типа:
- Процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Слушают порты 8010-8015.
- Процессы, отвечающие за отправку сообщения в канал. Слушают порты 9010-9011.
Для запуска Push-сервера необходимы:
- nodejs & npm,
- архив сервиса и его модулей.
Выполните следующие действия:
- Скачайте и установите архив
push-server-0.4.0.tgz
:
su -
cd /opt
wget https://repo.bitrix.info/vm/push-server-0.4.0.tgz
npm install --omit=dev ./push-server-0.4.0.tgz
Если репозиторий
repo.bitrix.info недоступен,
скачайте архив
push-server-0.4.0.tgz
и разместите его в директории
/opt
. Далее выполните установку:
su -
cd /opt
npm install --omit=dev ./push-server-0.4.0.tgz
Установка закончится строкой:
added 1 package in 15s
16 packages are looking for funding
run `npm fund` for details
- Для удобства дальнейшей работы выполните команды:
su -
ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server
- Скопируйте файлы сервиса и основную конфигурацию:
su -
cd /opt/node_modules/push-server
cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
cp etc/sysconfig/push-server-multi /etc/sysconfig/push-server-multi
cp etc/push-server/push-server.service /etc/systemd/system/
ln -sf /opt/node_modules/push-server /opt/push-server
- В конфигурационном файле /etc/sysconfig/push-server-multi исправьте (или добавьте, если их нет) следующие параметры:
SECURITY_KEY
— секретный ключ для подписи соединения между клиентом и Push-сервером,
Длина ключа не имеет значения. В ключе можно использовать только буквы латинского алфавита и цифры, спецсимволы запрещены. Рекомендуем использовать длинный ключ — простой и короткий небезопасен. Вы можете сгенерировать его в консоли с помощью команды:
cat /dev/urandom |tr -dc A-Za-z0-9 | head -c 128
RUN_DIR
— директория для хранения PID файлов процесса,
USER/GROUP
— пользователь, под которым будет запущен сервис.
Пример настроек параметров:
USER=bitrix
GROUP=apache
SECURITY_KEY="PUTTHEPRIVATEKEYHERE"
RUN_DIR=/tmp/push-server
REDIS_SOCK=/tmp/redis.sock
- Создайте пользователя:
su -
useradd -g apache bitrix
- Создайте каталог логов:
[[ ! -d /var/log/push-server ]] && mkdir /var/log/push-server
chown bitrix:apache /var/log/push-server
- Каждый nodejs-процесс будет запущен как отдельный процесс. Сгенерируйте конфигурации:
/usr/local/bin/push-server-multi configs pub
/usr/local/bin/push-server-multi configs sub
Сгенерированные конфигурации в формате [dw]json[/dw][di]push-server-sub-80XX.json
push-server-pub-90XX.json[/di] будут размещены в каталоге /etc/push-server/>.
- Создайте каталог через tmpfiles.d:
echo 'd /tmp/push-server 0770 bitrix apache -' > /etc/tmpfiles.d/push-server.conf
systemd-tmpfiles --remove --create
- Измените пользователя и путь к скрипту запуска в конфигурационном файле сервиса /etc/systemd/system/push-server.service:
[Service]
User=bitrix
Group=apache
ExecStart=/usr/local/bin/push-server-multi systemd_start
ExecStop=/usr/local/bin/push-server-multi stop
...
- Переконфигурируйте:
systemctl daemon-reload
- Запустите сервис:
systemctl --now enable push-server
- Выполните настройки Push-сервера, описанные в следующем уроке.
Конфигурация сайта
Сайт
Создайте рабочий каталог и загрузите скрипт BitrixSetup:
mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown apache:apache /var/www/html/bx-site -R
Аналогичным образом можно скачать нужный дистрибутив и установить его в каталог /var/www/html/bx-site.
Получите доступ к оболочке БД. Создайте базу данных и пользователя:
create database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';
Замените PASSWORD
на пароль, который будете использовать для доступа к БД.
Выполните установку продукта.
Push-server
Для работы портала необходимо настроить push-server. Сервис запущен, необходимо сделать настройки.
Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://имя_сайта/bitrix/admin/settings.php?lang=ru&mid=pull
Подробнее...[/di] или с помощью конфигурационного файла. Покажем, как это делается вторым способом.
Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php, добавив следующую секцию:
return array (
'pull' => Array(
'value' => array(
'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
'nginx_version' => '4',
'nginx_command_per_hit' => '100',
'nginx' => 'Y',
'nginx_headers' => 'N',
'push' => 'Y',
'websocket' => 'Y',
'signature_key' => 'PUTTHEPRIVATEKEYHERE',
'signature_algo' => 'sha1',
'guest' => 'N',
),
),
...
Параметр
signature_key
должен содержать тот же ключ, который вы указали в /etc/sysconfig/push-server-multi в соответствующем параметре. Если все хорошо, то после перезапуска httpd:
systemctl restart httpd
Вы увидите запросы к Push-серверу:
Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols
Настройка окружения для РЕД ОС 7.3
В главе описаны настройки окружения для операционной системы РЕД ОС 7.3 для установки на неё продуктов 1С-Битрикс24 (коробочная версия)
и 1С-Битрикс: Управление сайтом
. Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.
Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.
Установка и настройка ОС
Для начала необходимо установить дистрибутив РЕД ОС 7.3. В процессе установки выбирите сервер с минимальной настройкой (в противном случае получите декстоп).
Внимание! Дальнейшая настройка будет показана на базе такой установки.
Для установки можно использовать только официальные репозитории от Ред ОС. Вам понадобятся обновления (в поставке версия php 7.4 , в репозитории доступна 8.1).
В качестве менеджера пакетов используется dnf. Обновляем систему до последней стабильной версии. Отключаем selinux:
su -
dnf update
echo 'SELINUX=disabled' > /etc/sysconfig/selinux
reboot
Установка пакетов
Ниже приведен список всех пакетов, которые понадобятся для коробочной версии «Битрикс24». Для «1С-Битрикс: Управление сайтом» список аналогичен (не нужно устанавливать только push-server).
- Apache — версия 2.4 и PHP — версия 8.1:
dnf install httpd
dnf install php81-release
dnf install php php-cli php-common php-devel \
php-gd php-imap php-json php-ldap \
php-mbstring php-mysqlnd php-opcache \
php-pdo php-pear php-pear-DB php-pecl-apcu \
php-pecl-mcrypt php-pecl-memcache \
php-process php-pspell php-xml php-zipstream
- NGINX — версия 1.25.4:
dnf install nginx
- MariaDB сервер — версия 10.11.6:
dnf install mariadb-server mariadb
- Node и NPM (push-server) — версия 18.20:
dnf install nodejs npm
- Redis — 7.0.15:
dnf install redis
Конфигурация NGINX
Настройте конфигурацию Nginx:
- Рабочий каталог для сайта —
/var/www/html/bx-site
.
- Пользователь для web окружения — nginx, группа apache.
Конфигурация NGINX сервера:
/etc/nginx/nginx.conf # основной конфигурационный файл
|_conf.d/upstreams.conf # конфигурация для upstream серверов: apache && push-server
|_conf.d/maps-composite_settings.conf # параменные используемые для кеша
|_conf.d/maps.conf # дополнительные переменные
|_conf.d/http-add_header.conf # CORS заголовки
|_sites-available/*.conf # подключаем сайты
|_default.conf # сайт по умолчанию (настраиваем только 80 порт)
|_conf.d/bx_temp.conf # конфигурация BX_TEMPORARY_FILES_DIRECTORY
|_conf.d/bitrix.conf # дефолтная конфигурация сайта
|_rtc.conf # проксирование запросов на push-server (публикация)
Дефолтная конфигурация сайта:
conf.d/bitrix.conf # основный блоки со включенным по умолчанию кешем в файлах
|_conf.d/bitrix_general.conf # отдача статики, быстрая отдача для внешних хранилищ и прочее
|_conf.d/errors.conf # обработка ошибок
|_conf.d/im_subscrider.conf # проксирование запросов на push-server (получение)
|_conf.d/bitrix_block.conf # блокировки по умолчанию
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redos/nginx
.
Загрузите папку redos/nginx
в корневую папку сервера и выполните:
rsync -av redos/nginx/ /etc/nginx/
В сервисе используются имена для проксирования на определенные службы:
- httpd — проксирование запросов на apache
- push — проксирование запросов на push-server
Чтобы заработала конфигурация, необходимо прописать их в локальных адресах. Если сервисы расположены на другом хосте, указываем здесь правильный адрес:
echo "127.0.0.1 push httpd" >> /etc/hosts
Запускаем сервис:
systemctl --now enable nginx
Конфигурация PHP
В данной версии установки централизованное хранилище конфигов: /etc/php.d
.
Минимальные настройки, которые необходимо добавить:
- для модуля opcache:
opcache.max_accelerated_files = 100000
opcache.revalidate_freq = 0
- Настройки файла zx-bitrix.ini:
display_errors = Off
error_reporting = E_ALL
error_log = '/var/log/php/error.log'
; Set some more PHP parameters
enable_dl = Off
short_open_tag = On
allow_url_fopen = On
# Security headers
mail.add_x_header = Off
expose_php = Off
...
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для PHP расположены в папке: redos/php.d
. Загрузите папку на сервер и выполните:
su -
rsync -av redos/php.d/ /etc/php.d/
Конфигурация Apache
По умолчанию apache настроен на дефолтный сайт в каталоге /var/www/html
.
Основные действия для настройки конфигурации Apache:
- изменить каталог для сайта на
/var/www/html/bx-site
,
- изменить порт, который слушает сервис (так как в качестве внешнего сервиса будет использоваться nginx),
- импортировать настройки для сайта из виртуальной машины.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Apache расположены в папке: redos/httpd2
. Загрузите папку на сервер и выполните:
su -
rsync -av redos/httpd2/ /etc/httpd/
Мы настраиваем три файла:
conf.d/default.conf
— в описании сайта замените каталог на var/www/html/bx-site
;
conf/httpd.conf
— смена значения Listen на порт 8090
conf.modules.d/00-mpm.conf
— смена mpm event на prefork.
Запустите сервис:
systemctl --now enable httpd
Конфигурация Mariadb
Для конфигурации MariaDB выполните следующие настройки:
- transaction-isolation измените на
READ-COMMITTED
;
- innodb_flush_method установите равным
O_DIRECT
(рекомендованная, но не обязательная настройка);
- innodb_flush_log_at_trx_commit установить равным 2 (рекомендованная, но не обязательная настройка).
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для MariaDB расположены в папке: redos/my.cnf.d
.
Разместите их в директории /etc/my.cnf.d/
:
su -
rsync -av redos/my.cnf.d/ /etc/my.cnf.d/
Запустите сервис:
systemctl --now enable mariadb
Настройка сервиса выполняется через mysql_secure_installation.
Конфигурация Redis
Данный сервис необходим для организации работы Push-сервера.
Основные настройки, которые необходимо выполнить в конфигураторе:
- включить файловый сокет для работы;
- отключить сброс данных на диск (для работы Push-сервера эта возможность не нужна);
- установить группу пользователя.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Redis расположены в папке: redos/redis
.
Разместите их в директории /etc/redis/
:
su -
rsync -av redos/redis/ /etc/redis/
Выполните команды:
su -
usermod -g apache redis
chown root:apache /etc/redis/ /var/log/redis/
[[ ! -d /etc/systemd/system/redis.service.d ]] && mkdir /etc/systemd/system/redis.service.d
echo -e '[Service]\nGroup=apache' > /etc/systemd/system/redis.service.d/custom.conf
systemctl daemon-reload
Запустите сервис:
systemctl --now enable redis
Конфигурация Push-server
Схема работы
----------------------- ---------------------------------------------------
| nginx: 0.0.0.0:80 | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
----------------------- ---------------------------------------------------
----------------------- ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
----------------------- ---------------------------------------------------
Nginx проксирует запрос на push-сервис выбранного типа. Запросы получения сообщений (например, sub) — публичные, проксируются со стандартных портов 80/443. Запросы публикации (pub) — доступны только с внутреннего адреса сервера.
Nodejs-процессы делятся на два типа:
- Процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Слушают порты 8010-8015.
- Процессы, отвечающие за отправку сообщения в канал. Слушают порты 9010-9011.
Для запуска Push-сервера необходимы:
- nodejs & npm;
- архив сервиса и его модулей.
Выполните следующие действия:
- Скачайте и установите архив push-server-0.3.0.tgz:
su -
cd /opt
wget https://repo.bitrix.info/vm/push-server-0.3.0.tgz
npm install --omit=dev ./push-server-0.3.0.tgz
Установка закончится строкой:
added 1 package in 2m
16 packages are looking for funding
run `npm fund` for details
- Для удобства дальнейшей работы выполните команды:
su -
ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server
- Скопируйте файлы сервиса и основную конфигурацию:
su -
cd /opt/node_modules/push-server
cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
cp etc/sysconfig/push-server-multi /etc/sysconfig/push-server-multi
cp etc/push-server/push-server.service /etc/systemd/system/
ln -sf /opt/node_modules/push-server /opt/push-server
- В конфигурационном файле
/etc/sysconfig/push-server-multi
исправьте (или добавьте, если их нет) следующие параметры:
- SECURITY_KEY — секретный ключ для подписи соединения между клиентом и пуш-сервером;
Примечание. Длина ключа не имеет значения. В ключе можно использовать только буквы латинского алфавита и цифры (спецсимволы запрещены). Но имейте в виду, что простой короткий ключ небезопасен. Можно генерировать его, например, таким образом:
cat /dev/urandom |tr -dc A-Za-z0-9 | head -c 128
- RUN_DIR — директория для хранения PID файлов процесса;
- USER/GROUP — пользователь, под которым будет запущен сервис.
Пример настроек параметров:
USER=bitrix
GROUP=apache
SECURITY_KEY="PUTTHEPRIVATEKEYHERE"
RUN_DIR=/tmp/push-server
- Создайте пользователя:
su -
useradd -g apache bitrix
- Каждый nodejs-процесс будет запущен как отдельный процесс. Сгенерируйте конфигурации:
/usr/local/bin/push-server-multi configs pub
/usr/local/bin/push-server-multi configs sub
Сгенерированные конфигурации в формате [dw]json[/dw][di]push-server-sub-80XX.json
push-server-pub-90XX.json[/di] будут размещены в каталоге: /etc/push-server/
.
- Создайте каталог через tmpfiles.d:
echo 'd /tmp/push-server 0770 bitrix apache -' > /etc/tmpfiles.d/push-server.conf
systemd-tmpfiles --remove --create
Создайте каталог логов:
[[ ! -d /var/log/push-server ]] && mkdir /var/log/push-server
chown bitrix:apache /var/log/push-server
- Измените пользователя и путь к скрипту запуска в конфигурационном файле сервиса
/etc/systemd/system/push-server.service
:
[Service]
User=bitrix
Group=apache
ExecStart=/usr/local/bin/push-server-multi systemd_start
ExecStop=/usr/local/bin/push-server-multi stop
...
- Переконфигурируйте:
systemctl daemon-reload
- Запустите сервис:
systemctl --now enable push-server
- Перейдите в конфигурацию Push-модуля (настройки сайта) и включите использование локального Push-сервера (последняя версия). Укажите секретный ключ, который настраивали ранее в файле
/etc/sysconfig/push-server-multi
.
Конфигурация сайта
Сайт
Создайте рабочий каталог:
mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown apache:apache /var/www/html/bx-site -R
Аналогичным образом можно скачать нужный дистрибутив и установить его в каталог: /var/www/html/bx-site
.
Получите доступ к оболочке БД. Создайте базу данных и пользователя:
create database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';
Необходимо заменить 'PASSWORD'
, на пароль который будете использовать для доступа к БД.
Push-server
Для работы портала необходимо настроить push-server. Сервис запущен, необходимо сделать настройки.
Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.
Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php
, добавив следующую секцию:
return array (
'pull' => Array(
'value' => array(
'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
'nginx_version' => '4',
'nginx_command_per_hit' => '100',
'nginx' => 'Y',
'nginx_headers' => 'N',
'push' => 'Y',
'websocket' => 'Y',
'signature_key' => 'PUTTHEPRIVATEKEYHERE',
'signature_algo' => 'sha1',
'guest' => 'N',
),
),
...
Обратите внимание, что параметр signature_key должен содержать тот же ключ, который вы указали в
/etc/sysconfig/push-server-multi
в соответствующем ключе. Если все хорошо, то после перезапуска httpd:
systemctl restart httpd
Вы увидите запросы к push-server:
Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols
Настройка окружения для ALT 8 SP Server
В главе описаны настройки окружения для операционной системы ALT 8 SP Server для установки на неё продуктов 1С-Битрикс24 коробочная версия
и 1С-Битрикс: Управление сайтом
. Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.
Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.
Установка и настройка ОС
Установка
Начнем с установки продукта Alt 8 SP Server. В процессе установки доступен выбор набора пакетов. Выберите набор пакетов для организации web-сервера. Остальные (например, такие как сервер печати, samba сервер и т.п.) отключите.
Внимание: Дальнейшая настройка будет показана именно на базе такой установки.
Дополнительно подключите репозитории, т.к. на установочном диске есть не все нужные нам пакеты.
Примечание: Для установки можно использовать только официальные репозитории от ALT8.
В качестве менеджера пакетов используем apt-get.
- Обновите систему до последней стабильной версии:
su -
apt-repo rm all
vim /etc/apt/sources.list.d/altsp-C.list # <-- в этом файле раскомментируйте нужное зеркало, которое зависит от типа установки
apt-get update
apt-get dist-upgrade
update-kernel -t un-def
reboot
- После перезагрузки удалите неиспользуемые ядра:
su -
remove-old-kernels -t un-def
По умолчанию SELinux не устанавливается для данного типа установки, поэтому каких-либо дополнительных настроек для его отключения не требуется.
Настройка портов
Обязательно нужно открыть порты:
- 22 – ssh доступ;
- 80 / 443 – http / https web-сервер;
Остальные порты для:
- ntlm
- сервера мгновенных сообщений;
- xmpp-сервера
нужно открывать, если только они используются. Можно выбрать произвольные порты, а можно те же, что используются в CentOS:
- 8890 / 8891 – http/https ntlm;
- 8893 / 8894 – http/https сервер мгновенных сообщений;
- 5222 / 5223 – http/https.
Установка пакетов
Ниже приведен весь список пакетов, который нам понадобится для 1С-Битрикс24 коробочная версия
. Для 1С-Битрикс: Управление сайтом
из этого набора не нужен только push-server.
Установка по шагам:
- Apache 2.4 и php 7.2 уже будут установлены на сервере, если Вы выбрали web-сервер на этапе установки дистрибутива.
Если Вы выбрали минимальную установку (а не web-сервер), то просто поставьте все пакеты из списка ниже:
su -
apt-get install apache2-mods apache2-htcacheclean \
apache2-cgi-bin-test-cgi apache2-htpasswd \
apache2-httpd-prefork apache2-mod_php7 \
apache2-mod_cache_disk apache2 \
apache2-datadirs apache2-cgi-bin-printenv \
apache2-htcacheclean-control apache2-html \
apache2-ab apache2-base apache2-httpd-worker apache2-cgi-bin apache2-icons
apt-get install php7-mcrypt php7-imap \
php7 php7-xsl php7-gd php7-memcache \
php7-exif php7-zip php7-mbstring \
php7-fileinfo apache2-mod_php7 \
php7-libs php7-dom php7-xmlrpc php7-dba php7-curl \
php7-mysqli php7-openssl php7-opcache
С 01.02.2023 ограничивается поддержка наших продуктов на PHP версии ниже 8.0. Рекомендуемая версия PHP – 8.1 и выше. Поэтому после установки необходимо обновить PHP до версии не ниже 8.0.
- Установите Nginx (версия 1.20.1):
su -
apt-get install nginx
- Установите MariaDB сервер (версия 10.4.20):
su -
apt-get install mariadb-server mariadb-client
- Установите Node и npm (push-server) (версия 14.3.0):
su -
apt-get install node npm
- Установите Redis (версия 5.0.4):
su -
apt-get install redis
Конфигурация Nginx
Выполним конфигурацию Nginx.
- Рабочий каталог для сайта -
/var/www/html/bx-site
.
- Пользователь для web окружения - _nginx/_webserver.
Конфигурация nginx сервера:
/etc/nginx/nginx.conf # основной конфигурационный файл
|_conf.d/upstreams.conf # конфигурация для upstream серверов: apache && push-server
|_conf.d/maps-composite_settings.conf # переменные используемые для кеша
|_conf.d/maps.conf # дополнительные переменные
|_conf.d/http-add_header.conf # CORS заголовки
|_sites-available/*.conf # подключаем сайты
|_default.conf # сайт по умолчанию (настраиваем только 80 порт)
|_conf.d/bx_temp.conf # конфигурация BX_TEMPORARY_FILES_DIRECTORY
|_conf.d/bitrix.conf # дефолтная конфигурация сайта
|_rtc.conf # проксирование запросов на push-server (публикация)
Дефолтная конфигурация сайта:
conf.d/bitrix.conf # основный блоки со включенным по умолчанию кешем в файлах
|_conf.d/bitrix_general.conf # отдача статики, быстрая отдача для внешних хранилищ и прочее
|_conf.d/errors.conf # обработка ошибок
|_conf.d/im_subscrider.conf # проксирование запросов на push-server (получение)
|_conf.d/bitrix_block.conf # блокировки по умолчанию
Конфигурация взята из виртуальной машины и может показаться избыточной, но фактически поддерживает все те же возможности, что и виртуальная машина.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: alt8/nginx
.
Разместите их в директории /etc/nginx/
.
Для удобства, в конфигурационных файлах используются имена серверов httpd - apache2, сервис push push-server. По умолчанию они будут ставиться на локальную машину, поэтому прописываем следующие записи в /etc/hosts
:
127.0.0.1 httpd push
Если Вы планируете развернуть данные сервисы на отдельных хостах, то нужно прописать правильный IP в /etc/hosts
или сконфигурировать DNS сервер.
Запустите сервис:
systemctl --now enable nginx
Конфигурация PHP
В данной версии установки два местоположения для конфигов:
/etc/php/7.2/cli/php.d/
настройка CLI;
/etc/php/7.2/apache2-mod_php/php.d/
настройки модуля Apache.
Минимально необходимо добавить настройки для модуля Apache:
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для PHP находятся в папке: alt8/php.d
.
Разместите их в директории /etc/php/7.2/apache2-mod_php/php.d/
.
Можно проверить, что php нашел все модули без проблем и нет ошибок в конфигурации:
php -m
Создайте каталоги для сессий и загрузки файлов:
mkdir /tmp/php_upload /tmp/php_sessions
chown apache2:_webserver /tmp/php_upload /tmp/php_sessions -R
Каталоги в /tmp
находятся под управлением tmpfiles, делаем настройку для них:
vim /etc/tmpfiles.d/bitrix.conf
----
d /tmp/php_sessions 0770 apache2 _webserver -
d /tmp/php_upload 0770 apache2 _webserver -
----
Конфигурация Apache
По умолчанию Apache настроен на дефолтный сайт в каталоге /var/www/html
.
Основное, что требуется сделать для настройки конфигурации Apache:
- изменить каталог для сайта на
var/www/html/bx-site
;
- изменить порт, который слушает сервис (так как в качестве внешнего сервиса используем nginx);
- импортировать настройки для сайта из виртуальной машины.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Apache находятся в папке: alt8/httpd2
.
Разместите их в директории /etc/httpd2/
.
Настроить требуется три файла:
conf/ports-available/http.conf
- указать новый порт: 8090;
conf/sites-available/default.conf
- заменить каталог в описании сайта на var/www/html/bx-site
;
conf/httpd2.conf
- изменить группу пользователя на _webserver.
Отключите приватный Tmp каталог для сервиса httpd:
mkdir /etc/systemd/system/httpd2.service.d
echo -e "[Service]\nPrivateTmp=false\n" > /etc/systemd/system/httpd2.service.d/custom.conf
systemctl daemon-reload
После этого запустите сервис:
systemctl --now enable httpd2
Конфигурация MariaDB
Для конфигурации MariaDB требуется выполнить такие настройки:
- transaction-isolation изменить на
READ-COMMITTED
;
- innodb_flush_method установить равным
O_DIRECT
(желательная, но не обязательная настройка);
- innodb_flush_log_at_trx_commit установить равным 2 (желательная, но не обязательная настройка).
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для MariaDB находятся в папке: alt8/my.cnf.d
.
Разместите их в директории /etc/my.cnf.d/
.
Запустите сервис:
systemctl --now enable mariadb
Настройте пароль для доступа к серверу и прочие опции безопасности через скрипт:
mysql_secure_installation
.....
Set root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n] y
... Success!
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] y
...
Конфигурация Redis
Данный сервис нам нужен для организации Push-сервера.
Основное, что нам важно установить в конфигурации:
- включить файловый сокет для работы;
- отключить сброс данных на диск (для работы Push-сервера нам не нужна эта возможность);
- установить группу пользователя.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Redis находятся в папке: alt8/redis
.
Разместите их в директории /etc/redis/
и выполните:
su -
usermod -g apache2 \_redis
chown root:apache2 /etc/redis/ /var/log/redis/
mkdir /etc/systemd/system/redis.service.d
echo -e '[Service]\nGroup=apache2' > /etc/systemd/system/redis.service.d/custom.conf
systemctl daemon-reload
Запустите сервис:
systemctl --now enable redis
Конфигурация Push-server
Схема работы:
----------------------- ---------------------------------------------------
| nginx: 0.0.0.0:80 | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
----------------------- ---------------------------------------------------
----------------------- ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
----------------------- ---------------------------------------------------
Nginx проксирует запрос на push-сервис выбранного типа. Публикация сообщений ограничена для локальной ноды.
Nodejs-процессы делятся на два типа:
- Процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Слушают порты 8010-8015;
- Процессы, отвечающие за отправку сообщения в канал. Слушают порты 9010-9011.
Для запуска Push-сервера нам понадобятся:
- nodejs & npm ;
- архив сервиса и его модулей.
Выполните действия:
- Скачайте архив с репозитория repo.bitrix.info
wget https://repo.bitrix.info/vm/push-server-0.3.0.tgz
и разместите его в директории /opt
. Выполните установку:
su -
cd /opt
npm install --production ./push-server-0.3.0.tgz
Установка закончится строкой:
+ push-server@0.3.0
added 144 packages from 151 contributors and audited 144 packages in 10.388s
- Выполните (исключительно для удобства):
su -
ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server
- Скопируйте файлы сервиса и основную конфигурацию:
su -
cd /opt/node_modules/push-server
cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
cp etc/sysconfig/push-server-multi /etc/sysconfig/push-server-multi
cp etc/push-server/push-server.service /etc/systemd/system/
ln -sf /opt/node_modules/push-server /opt/push-server
- Отредактируйте конфигурационный файл
/etc/sysconfig/push-server-multi
. В нём нужно исправить/добавить параметры:
- USER/GROUP - пользователь, под которым будет запущен сервис;
- SECURITY_KEY - cекретный ключ для подписи соединения между клиентами и пуш-сервером;
- RUN_DIR - директория для хранения PID файлов процесса.
Пример настроек параметров:
USER=apache2
GROUP=_webserver
SECURITY_KEY="SECURITYKEY123456"
RUN_DIR=/tmp/push-server
- Каждый nodejs процесс будет запущен как отдельный процесс. Сгенерируйте конфигурации:
/usr/local/bin/push-server-multi configs pub
/usr/local/bin/push-server-multi configs sub
Сгенерированные конфигурации в формате [dw]json[/dw][di]push-server-sub-80XX.json
push-server-pub-90XX.json[/di] будут размещены в каталоге: /etc/push-server/
.
- Создайте каталог через tmpfiles.d:
echo 'd /tmp/push-server 0770 apache2 _webserver -' > /etc/tmpfiles.d/push-server.conf
systemd-tmpfiles --remove --create
- Создайте каталог логов:
mkdir /var/log/push-server
chown apache2:_webserver /var/log/push-server
- Измените пользователя в конфигурационном файле сервиса:
/etc/systemd/system/push-server.service
[Service]
User=apache2
Group=_webserver
ExecStart=/usr/local/bin/push-server-multi systemd_start
ExecStop=/usr/local/bin/push-server-multi stop
....
- Переконфигурируйте:
systemctl daemon-reload
- Запустите сервис:
systemctl --now enable push-server
- Перейдите в конфигурацию push модуля (настройки сайта) и включите использование локального push-сервера (последняя версия).
Дополнительно нужно будет указать секретный ключ SECURITY_KEY, который мы настраивали выше в файле
/etc/sysconfig/push-server-multi
.
Конфигурация сайта
Сайт
- Создайте рабочий каталог:
mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown apache2:_webserver /var/www/html/bx-site -R
Аналогичным образом можно скачать нужный дистрибутив и установить его в каталог: /var/www/html/bx-site
.
- Создайте базу данных и пользователя:
reate database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';
Необходимо заменить PASSWORD на пароль, который будете использовать для доступа к БД.
Push-server
Для работы портала необходимо настроить push-server. Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.
Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php
, добавив следующую секцию:
return array (
'pull' => Array(
'value' => array(
'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
'nginx_version' => '4',
'nginx_command_per_hit' => '100',
'nginx' => 'Y',
'nginx_headers' => 'N',
'push' => 'Y',
'websocket' => 'Y',
'signature_key' => 'SECURITYKEY123456',
'signature_algo' => 'sha1',
'guest' => 'N',
),
),
...
Обратите внимание: signature_key должен содержать тот же ключ, который был указан в /etc/sysconfig/push-server-multi в соответствующем ключе. Если все хорошо, то после перезапуска httpd:
systemctl restart httpd2
Вы увидите запросы к push-server:
Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols
Архив
Настройка окружения для Astra 1.7
В главе описаны настройки окружения для операционной системы Astra 1.7 для установки на неё продуктов "1С-Битрикс24 (коробочная версия)" и "1С-Битрикс: Управление сайтом". Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.
Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.
Установка и настройка ОС
Установка
Установку можно выполнять с диска с минимальным набором ПО, остальное будет установлено по сети во время настройки.
В процессе установки выбираем сервер с минимальной настройкой, в противном случае получим декстоп. Дальнейшая настройка будет показана на базе такой установки.
В качестве менеджера пакетов используется apt/apt-get
. Обновляем систему до последней стабильной версии.
Настройка портов
Обязательно нужно открыть порты:
- 22 – ssh доступ;
- 80 / 443 – http / https web-сервер;
Остальные порты для:
- ntlm
- сервера мгновенных сообщений;
- xmpp-сервера
нужно открывать, если только они используются. Можно выбрать произвольные порты, а можно те же, что используются в CentOS:
- 8890 / 8891 – http/https ntlm;
- 8893 / 8894 – http/https сервер мгновенных сообщений;
- 5222 / 5223 – http/https.
Установка пакетов
Весь список пакетов, который нам понадобится для работы "Битрикс24" (для "1С-Битрикс: Управление сайтом" push сервер не нужен.):
- mariadb
- PHP
- Apache
- nginx
- push-server
- redis
mariadb
Подключите репозитории в файле /etc/apt/sources.list
, добавив запись вида:
# Основной репозиторий
deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-main/
1.7_x86-64 main contrib non-free
# Оперативные обновления основного репозитория
deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-update/
1.7_x86-64 main contrib non-free
# Базовый репозиторий
deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-base/
1.7_x86-64 main contrib non-free
# Расширенный репозиторий
deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-extended/
1.7_x86-64 main contrib non-free
# Расширенный репозиторий (компонент astra-ce)
deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-extended/
1.7_x86-64 astra-ce
Обновитесь:
apt update && apt upgrade
Установите необходимые пакеты:
apt install mariadb-server mariadb-client
PHP и Apache
Для начала уставите apache2:
apt install apache2 apache2-dev
Рекомендуется использовать PHP 8.0. В дефолтном репозитории его нет и необходимо собрать его самостоятельно.
apt install -y lsb-release ca-certificates apt-transport-https software-properties-common gnupg2 \
autoconf build-essential curl libtool libssl-dev libcurl4-openssl-dev libxml2-dev libreadline7 \
libreadline-dev libzip-dev libzip4 \
openssl pkg-config zlib1g-dev libsqlite3-dev sqlite3 libonig-dev \
libpq-dev git autoconf bison re2c libpng-dev libldap2-dev \
libfreetype6-dev libfreetype6 libjpeg-dev libxslt1-dev
Скачайте исходники:
cd /usr/local/src
wget https://www.php.net/distributions/php-8.0.23.tar.gz
cd php-8.0.23
./configure \
--prefix=/usr \
--with-config-file-path=/etc/php/8.0 \
--sysconfdir=/etc/php/8.0 \
--enable-mysqlnd \
--with-pdo-mysql \
--with-pdo-mysql=mysqlnd \
--enable-bcmath \
--enable-cli \
--with-apxs2=/usr/bin/apxs2 \
--with-fpm-user=www-data \
--with-fpm-group=www-data \
--enable-mbstring \
--enable-phpdbg \
--enable-shmop \
--enable-sockets \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--with-zlib \
--with-curl \
--with-pear \
--with-openssl \
--enable-pcntl \
--enable-gd \
--with-jpeg \
--with-mysqli \
--with-readline \
--with-freetype \
--enable-session \
--with-xsl \
--with-openssl \
--enable-opcache
make
make test
make install
cp php.ini-development /etc/php/8.0/php.ini
nginx
Установите nginx (1.18 версия)
apt install nginx -y
push-server
Установите node и npm (push-server) - 12.22
apt install nodejs npm -y
redis
Установите redis - 6.0
apt install redis -y
Конфигурация Nginx
Рабочий каталог для сайта - /var/www/html/bx-site
. Пользователь для web окружения - nginx, группа apache.
Конфигурация nginx сервера:
/etc/nginx/nginx.conf # основной конфигурационный файл
|_conf.d/upstreams.conf # конфигурация для upstream серверов: apache && push-server
|_conf.d/maps-composite_settings.conf # параменные используемые для кеша
|_conf.d/maps.conf # дополнительные переменные
|_conf.d/http-add_header.conf # CORS заголовки
|_sites-available/*.conf # подключаем сайты
|_default.conf # сайт по умолчанию (настраиваем только 80 порт)
|_conf.d/bx_temp.conf # конфигурация BX_TEMPORARY_FILES_DIRECTORY
|_conf.d/bitrix.conf # дефолтная конфигурация сайта
|_rtc.conf # проксирование запросов на push-server (публикация)
Дефолтная конфигурация сайта:
conf.d/bitrix.conf # основный блоки со включенным по умолчанию кешем в файлах
|_conf.d/bitrix_general.conf # отдача статики, быстрая отдача для внешних хранилищ и прочее
|_conf.d/errors.conf # обработка ошибок
|_conf.d/im_subscrider.conf # проксирование запросов на push-server (получение)
|_conf.d/bitrix_block.conf # блокировки по умолчанию
Конфигурация взята из виртуальной машины и может показаться избыточной, но фактически поддерживает все возможности, что и виртуальная машина.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx размещены в папке astra/nginx
rsync -av astra/nginx/ /etc/nginx/
В сервисе используются имена для проксирования на определенные службы:
- httpd - проксирование запросов на apache,
- push - проксирование запросов на push-server. Чтобы заработала конфигурация, необходимо прописать их в локальных адресах. Если сервисы расположены на другом хосте, указываем здесь правильный адрес.
echo "127.0.0.1 push httpd" >> /etc/hosts
По умолчанию в Astra Apache2 сервер использует 80 порт и поставлен в автозапуск. Поэтому перед запуском nginx сервера, мы на время выключаем apache2 (мы его еще не настраивали). Останавливаем apache2:
systemctl stop apache2
Запустите Nginx
systemctl --now enable nginx
Конфигурация PHP
В данной версии установки централизованное хранилище конфигов (для версии php 8.0):
/etc/php/8.0
| |-> php.ini
Как минимум, нам нужно добавить настройки для следующих опций:
- для модуля opcache
opcache.max_accelerated_files = 100000
opcache.revalidate_freq = 0
- добавляем настройки bitrexenv.ini
display_errors = Off
error_reporting = E_ALL
error_log = '/var/log/php/error.log'
; Set some more PHP parameters
enable_dl = Off
short_open_tag = On
allow_url_fopen = On
# Security headers
mail.add_x_header = Off
expose_php = Off
...
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для PHP размещены в папке astra/php.d
su -
cd bx-os/astra
# добавляем конфиг для opcache
cat ./php.d/opcache.ini >> /etc/php/8.0/php.ini
# остальные настройки
cat ./php.d/zbx-bitrix.ini >> /etc/php/8.0/php.ini
# создаем каталог для логов
mkdir /var/log/php
chown www-data:www-data /var/log/php
Конфигурация Apache
По умолчанию конфигурация Apache устроена следующим образом:
# /etc/apache2/
# |-- apache2.conf
# | `-- ports.conf
# |-- mods-enabled
# | |-- *.load
# | `-- *.conf
# |-- conf-enabled
# | `-- *.conf
# `-- sites-enabled
# |-- 000-default.conf
# `-- *.conf
Основное, что нужно изменить:
- каталог для сайта
/var/www/html/bx-site
,
- порт, который слушает сервис (так как в качестве внешнего сервиса используем nginx),
- для сайта импортируем настройки из виртуальной машины 000-default.conf. Замечание: В дефолтной конфигурации
sites-enabled/000-default.conf
- это ссылка на файл в каталоге /sites-available
.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Apache размещены в папке astra/apache2
rsync -av astra/apache2/ /etc/apache2/
Настройте следующие файлы:
- ports.conf - смена Listen на 8090
sites-available/000-default.conf
- настройки сайта
mods-available/php.conf
- конфгурация php модуля
apache2/apache2.conf
- выключаем AstraMode
Отключите листинг каталогов в Apache:
a2dismod --force autoindex
Включите модуль rewrite:
a2enmod rewrite
Включите php модуль:
a2enmod php
Запустите сервис:
systemctl --now enable apache2
Конфигурация MariaDB
Необходимые настройки:
- transaction-isolation измените в READ-COMMITTED.
- innodb_flush_method желательно должно быть равным O_DIRECT
- innodb_flush_log_at_trx_commit желательно должно быть равным 2.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для MariaDB размещены в папке astra/my.cnf.d
su -
rsync -av astra/mysql/ /etc/mysql/
Измените следующие файлы:
- my.cnf - добавьте загрузку настроек из каталога
/etc/mysql/my-bx.d/
;
my-bx.d/zbx-custom.cnf
- пропишите настройки, указанные выше.
Запустите сервис:
systemctl --now enable mariadb
systemctl restart mariadb
Настройте сервис через mysql_secure_installation.
mysql_secure_installation
...
Switch to unix_socket authentication [Y/n] n
... skipping.
Change the root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
Remove anonymous users? [Y/n] y
... Success!
Disallow root login remotely? [Y/n] y
... Success!
Конфигурация Redis
Данный сервис необходим для организации работы push-server.
Основное, что важно в конфиге:
- включение файлового сокета для работы;
- отключение сброса данных на диск (для работы push-server нам не нужна эта возможность);
- группа пользователя.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Redis размещены в папке astra/redis
su -
rsync -av astra/redis/redis.conf /etc/redis/redis.conf
usermod -g www-data redis
chown root:www-data /etc/redis/ /var/log/redis/
[[ ! -d /etc/systemd/system/redis-server.service.d ]] && mkdir /etc/systemd/system/redis-server.service.d
echo -e '[Service]\nGroup=www-data' > /etc/systemd/system/redis-server.service.d/custom.conf
systemctl daemon-reload
Запустите сервис:
systemctl enable redis-server.service
systemctl restart redis-server.service
Конфигурация push-server
Схема работы:
----------------------- ---------------------------------------------------
| nginx: 0.0.0.0:80 | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
----------------------- ---------------------------------------------------
----------------------- ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
----------------------- ---------------------------------------------------
Nginx проксирует запрос на push-сервис выбранного типа. Запросы получения сообщений (например, sub) - публичные и проксируются со стандартных портов 80/443, запросы публикации (pub) доступны только с внутреннего адреса сервера.
Процессы Nodejs делятся на два типа:
- Отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Они слушают порты 8010-8015
- Отвечающие за отправку сообщения в канал. Они слушают порты 9010-9011.
Для запуска push-server понадобится:
- nodejs и npm,
- архив сервиса и его модулей.
Скачайте архив:
su -
cd /opt
wget https://repo.bitrix.info/vm/push-server-0.3.0.tgz
npm install --production ./push-server-0.3.0.tgz
Установка закончится строкой:
added 1 package, and audited 145 packages in 13s
16 packages are looking for funding
run `npm fund` for details
Для удобства можно использовать:
ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server
Скопируйте файлы сервиса и основной конфиг:
su -
cd /opt/node_modules/push-server
cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
mkdir /etc/sysconfig
cp etc/sysconfig/push-server-multi /etc/sysconfig/push-server-multi
cp etc/push-server/push-server.service /etc/systemd/system/
ln -sf /opt/node_modules/push-server /opt/push-server
Редактируйте конфигурационный файл /etc/sysconfig/push-server-multi
. Нужно исправить/добавить параметры:
- SECURITY_KEY - cекретный ключ для подписи соединения между клиентом и пуш-сервером,
- RUN_DIR - используется для хранения pid файлов процесса,
- USER/GROUP - пользователь, под которым будет запущен сервис,
- REDIS_SOCK - сокет, который использует Redis сервис.
Пример
GROUP=www-data
SECURITY_KEY="PUTTHEPRIVATEKEYHERE"
RUN_DIR=/tmp/push-server
REDIS_SOCK=/var/run/redis/redis.sock
Создайте пользователя:
useradd -g www-data bitrix
Каждый nodejs процесс будет запущен как отдельный процесс. Сгенерируйте конфиги:
/usr/local/bin/push-server-multi configs pub
/usr/local/bin/push-server-multi configs sub
Создайте каталог через tmpfiles.d.
echo 'd /tmp/push-server 0770 bitrix www-data -' > /etc/tmpfiles.d/push-server.conf
systemd-tmpfiles --remove --create
Создайте каталог логов:
[[ ! -d /var/log/push-server ]] && mkdir /var/log/push-server
chown bitrix:www-data /var/log/push-server
Измените пользователя в конфигурационном файле сервиса /etc/systemd/system/push-server.service
:
[Service]
User=bitrix
Group=www-data
ExecStart=/usr/local/bin/push-server-multi systemd_start
ExecStop=/usr/local/bin/push-server-multi stop
...
Переконфигурируйте
systemctl daemon-reload
и затем запустите сервис:
systemctl --now enable push-server
В [dw]настройках push модуля[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Подробнее...[/di] в административном разделе сайта включите использование [dw]локального пуш сервера (последняя версия)[/dw][di]
.[/di]. Дополнительно нужно будет указать секретный ключ, который вы настраивали в файле /etc/sysconfig/push-server
.
Конфигурация сайта
Сайт
- Создайте рабочий каталог:
mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown www-data:www-data /var/www/html/bx-site -R
Аналогичным образом можно скачать нужный дистрибутив и установить его в каталог: /var/www/html/bx-site
.
- Создайте базу данных и пользователя:
create database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.\* to 'bitrix'@'localhost';
Необходимо заменить PASSWORD на пароль, который будете использовать для доступа к БД.
- Перейдите в http и откройте страницу: http://IP_ADDRESS/bitrixsetup.php. В качестве сервера БД используйте следующие настройки:
'host' => '127.0.0.1',
'database' => 'portal',
'login' => 'bitrix',
'password' => 'PASSWORD'
Пароль измените на тот, который вводили на этапе создания аккаунта.
Push-server
Для работы портала необходимо настроить push-server. Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.
Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php
, добавив следующую секцию:
return array (
'pull' => Array(
'value' => array(
'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
'nginx_version' => '4',
'nginx_command_per_hit' => '100',
'nginx' => 'Y',
'nginx_headers' => 'N',
'push' => 'Y',
'websocket' => 'Y',
'signature_key' => 'PUTTHEPRIVATEKEYHERE',
'signature_algo' => 'sha1',
'guest' => 'N',
),
),
...
Обратите внимание: signature_key должен содержать тот же ключ, который был указан в /etc/sysconfig/push-server-multi в соответствующем ключе. Если все хорошо, то после перезапуска httpd:
systemctl restart httpd2
Вы увидите запросы к push-server:
Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols
Настройка окружения для РЕД ОС 7.2
В главе описаны настройки окружения для операционной системы РЕД ОС 7.2 для установки на неё продуктов 1С-Битрикс24 (коробочная версия)
и 1С-Битрикс: Управление сайтом
. Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.
Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.
Установка и настройка ОС
Установка
Для начала необходимо установить дистрибутив РЕД ОС 7.2. В процессе установки выберите сервер с минимальными настройками (в противном случае в результате получите десктоп).
Важно! Дальнейшая настройка будет показана на базе именно такой установки.
Для установки можно использовать только официальные репозитории РЕД ОС. Вам понадобится версия 7.2 (в поставке версия php 7.1, а в репозитории доступна 7.2).
В качестве менеджера пакетов используется yum. Обновите систему до последней стабильной версии и отключите selinux:
su -
yum update -y
echo 'SELINUX=disabled' > /etc/sysconfig/selinux
reboot
Настройка портов
Обязательно нужно открыть порты:
- 22 – ssh доступ;
- 80 / 443 – http / https web-сервер;
Остальные порты для:
- ntlm
- сервера мгновенных сообщений;
- xmpp-сервера
нужно открывать, если только они используются. Можно выбрать произвольные порты, а можно те же, что используются в CentOS:
- 8890 / 8891 – http/https ntlm;
- 8893 / 8894 – http/https сервер мгновенных сообщений;
- 5222 / 5223 – http/https.
Установка пакетов
Ниже приведен список всех пакетов, которые понадобятся для 1С-Битрикс24 (коробочная версия)
. Для 1С-Битрикс: Управление сайтом
список аналогичен (не нужно устанавливать только push-server).
- Apache 2.4 и php 7.4:
# yum install httpd -y
# yum -y install php php-cli php-common \
php-devel php-gd \
php-imap php-json php-ldap php-mbstring \
php-mysqlnd php-opcache php-pdo \
php-pear php-pear-DB php-pecl-apcu \
php-pecl-apcu-bc php-pecl-geoip \
php-pecl-mcrypt php-pecl-memcache \
php-pecl-ssh2 php-process php-pspell php-xml php-zipstream
С 01.02.2023 ограничивается поддержка наших продуктов на PHP версии ниже 8.0. Рекомендуемая версия PHP - 8.1 и выше. Поэтому после установки необходимо обновить PHP до версии не ниже 8.0.
- Nginx (версия 1.18):
yum install nginx -y
- MariaDB сервер (версия 10.5):
yum -y install mariadb-server mariadb
- Node и npm (push-server), версия 16.13:
yum install nodejs -y
- Redis (версия 6.2):
yum install redis -y
Конфигурация Nginx
Настройте конфигурацию Nginx.
- Рабочий каталог для сайта -
/var/www/html/bx-site
.
- Пользователь для web окружения - nginx, группа apache.
Конфигурация nginx сервера:
/etc/nginx/nginx.conf # основной конфигурационный файл
|_conf.d/upstreams.conf # конфигурация для upstream серверов: apache && push-server
|_conf.d/maps-composite_settings.conf # параменные используемые для кеша
|_conf.d/maps.conf # дополнительные переменные
|_conf.d/http-add_header.conf # CORS заголовки
|_sites-available/*.conf # подключаем сайты
|_default.conf # сайт по умолчанию (настраиваем только 80 порт)
|_conf.d/bx_temp.conf # конфигурация BX_TEMPORARY_FILES_DIRECTORY
|_conf.d/bitrix.conf # дефолтная конфигурация сайта
|_rtc.conf # проксирование запросов на push-server (публикация)
Дефолтная конфигурация сайта:
conf.d/bitrix.conf # основные блоки со включенным по умолчанию кешем в файлах
|_conf.d/bitrix_general.conf # отдача статики, быстрая отдача для внешних хранилищ и прочее
|_conf.d/errors.conf # обработка ошибок
|_conf.d/im_subscrider.conf # проксирование запросов на push-server (получение)
|_conf.d/bitrix_block.conf # блокировки по умолчанию
Конфигурация взята из виртуальной машины и может показаться избыточной, но фактически поддерживает те же возможности, что и виртуальная машина.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redos/nginx
.
Разместите их в директории /etc/nginx/
.
В сервисе используются имена для проксирования на определенные службы:
- httpd – проксирование запросов на apache;
- push – проксирование запросов на push-server.
Чтобы заработала конфигурация, необходимо прописать их в локальных адресах. Если сервисы расположены на другом хосте, укажите здесь правильный адрес:
echo "127.0.0.1 push httpd" >> /etc/hosts
Запустите сервис:
systemctl --now enable nginx
Конфигурация php
В данной версии установки централизованное хранилище конфигов: /etc/php.d
.
Минимальные настройки, которые необходимо добавить:
- для модуля opcache:
opcache.max_accelerated_files = 100000
opcache.revalidate_freq = 0
- настройки файла bitrexenv.ini:
display_errors = Off
error_reporting = E_ALL
error_log = '/var/log/php/error.log'
; Set some more PHP parameters
enable_dl = Off
short_open_tag = On
allow_url_fopen = On
# Security headers
mail.add_x_header = Off
expose_php = Off
...
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для PHP расположены в папке: redos/php.d
.
Разместите их в директории /etc/php.d/
.
Конфигурация Apache
По умолчанию Apache настроен на дефолтный сайт в каталоге /var/www/html
.
Основные действия для настройки конфигурации Apache:
- изменить каталог для сайта на
var/www/html/bx-site
;
- изменить порт, который слушает сервис (так как в качестве внешнего сервиса будет использоваться nginx);
- импортировать настройки для сайта из виртуальной машины.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Apache расположены в папке: redos/httpd
.
Разместите их в директории /etc/httpd/
.
Необходимо настроить два файла:
conf.d/default.conf
– в описании сайта замените каталог на var/www/html/bx-site
;
conf/httpd.conf
– в Listen замените порт на 8090.
conf.modules.d/00-mpm.conf
- смена mpm event на prefork.
Запустите сервис:
systemctl --now enable httpd
Конфигурация MariaDB
Для конфигурации MariaDB выполните следующие настройки:
- transaction-isolation измените на
READ-COMMITTED
;
- innodb_flush_method установите равным
O_DIRECT
(рекомендованная, но не обязательная настройка);
- innodb_flush_log_at_trx_commit установить равным 2 (рекомендованная, но не обязательная настройка).
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для MariaDB расположены в папке: redos/my.cnf.d
.
Разместите их в директории /etc/my.cnf.d/
.
Запустите сервис:
systemctl --now enable mariadb
Настройка сервиса выполняется через mysql_secure_installation.
Конфигурация Redis
Данный сервис необходим для организации Push-сервера.
Основные настройки, которые необходимо выполнить в конфигураторе:
- включить файловый сокет для работы;
- отключить сброс данных на диск (для работы Push-сервера эта возможность не нужна);
- установить группу пользователя.
Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redos/redis
.
Разместите их в директории /etc/redis/
и выполните команды:
su -
usermod -g apache redis
chown root:apache /etc/redis/ /var/log/redis/
[[ ! -d /etc/systemd/system/redis.service.d ]] && mkdir /etc/systemd/system/redis.service.d
echo -e '[Service]\nGroup=apache' > /etc/systemd/system/redis.service.d/custom.conf
systemctl daemon-reload
Запустите сервис:
systemctl --now enable redis
Конфигурация Push-server
Схема работы:
----------------------- ---------------------------------------------------
| nginx: 0.0.0.0:80 | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
----------------------- ---------------------------------------------------
----------------------- ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
----------------------- ---------------------------------------------------
Nginx проксирует запрос на push-сервис выбранного типа. Запросы получения сообщений (например, sub) – публичные, проксируются со стандартных портов 80/443. Запросы публикации (pub) – доступны только с внутреннего адреса сервера.
Nodejs-процессы делятся на два типа:
- Процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Слушают порты 8010-8015;
- Процессы, отвечающие за отправку сообщения в канал. Слушают порты 9010-9011.
Для запуска Push-сервера необходимы:
- nodejs & npm;
- архив сервиса и его модулей.
Выполните следующие действия:
- Скачайте и установите архив push-server-0.3.0.tgz:
su -
cd /opt
wget https://repo.bitrix.info/vm/push-server-0.3.0.tgz
npm install --production ./push-server-0.3.0.tgz
Установка закончится строкой:
added 73 packages, and audited 74 packages in 8s
- Для удобства дальнейшей работы выполните команды:
su -
ln -sf /opt/node_modules/push-server/logs /var/log/push-server
- Скопируйте файлы сервиса и основную конфигурацию:
su -
cd /opt/node_modules/push-server
cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
cp etc/sysconfig/push-server-multi /etc/sysconfig/push-server-multi
cp etc/push-server/push-server.service /etc/systemd/system/
ln -sf /opt/node_modules/push-server /opt/push-server
- В конфигурационном файле
/etc/sysconfig/push-server-multi
исправьте (или добавьте, если их нет) следующие параметры:
- SECURITY_KEY – секретный ключ для подписи соединения между клиентом и пуш-сервером;
Примечание: Длина ключа не имеет значения. В ключе можно использовать только буквы латинского алфавита и цифры (спецсимволы запрещены). Но имейте в виду, что простой короткий ключ небезопасен. Можно генерировать его, например, таким образом:
cat /dev/urandom |tr -dc A-Za-z0-9 | head -c 128
- RUN_DIR – директория для хранения PID файлов процесса;
- USER/GROUP – пользователь, под которым будет запущен сервис.
Пример настроек параметров:
GROUP=apache
SECURITY_KEY="SECURITYKEY123456"
RUN_DIR=/tmp/push-server
- Каждый nodejs-процесс будет запущен как отдельный процесс. Сгенерируйте конфигурации:
/usr/local/bin/push-server-multi configs pub
/usr/local/bin/push-server-multi configs sub
Сгенерированные конфигурации в формате [dw]json[/dw][di]push-server-sub-80XX.json
push-server-pub-90XX.json[/di] будут размещены в каталоге: /etc/push-server/
.
- Создайте каталог через tmpfiles.d:
echo 'd /tmp/push-server 0770 apache apache -' > /etc/tmpfiles.d/push-server.conf
systemd-tmpfiles --remove --create
- В конфигурационном файле сервиса
/etc/systemd/system/push-server.service
измените пользователя:
[Service]
User=apache
Group=apache
ExecStart=/usr/local/bin/push-server-multi systemd_start
ExecStop=/usr/local/bin/push-server-multi stop
...
- Переконфигурируйте:
systemctl daemon-reload
- Запустите сервис:
systemctl --now enable push-server
- Перейдите в конфигурацию Push-модуля (настройки сайта) и включите использование локального Push-сервера (последняя версия). Укажите секретный ключ, который настраивали ранее в файле
/etc/sysconfig/push-server-multi
.
Конфигурация сайта
Сайт
Создайте рабочий каталог:
mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown apache:apache /var/www/html/bx-site -R
Аналогичным образом скачайте нужный дистрибутив и установите его в каталог: /var/www/html/bx-site
.
Создайте базу данных и пользователя:
create database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';
Необходимо заменить 'PASSWORD'
, на пароль который будете использовать для доступа к БД.
Push-server
Для работы портала необходимо настроить push-server. Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.
Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php
, добавив следующую секцию:
return array (
'pull' => Array(
'value' => array(
'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
'nginx_version' => '4',
'nginx_command_per_hit' => '100',
'nginx' => 'Y',
'nginx_headers' => 'N',
'push' => 'Y',
'websocket' => 'Y',
'signature_key' => 'SECURITYKEY123456',
'signature_algo' => 'sha1',
'guest' => 'N',
),
),
...
Внимание! .Обратите внимание,
signature_key должен содержать тот же ключ, который вы указали в
/etc/sysconfig/push-server-multi
в соответствующем ключе. Если все хорошо, то после перезапуска httpd:
systemctl restart httpd
Вы увидите запросы к push-server:
Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols
Монитор производительности
Монитор производительности показывает скорость работы сайта на хостинге, выявляет узкие места (скрипты на сайте, которые потребляют наибольшее число системных ресурсов) и основные ошибки настройки сервера.
Подробнее про оптимальную настройку сервера можно посмотреть в главе [ds]Конфигурирование веб-систем для оптимальной работы[/ds][di]Типовые настройки серверного программного обеспечения рассчитаны на минимальное оборудование и статические HTML-приложения. Внесение некоторых конфигурационных изменений в серверное ПО позволяет в несколько раз увеличить производительность системы в целом, сократить время генерации страниц, увеличить устойчивость системы к пиковым нагрузкам.
Подробнее ...[/di].
Настройки модуля
Настройки модуля
Глобальные параметры модуля определяются на странице настроек Монитор производительности (Настройки > Настройки продукта > Настройки модулей > Монитор производительности).
Для настройки модуля доступны следующие опции:
Вкладка Генератор таблетов предназначена для разработчиков. На ней включается автоматическая генерация таблетов для ORM и настраиваются параметры генератора.
Настройка прав доступа производится типовым для Bitrix Framework способом. Подробнее про [ds]настройку доступа[/ds][di]Настройка прав доступа к модулям системы позволяет определить диапазон допустимых действий пользователя над модулем и его контентом. Управление правами доступа к модулям выполняется:
Подробнее ...[/di] к модулям.
Публичная часть модуля
Просмотр статистики "с лица"
Для оценки производительности в публичной части сайта используется кнопка [dw]Отладка[/dw][di]
[/di], которая позволяет отображать статистику прямо на странице:
Примечание:
- Для административной части сайта также доступна Статистика SQL-запросов, Время исполнения страницы. [dw]Отображение статистики[/dw][di]
[/di] включается с помощью меню кнопки Отладка в публичной части сайта.
- До версии 20.0.1300 также отображалась Статистика компрессии. С указанной версии модуль Компрессия удалён из продукта.
Что отображается в статистике
Статистика в целом по странице отображается внизу страницы:
Информация о запросах
Для просмотра информации о запросах компонента выберите пункт меню Статистика включаемых областей и затем используйте ссылку вида Запросов: n, отображаемую в информационной области, которая расположена рядом с компонентом:

Откроется форма, в которой будет отображена [dw]информация о запросах[/dw][di]В нижней части формы отображается детальная информация о каждом запросе. Для отображения информации о другом запросе компонента необходимо использовать ссылку в верхней части формы.[/di]:

Кеш
Данные о кеше выводятся во всплывающем окне:

Административные страницы модуля
В административной части сайта к модулю
Монитор производительности относятся следующие страницы, расположенные в разделе
Производительность (
Настройки > Производительность).
Скорость сайта
Следите за скоростью работы сайта
Важнейшим показателем качества работы любого сайта является скорость его загрузки. Если посетителю вашего ресурса придется ждать загрузки страницы хотя бы несколько секунд, с высокой долей вероятности он уйдет.
Скорость сайта - комплексный показатель комфортности работы с сайтом для посетителей. [dw]Инструмент[/dw][di]Доступен после установки обновления main 14.9.0 и только для русских версий продуктов "1C-Битрикс: Управление сайтом".[/di] учитывает качество разработки сайта, качество хостинга и доступность сайта по сети. Рассчитывается для 1000 последних посетителей сайта. Скорость сайта фактически показывает, как быстро отобразился сайт для большинства из этих 1000 посетителей.
В отличие от большинства сервисов, замеряющих скорость загрузки сайта из внешних точек, скорость загрузки ресурса инструментом Скорость сайта проверяется на хитах реальных пользователей. Так как посетители все время меняются, то и данные меняются вместе с ними.
На Рабочем столе в административной части есть гаджет, показывающий текущую скорость загрузки страниц вашего сайта:

Как считается Скорость сайта |
Для подсчёта данных скорости сайта в этом инструменте используется стандартная функция любого современного браузера: Navigation Timing API. В браузере есть объект performance с ключом timing, который возвращает временные отметки этапов запроса к странице:

События полного цикла загрузки страницы:
Событие (метрика) | Описание |
navigationStart | Время начала навигации |
unloadEventStart | Время начала выгрузки предыдущего документа (0, если такового не было) |
unloadEventEnd | Время завершения выгрузки предыдущего документа (0, если такового не было) |
redirectStart | Время начала редиректа (или последовательности редиректов. 0, если таковых не было) |
redirectEnd | Время окончания редиректа (или последовательности редиректов. 0, если таковых не было) |
fetchStart | Время первого обращения в кэш браузера или начала загрузки страницы. |
domainLookupStart | Время начала поиска адреса для доменного имени. Если страница извлекается из кэша, то свойство равнозначно предыдущей метрике. |
domainLookupEnd | Время завершения поиска адреса для доменного имени. Если страница извлекается из кэша, то свойство равнозначно предыдущей метрике. |
connectStart | Время начала соединения с сервером сайта или приложения. Если страница загружается из кэша или локально, то свойство равнозначно предыдущей метрике. |
connectEnd | Время завершения соединения с сервером сайта или приложения. Если страница загружается из кэша или локально, то свойство равнозначно предыдущей метрике. |
secureConnectionStart | Время первого "рукопожатия" при инициализации безопасного HTTPS соединения. |
requestStart | Время начала загрузки основного документа (как из удаленного сервера, так и из кэша или локального ресурса). Технология [ds]Композитный сайт[/ds][di]Технология Композитный сайт позволяет соединить достоинства быстрой выдачи страницы пользователю с гибкостью отображения информации в зависимости от различных условий запроса страницы. Это некий надуровень, который может быть записан в статику и отдаваться всем, вместе с результатом работы всех остальных способов кеширования. Технология является дальнейшим развитием и одним из видов кеширования, используемых в Bitrix Framework.
Подробнее ...[/di] ускоряет именно этот отрезок тайминга - Request. |
responseStart | Время до начала ответа сервера (время до первого полученного байта) |
responseEnd | Время до полной загрузки основного документа |
domLoading | Время установления свойству readyState значения "loading" |
domInteractive | Время установления свойству readyState значения "interactive" - момент, когда пользователь может взаимодействовать со страницей |
domContentLoadedStart | Время события DOMContentLoaded |
domContentLoadedEnd | Время завершения всех действий связанных с предыдущим событием |
domComplete | Время установления свойству readyState значения "complete" |
loadEventStart | Время события onLoad |
loadEventEnd | Время завершения всех действий связанных с предыдущим событием |
|
Скоростью сайта считается время между navigationStart и domContentLoaded .
Технология подсчёта значения Скорость сайта следующая: из 1250 последних хитов вычитаются 250 (20%) самых медленных. Для оставшихся считается [ds]медиана,[/ds][di]
Медиа́на (от лат. mediāna — середина) в математической статистике — число, характеризующее выборку (например, набор чисел). Если все элементы выборки различны, то медиана — это такое число выборки, что ровно половина из элементов выборки больше него, а другая половина меньше него. В более общем случае медиану можно найти, упорядочив элементы выборки по возрастанию или убыванию и взяв средний элемент.
Подробнее...[/di] которая и выводится в гаджете. В результате полученное значение включает в себя как параметры сети, так и организацию бек-энда и фронт-энда.
Примечание: 20% "плохих" хитов откидываются, чтобы исключить ошибку, связанную с неустойчивыми каналами связи (мобильный интернет, связь в средствах транспорта и подобные).
На Скорость сайта оказывают влияние различные факторы: производительность и настройки сервера, скорость "интернета" (доставки страничек сайта до посетителей), качество разработки сайта и использование различных технологий, ускоряющих его работу. Например, сторонние подключаемые скрипты, которые долго загружаются и исполняются, могут в итоге увеличивать общее время отображения страницы.
Сюда же входит правильность настройки сервера и его производительность, которую можно оценить на странице [ds]Монитор производительности[/ds][di]Для оценки производительности необходимо перейти в раздел Монитор производительности (Настройки > Производительность > Панель производительности)....
Подробнее ...[/di]. Чем медленнее или проблемнее сервер, тем больше времени понадобится для получения страницы, и тем хуже будет показатель скорости сайта.
Инструмент учитывает все эти параметры и показывает реальную картину работы вашего сайта для пользователей из сети.
|
Страница Скорость сайта
Для просмотра подробной информации о скорости загрузки сайта перейдите на страницу Скорость сайта (Настройки > Производительность > Скорость сайта).
В самом верху страницы выбирается сайт, для которого будет показана статистика. В списке доступны адреса всех сайтов, привязанных к лицензионному ключу. Ниже отображается оценочная характеристика скорости работы сайта:

Чтобы оперативно контролировать скорость работы сайта прямо с этой же страницы можно перейти к настройкам в [ds]Панели производительности[/ds][di]Для оценки производительности необходимо перейти в раздел Монитор производительности (Настройки > Производительность > Панель производительности).
Подробнее ...[/di], [ds]Композитного сайта[/ds][di]Для включения технологии необходимо понять какой режим вы хотите использовать (автоматический или ручной) и нажать кнопку включения на нужной закладке. Активизация одного из режимов делает неактивной кнопку включения другого режима.
Подробнее ...[/di] и [ds]CDN[/ds][di]После включения поддержки CDN ссылки на статические файлы сайта (картинки, файлы стилей css, скрипты js) будут заменены. Вместо локальных URL'ов будут использоваться служебные имена серверов сети CDN. При этом не потребуется вносить никакие изменения в DNS и не нужно заботиться о сбросе кеша CDN при обновлении файлов.
Подробнее ...[/di].

Выводить только лишь средний показатель не эффективно. Страницы могут различаться как по количеству контента, так и по количеству скриптов и времени их выполнения. Для этого доступна соответствующая диаграмма, которая показывает, как распределились страницы и какие из них влияют на ухудшение среднего результата:

На диаграмме показано время, с которым страницу увидел посетитель, и количество страниц, загруженных с таким временем. Если подвести курсор к конкретному столбцу диаграммы, то будут отображены 10 страниц с худшими показателями времени загрузки.
Еще ниже представлен график, отображающий статистику последних посещений сайта на разных этапах загрузки страницы:

- DNS (DNS Lookup). Хоть в большинстве своем, запрос к DNS по скорости близок к нулю, так как данные кешируются и браузерами, и самими серверами DNS (локальными, серверами провайдера и т.п.) инструмент "скорость сайта" учитывает этот параметр и выводит его на график.
- Дальше происходит Подключение к серверу (Connect to Server) и разрешение на дальнейшие действия. Это некое "рукопожатие", время которого также выводится на график.
- Следующий шаг - это Ответ сервера (Request Document). Чем дальше от клиентов находится сервер, тем больше будет этот показатель. По нему можно ориентироваться, сколько теряется времени на ответ сайта посетителю.
Данный ответ может быть не разовой операцией, ведь чем больше запросов делает страница к серверу, чтобы произвести загрузку ресурсов и т.п., тем дольше все будет отрабатываться.
- Дальше происходит Загрузка HTML (Receive Document). Здесь учитывается время загрузки HTML-страницы для ее последующей обработки.
- После того, как страница загрузилась, начинается процесс ее обработки - Обработка HTML ([dw]часть блока[/dw][di]
[/di] Process the Document and Load the DOM) и загрузки ресурсов.
Вот здесь при наличии ошибок в разработке, процесс загрузки страницы может очень "просесть", что будет заметно на графике.
- Далее следует Отрисовка страницы ([dw]сумма процессов[/dw][di]
[/di]), когда браузер обрабатывает содержимое страницы (синтаксический анализ HTML, CSS, обработка элементов JavaScript и отображение страницы) после загрузки её с сервера и до начала отрисовки.
Примечание: Все графики можно совместить, или отслеживать их в разрезе каждой страницы, поднося курсор к нужным узлам.
Страницы и компоненты
Чтобы собиралась статистика по нагрузке страниц, должен быть включен Монитор производительности (в настройках модуля, опция Включить монитор).
Страницы
На странице Монитор производительности: страницы (Настройки > Производительность > Страницы) можно просмотреть отчет по нагружаемости страниц:

Переход по ссылке с названием страницы позволяет просмотреть все её хиты на странице Хиты.
Компоненты
На странице Монитор производительности: компоненты (Настройки > Производительность > Компоненты) можно просмотреть отчет по используемым на страницах сайта компонентам или включаемым областям:

Переход по ссылке в графе Запросы позволяет просмотреть все SQL Запросы компонента на странице SQL Запросы.
Здесь же можно включить группировку по компонентам, если необходимо увидеть общую картину по использованию того или иного компонента.

Хиты
На странице Монитор производительности: хиты (Настройки > Производительность > Хиты) выводится отчет по [dw]хитам[/dw][di]Хит - это запрос к веб-серверу для получения файла (веб-страницы, изображения, JavaScript'а, таблицы стилей и т. д.).
Подробнее...[/di]:

Переход по ссылке >> позволяет перейти на желаемую страницу в публичную часть сайта и просмотреть [dw]детальную статистику[/dw][di]
[/di].
Примечание: Нажав кнопку [dw]Отладка[/dw][di]

[/di] или выбрав пункт меню
Суммарная статистика (
Отладка > Суммарная статистика) на
Панели управления в публичной части сайта и перейдя по ссылке
>> со страницы
Монитор производительности: хиты (
Настройки > Производительность > Хиты), можно просмотреть [dw]более детальную статистику[/dw][di]

[/di].
Переход по ссылке с названием страницы (или по ссылке в графе Запросы) позволяет просмотреть все SQL запросы хита на странице SQL Запросы.
Переход по ссылке в графе Компоненты позволяет просмотреть отчет по используемым компонентам для хита на странице Компоненты.
SQL запросы
На странице Монитор производительности: запросы (Настройки > Производительность > SQL запросы) отображается отчет, если в настройках модуля включены опции [dw]Вести журнал запросов и Сохранять стек вызова для SQL запросов.[/dw][di]
[/di]:

Двойной клик по строке таблицы с запросом или пункт меню действий План исполнения позволит просмотреть план исполнения запроса [dw]в новом окне[/dw][di]
[/di].
После проведения теста в панели производительности наведение указателя мыши на текст запроса вызовет его стек. В первой строке отображается исходная функция, вызвавшая его:

Кеширование
Информация о файлах кеша доступна при включённой в настройках модуля Монитор производительности опции [dw]Вести журнал кеширования[/dw][di]
[/di]. В этом случае эта информация отобразится на странице Кеширование (Настройки > Производительность > Кеширование).
Кнопка Группировка позволяет выбрать режим отображения данных в таблице:
- Без группировки - отображается вся информация о кеше, без каких-либо группировок;
- Группировка по компонентам - информация о кеше сгруппирована по названию компонентов;
- Группировка по типу - информация о кеше сгруппирована по типу кеша (управляемый / неуправляемый);
- Группировка по каталогу - информация о кеше сгруппирована по каталогам, в которых хранятся файлы кеша;
- Группировка по файлу - информация о кеше сгруппирована по файлам, в которых хранятся кеш.
Ссылки в таблице позволяют применять фильтр, согласно выбранному полю. Для полей таблицы в колонке Файл ссылка с названием позволяет перейти к просмотру содержимого этого файла.
Таблицы в базе данных
Таблицы БД
Просмотреть их можно на странице Таблицы в базе данных (Настройки > Производительность > Таблицы ):

Показ столбца Размер индексов добавлен с версии модуля 23.0.0.
Работая со списком таблиц вы можете использовать:
- [dw]Групповые действия[/dw][di]
[/di] для применения оптимизации или преобразований сразу к нескольким таблицам;
- [dw]Фильтры[/dw][di]
[/di]. После введения текста в поле в списке останутся только те таблицы, что содержат указанный текст.
Переход по ссылке с именем таблицы позволяет просмотреть её содержимое.
Работа с записями таблицы
При открытии таблицы из списка, вы увидите список всех её записей. На такой странице доступны следующие возможности:
Примечание: с версии модуля 23.0.0 обновлен интерфейс работы с таблицами. Далее в уроке показаны скриншоты из нового интерфейса.
Система запоминает просмотренные вами таблицы. В режиме просмотра записей, на контекстной панели в правом верхнем углу будет доступно меню
Последние таблицы (n), которое позволяет быстро и удобно переключаться между ними. На странице со списком всех таблиц также отображаются [dw]Последние просмотренные таблицы[/dw][di]

[/di].
Индексы
Индексы
Заочно нельзя сказать какие [ds]индексы[/ds][di]Поиско́вый и́ндекс - структура данных, которая содержит информацию о документах и используется при поиске на сайте.
Подробнее ...[/di] необходимо создавать, надо всегда рассматривать конкретную ситуацию. Они нужны для конкретных выборок на конкретных проектах. В зависимости от архитектуры и логики проекта медленные запросы получаются у каждого свои, и для них нужны свои индексы, часто составные.
Страницы Анализ индексов и Список индексов - инструмент анализа и рекомендаций по созданию индексов.
Создание индекса (видеоурок)
Анализ индексов
Анализ индексов лучше производить после получения списка медленных запросов. Для этого в настройках модуля включите [dw]соответствующую опцию[/dw][di]
[/di] и установите время, после которого запрос будет считаться медленным. Рекомендуемое время работы монитора - [dw]сутки[/dw][di]
Данное время работы можно установить, если отмечена опция Записывать только медленные SQL запросы. В противном случае время работы монитора составляет до 1 часа.
[/di], но, опять же, надо учитывать реалии конкретного проекта.
После получения списка медленных запросов на странице Анализ индексов (Настройки > Производительность > Индексы > Анализ индексов) необходимо воспользоваться кнопкой Выполнить анализ собранных SQL запросов и отобразится список всех запросов, которые были совершены за это время, отсортированных по имени таблицы:

В общем списке в первую очередь нужно обращать внимание на запросы с большей продолжительностью и на большое их количество. Но и в случае больших величин у этих параметров не на каждый запрос стоит создавать индекс (возможно нужно просто исправить код компонента). Косвенным критерием успешности создания индекса служит время выполнения запроса до и после создания индекса.
При необходимости можно посмотреть план выполнения любого запроса. Команда Детальный анализ позволяет перейти к анализу конкретного запроса и созданию его индекса.
На этой странице жирным шрифтом выделяются таблица и колонки, к которым обращается запрос.
[dw]Структура таблицы[/dw][di]
[/di] - информационная закладка. Главное в ней - размер таблицы. И если размер большой (к примеру, больше 100 мегабайт), то построение и удаление индексов лучше проводить в часы наименьшей нагрузки на сайт.
[dw]Анализ запросов[/dw][di]
[/di] - закладка с собственно анализом запроса. При принятии решения о создании индекса учитывайте, селективен ли этот запрос и процент [dw]селективности[/dw][di]Селективность индекса – это отношение количества различных проиндексированных значений к общему количеству строк в таблице. Индекс с высокой селективностью хорош тем, что позволяет Базе данных при поиске соответствий отфильтровывать больше строк. Подробнее...[/di]. Информация об этом выводится в таблице.
Создание индекса - закладка, на которой непосредственно принимается решение о создании (или нет) индекса. Те запросы, по которым не нужно создавать индекс, можно внести в список Не предлагать создавать.
Запросы, по которым принято решение, пропадают из списка запросов и появляются на странице Список индексов.
Список индексов
Страница Список индексов (Настройки > Производительность > Индексы > Список индексов) отображает результаты ваших решений по анализу тех или иных запросов. "Зелёный" статус - индекс создан, "красный" статус - индекс не будет создаваться.

Настройки и ошибки PHP
Настройки
На странице Монитор производительности: настройки PHP (Настройки > Производительность > PHP) отображается сводная таблица Параметры окружения с анализом параметров PHP.
С помощью ссылки Настройки PHP можно перейти на страницу с подробной информацией (phpinfo).
Ошибки
На странице Монитор производительности: журнал ошибок PHP (Настройки > Производительность > Ошибки PHP (N)) можно просмотреть журнал регистрации ошибок PHP, где N - общее количество ошибок.
Примечание: Данная страница отображается, только если в настройках модуля Монитор производительности указана опция Вести журнал предупреждений PHP.
Журнал ошибок PHP ошибок хранится в базе. Удалить журнал ошибок PHP можно с помощью опции [dw]Удалить собранные ранее данные[/dw][di]Доступна только при отключенном мониторе
[/di] в настройках модуля Монитор производительности.
Сервер БД
На странице Монитор производительности: сервер БД (Настройки > Производительность > Сервер БД) отображается сводная статистика производительности сервера базы данных и рекомендации:
Значения, отличающиеся от рекомендуемых, выделяются цветом:
История замеров производительности
|
История работы над производительностью |
На странице История замеров производительности (Настройки > Производительность > История) выводятся результаты прошлых замеров производительности.
В таблице отображается производительность системы с указанием даты замера.

Панель производительности
Вы узнаете, как протестировать производительность, определить проблему и поправить "узкие" места сайта.
Панель производительности: поиск "узких" мест сайта
Поиск "узких" мест сайта
Для оценки производительности перейдите в раздел Монитор производительности (Настройки > Производительность > Панель производительности).
Нажатие кнопки Тестировать производительность позволит вам определить слабые места настройки хостинга. Важно понимать, что цифры в строке Конфигурация могут отличаться в разы при изменении нагрузки на сервер: если нагрузки нет, производительность может быть высокой, если есть – она сможет снизиться. Это связано с тем, что данные цифры показывают скорость открытия пустой страницы сайта и, естественно, зависят от общей загрузки сервера.
Проблема далеко не всегда кроется в хостинге, она может быть и в самом сайте. Модуль позволяет определить проблему и исправить её. Для этого требуется запустить тест производительности в течение некоторого времени – для [dw]малопосещаемых проектов[/dw][di]Если сайт малопосещаемый, рекомендуется самому открывать различные страницы сайта для сбора статистики модуля.[/di] – час, для посещаемых можно выбрать меньшее время. Система будет фиксировать посещения и собирать статистику о времени выполнения каждой страницы, числе SQL запросов и другие параметры.
Показатель производительности - величина, обратная времени исполнения ядра продукта (среднему на 10 измерений).
Если [dw]Производительность = 18,66[/dw][di]
[/di], то публичная страница сайта с пустым шаблоном (например, версия для печати), с пустой рабочей областью будет создаваться за 1/18,66 или 0,0536 сек. Если говорить проще, то сервер сгенерирует 18 (пустых, но с подключением ядра) страниц в секунду. То есть чем выше число, тем производительнее работает сайт.
Умножив 18 (страниц в секунду) на 60 получим, что сервер может генерировать около 1080 пустых, но с подключением ядра, страниц в минуту. Так, если посещаемость ресурса составляет всего 1000 человек в день, то производительность сервера будет [dw]на пределе[/dw][di]Предполагается, что эта 1000 посетителей вдруг зашла на сайт одномоментно.[/di]. Естественно, в реальных условиях производительность будет ниже, в зависимости от "нагруженности" различных страниц сайта, нагрузки на сам сервер и других условий.
Показатель производительности не вычисляется на основе производительности файловой системы, работы базы, сессий и почты. Эти цифры нужны для того, чтобы помочь системному администратору найти узкое место (если такое есть). Величина производительности всегда обратна величине среднего времени отклика.
Что важно знать
Важно: Абсолютные цифры монитора производительности сами по себе ничего не значат. Они нужны только для того, чтобы помочь найти и решить [dw]проблему производительности[/dw][di]Например, известно, что страница или раздел сайта открываются долго (несколько секунд и дольше). Тогда оценка монитора производительности покажет, что в данном случае является препятствием.[/di].
Если какая-то из подсистем сайта работает медленно, возможно, проблема не в самом сайте, а в конфигурации ОС или неустановленных необходимых драйверах. Это комплексная задача, которая должна решаться квалифицированным системным администратором. Можно взять мощное железо и получить низкие цифры.
При оценке производительности учтите что:
- Оценка зависит от редакции продукта.
Раз мы замеряем время работы ядра, очевидно, оно будет зависеть от размера ядра. Для редакции «Бизнес» со всеми включенными модулями оценка всегда будет ниже, чем на «Старте» на том же оборудовании. Эталонная оценка в Мониторе производительности продукта делалась на редакции «Бизнес».
- Результат зависит от пользовательских функций в
/bitrix/php_interface/init.php
.
Указанный [dw]файл[/dw][di]Примечание: файл init.php подключается при открытии каждой страницы сайта и служит для запуска обработчиков событий или подключения каких-либо дополнительных функций. Файл не является обязательным (т.е. его может не быть в папке /bitrix/php_interface).[/di] подключается на каждый хит, в том числе и при работе административной части. Файл /bitrix/php_interface/init.php не должен содержать запросы к БД и любые другие ресурсоемкие операции.
- Оценка будет меняться в зависимости от нагрузки.
Чем больше нагружен сервер, тем ниже будет оценка. Но даже при пиковой нагрузке она не должна опускаться ниже приемлемого уровня, чтобы можно было говорить, что сервер справляется (например, не ниже 10 единиц, т.е. 0,1 сек. на страницу).
- Показатель производительности не показывает возможности масштабирования системы.
Процесс веб-сервера работает на одном ядре, а значит, когда измеряется производительность без нагрузки, число ядер процессора не влияет на результат. Другое дело под нагрузкой: многоядерная система в состоянии сохранить высокие показатели.
- Для базы данных на отдельном сервере оценка производительности будет ниже.
Когда речь идет о [dw]кластере[/dw][di]Кла́стер (англ. cluster - скопление, кисть, рой) - объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами. В рамках нашего рассказа имеется в виду кластер серверов.[/di], мы имеем масштабируемую систему: при увеличении нагрузки она должна сохранять хорошие показатели. Но при моментальном замере времени открытия страниц без нагрузки мы неизбежно увидим небольшое замедление за счет межсерверных коммуникаций.
Вкладка Конфигурация
Вкладка Конфигурация
Во вкладке отображаются текущие показатели производительности подсистем сервера и сравнение их с показателями эталонной системы.
Если какая-то подсистема не удовлетворяет оптимальным условиям, то будет выведена ссылка с рекомендациями по исправлению в колонке Примечание.
Основные ошибки конфигурации
- Не установлен акселератор php.
Наличие акселератора php просто жизненно необходимо, даже без дополнительных настроек страницы открываются в три раза быстрее, во столько же раз снижается нагрузка на процессор. Поддерживается акселератор OPcache.
- Включено ограничение open_basedir.
На shared хостинге сложно отделить клиентов друг от друга. Самый простой вариант: включить open_basedir, тогда на все операции с файлами происходит дополнительная проверка пути. Это существенно снижает производительность. Решением будет использовать собственный экземпляр Apache для каждого пользователя или установка дополнительных модулей на сервер для ограничения доступа. В этом случае ограничение open_basedir ставить не нужно! Доступ ограничивается системой для пользователя веб-сервера.
- Не установлен или не настроен NGINX.
Хоть это напрямую не влияет на оценку производительности, но чрезвычайно важно для нагруженных проектов: лучше когда статика (картинки, стили, ява скрипты) отдаётся NGINX'ом и не обрабатываться Apache. Посмотрите логи доступа Apache: там не должно быть ни одного запроса к статике!
- Не настроена база данных.
По возможности всегда используйте формат данных InnoDB, рекомендуемые настройки смотрите на странице монитора производительности Сервер БД.
- Стоят не оригинальные драйвера оборудования.
Особенно актуально для RAID контроллеров: при установке на Linux системах обычно предлагает к установке open source драйвера, которые не всегда достаточно эффективно работают с оборудованием. Всегда ставьте оригинальные драйвера с сайта разработчика.
- PHP как CGI.
PHP, запускаемый как CGI (не FastCGI) – плохая схема.
На каждое обращение к php-скрипту запускается новый процесс интерпретатора PHP. Все это работает очень медленно, производительность сайта будет крайне низкой.
Как читать оценку подсистем
Монитор производительности не имеет прямого доступа к системным ресурсам, поэтому оценки, полученные средствами PHP, в большей степени отражают работу PHP, чем сервера.
- Конфигурация - собственно, оценка производительности.
- Среднее время отклика - число, обратное оценке производительности.
- Процессор (CPU). Делается большое число простых математических вычислений. Задача не распараллеливается, поэтому идет оценка работы одного ядра процессора. Когда сайт работает на VPS, здесь часто можно увидеть, что "зажат" процессор.
- Файловая система. Этот тест показывает не столько работу диска, сколько работу PHP с файлами: создается, исполняется, удаляется большое число простых файлов. Данный показатель зависит от производительности файловой системы и эффективности работы PHP акселератора. В целом хорошо показывает, как работает PHP на данной конфигурации (без учета работы базы).
- Почтовая система. Отправляется тестовое письмо на hosting_test@bitrix.ru. Содержимое письма: "This is test message. Delete it." Никакая служебная информация не передается! Если настроена отправка почты на cron, этот показатель можно игнорировать.
- Время старта сессии. Сессия стартует на каждый хит, поэтому это время будет прибавляться к работе каждой страницы. Проблемы обычно возникают, когда меняются настройки хранения сессий PHP так, что скапливаются сотни тысяч файлов сессий.
- База данных (чтение/запись/удаление). Отправляется большое число простых запросов в базу. Это очень утрированный тест: он не показывает, как база будет работать со сложными запросами на больших объемах данных. Очевидно, что для базы данных на локальной машине цифры будут выше, чем для базы на отдельном сервере. Это нормально.
Вкладка Битрикс
Во вкладке отображаются текущие настройки продукта, непосредственно влияющие на производительность, с соответствующими рекомендациями для оптимальной работы продукта.
Клик по рекомендации – переход на страницу системы, где выполняются эти настройки.
Вкладка Разработка
Разработка
В этой вкладке отображается список страниц сайта, среднего времени выполнения и предполагаемых ошибок разработчика.
Например, ошибка, которую предлагается исправить, - некэшированные компоненты.
Примечание: Для просмотра информации об ошибках используйте ссылку в колонке Ошибки разработки.
Чтобы увидеть причину ошибки, нажмите на адрес страницы в колонке 20 самых нагружающих страниц.
Пример анализа
Список адресов и статистики выполнения для страницы /catalog/index.php
:
Обратите внимание – на странице /catalog/index.php
размещён комплексный компонент Каталог с включенным ЧПУ, поэтому реальные URL для этой страницы – разные. Приведенная таблица отсортирована по уменьшению времени выполнения страницы, и хорошо видно, что если в первый раз страница открывалась 1,5 секунды, то в последующие разы с постоянным уменьшением времени. При этом сработало кэширование компонентов, и, как следствие - уменьшение времени на выполнение SQL-запросов.
Проверим, какие компоненты выполняются на этой странице. Для этого нажмите на число в колонке Компоненты нужной страницы. Список компонентов и их характеристики для хита 14 по адресу /catalog/t-shirts/t-shirt-men-s-fire/
.
[dw]Вы увидите[/dw][di]
[/di] список компонентов, подключаемых на странице, число SQL-запросов из них и тип кэширования. В этом списке ищутся те некэшированное компоненты, о которых сообщал монитор производительности.
Аналогичным образом просматривается список SQL-запросов на этой странице (для данного хита). Для определения, какой из компонентов не кэшируется вернитесь на страницу Монитор производительности: хиты и нажмите на ссылку >> перед адресом страницы, откроется сводная статистика по странице. Здесь вы увидите, на каком именно этапе построения страницы сайта [dw]затрачивается максимальное время[/dw][di]
[/di].
Если на Панели управления нажата кнопка Отладка (Отладка > Суммарная статистика), то в этом окне будет отображён и [dw]список компонентов страницы[/dw][di]
[/di]. Любой из компонентов можно настроить, выбрав его из этого списка. Как правило, компоненты расположены в том же порядке, что и на странице диагностики.
Примечание: Подробнее про работу с монитором производительности в публичной части сайта смотрите в уроке
Публичная часть модуля.
Вкладка Масштабируемость
|
Получаем количественные данные |
В модуле [ds]Монитор производительности[/ds][di]Монитор производительности показывает скорость работы сайта на хостинге, выявляет узкие места (скрипты на сайте, которые потребляют наибольшее число системных ресурсов) и основные ошибки настройки сервера.
Подробнее ...[/di] доступен встроенный инструмент тестирования нагрузки многопоточных и [ds]веб-кластерных[/ds][di]
Модуль Веб-кластер — это комбинация технологических решений, которые позволяют распределить один сайт на несколько серверов, решая тем самым несколько задач:
1) обеспечение высокой доступности сайта;
2) его масштабирование в условиях возрастающей нагрузки;
3) балансирование нагрузки, трафика, данных между несколькими серверами.
Подробнее...[/di] систем (Настройки > Производительность > Панель производительности, вкладка Масштабируемость).

Для проведения теста настройте форму. Поясним некоторые поля.
- Сервер, который будет тестироваться. Для минимизации влияния самого тестирующего скрипта на результаты тестов рекомендуется запускать его не на тестируемых серверах, а на отдельном хосте.
Также на тестируемом сайте необходимо на время проведения теста отключить опцию блокировки пользователя при большом количестве соединений ([dw]Блокировать?[/dw][di]
[/di]) в настройках модуля Веб-аналитика, вкладка Настройки, секция Ограничение активности.
- Страница (оставьте пустым для системного теста). В поле указывается адрес страницы, к которой будут происходить обращения во время теста, например, к индексной странице. При пустом поле обращение будет происходить к [dw]системной странице[/dw][di]/bitrix/admin/perfmon_panel.php?test=Y&show_page_exec_time=Y&show_sql_stat=N[/di];
- Максимальная продолжительность теста (минут). Задаётся время в течение которого продолжается тест по достижению числа соединений, указанных в поле Конечное количество одновременных соединений, причем в каждом последующем шаге теста количество одновременных соединений будет одно и то же.
Нажмите Начать тестирование, и в реальном времени будут строиться: таблица с результатами, графики генерации Страниц в секунду и Время генерации/получения страницы.
Таблица Результаты
Помимо колонок № теста и Соединений, пояснения к которым не требуются, в таблице также присутствуют следующие колонки:
- Хитов - общее количество [dw]хитов[/dw][di]Хит – это запрос к веб-серверу для получения файла. Подробнее...[/di] произведенных за тест;
- Ошибок - в данном случае под ошибками понимается ответ сервера, отличающийся от
200 ОК
;
- Страниц в секунду - количество страниц отданных тестируемым сервером за секунду;
- Время генерации страницы - время генерации страницы на тестируемом сервере;
- Время получения страницы - время получения страницы от тестируемого сервера.
График Страниц в секунду
С увеличением количества одновременных соединений сервер должен отдавать больше страниц, поэтому при нормальных условиях график должен иметь тенденцию к росту.
Если при росте нагрузки график имеет горизонтальный вид, то это значит, что настройки не оптимальны или сервер начинает уже не справляться.
В тесте с одинаковым количеством соединений график не должен иметь провалов.
График Время генерации/получения страницы
С увеличением количества одновременных соединений время отдачи страниц клиентам будет также увеличиваться (синий график), а время генерации не должно меняться в широких пределах (красный график).
Пример нахождения мелких ошибок в производительности
Мелкие ошибки
в производительности сайта
Перед сдачей проекта протестируйте сайт и найдите ошибки в верстке, неправильно настроенного кэширования и другие мелкие недочеты. Для этого скачайте два-три раза все страницы на жесткий диск. Для этой цели хорошо подходит бесплатная программа wget, работающая под управлением Linux/Unix систем и встроенная в виртуальную машину VMBitrix.
В случае, если вы разрабатываете сайт на этой же виртуальной машине, вы получите полноценное тестирование с минимальными сетевыми задержками. Запуск тестирования несколько раз требуется для того, чтобы на каждой странице был создан кэш и повторный хит брался уже из кэша.
Для тестирования включите режим тестирования производительности, затем перейдите в виртуальную машину и выполните такие команды:
cd /tmp
mkdir test1
cd test1
rm -rf localhost
wget -m http://localhost
rm -rf localhost
wget -m http://localhost
rm -rf localhost
wget -m http://localhost
Для повтора теста повторите 2 последние команды. Если тестирование затянулось, прервать его можно, нажав CTRL+C.
Внимание! При большом числе обращений с одного адреса проактивная защита не позволит выполнить тестирование. Отключите контроль активности на странице
Проактивный фильтр (Настройки > Проактивная защита > Проактивный фильтр).
Низкая скорость работы сайта
и низкая оценка производительности
В первую очередь необходимо проверить наличие [ds]акселератора php[/ds][di]Наличие акселератора php просто жизненно необходимо, даже без дополнительных настроек страницы открываются в три раза быстрее, во столько же раз снижается нагрузка на процессор.
Подробнее ...[/di]. Это специальный модуль, который выполняет прекомпиляцию php скриптов, что позволяет уменьшить время работы скриптов в среднем в три раза.
Затем проверить, не включено ли расширение [ds]open_basedir[/ds][di]На shared хостинге сложно отделить клиентов друг от друга. Самый простой вариант: включить open_basedir, тогда на все операции с файлами происходит дополнительная проверка пути.
Подробнее ...[/di].
Медленное открытие
страниц
Наиболее просты в определении и легки для детектирования две проблемы:
- все или значительная часть страниц сайта открывается не очень быстро;
- некоторые разделы сайта почти не открываются или открываются очень медленно.
Причины могут быть разные, но, пожалуй, одни из самых частых:
Для первой проблемы. В коде страниц сайта имеются битые ссылки, которые переадресуются на индексную или на 404 страницу.
Такие несуществующие адреса легко отлавливаются после получасового теста Монитора производительности.
Для второй проблемы: после сбоя некоторые таблицы базы данных оказались повреждены. В результате нагрузка на MySQL возросла в сотни раз. 5-ти минутный тест Монитора производительности показал, что причина – в нескольких поврежденных таблицах в разделе Каталог.
Конфигурирование веб-систем для оптимальной работы
Типовые настройки серверного программного обеспечения рассчитаны на минимальное оборудование и статические HTML-приложения. Внесение некоторых конфигурационных изменений в серверное ПО позволяет в несколько раз увеличить производительность системы в целом, сократить время генерации страниц, увеличить устойчивость системы к пиковым нагрузкам.
В этой главе приведены рекомендации по настройке серверного ПО, которые выполняются сотрудниками компании «Битрикс» при конфигурировании проектов с посещаемостью более 3-10 тысяч уникальных пользователей в день, либо при недостаточности системных ресурсов для обработки меньшей нагрузки.
Все рекомендации относятся в основном к UNIX-системам или Windows-системам, использующим веб-сервер Apache.
Рекомендованные решения не являются единственными возможными. Предполагается, что данные инструкции послужат руководством для создания и доработки данных рекомендаций в соответствии с имеющимися ресурсами, оборудованием, конфигурациями из нескольких серверов.
Внимание! Все рекомендации подразумевают, что выполнены все обязательные требования и, по возможности, рекомендуемые установки на странице Проверка сайта (Инструменты > Проверка сайта) в Административном разделе продукта.
Примечание: Помимо изучения данной главы рекомендуем обратиться к опыту разработчиков сайтов на платформе Bitrix Framework. В частности можно использовать методики описанные в группе
Оптимизация веб-проектов.
Особенности веб-приложений
Веб-приложения отличаются от программ, работающих под управлением операционной системы, например, Windows.
Основное отличие – в задачах. Windows-приложение ожидает действий пользователя и работает постоянно, пока оно запущено. В случае веб-приложения посетитель сайта видит уже результат выполнения программы, которая, к этому времени, уже завершила свою работу и освободила ресурсы сервера для обслуживания других посетителей. При открытии другой (или этой же) страницы выполняется новый экземпляр программы, который, после выдачи данных пользователю, также завершается.
Таким образом, в операционной системе вам принадлежат все ресурсы компьютера, и почти неограниченное время, а в Веб вам принадлежит лишь совсем чуть-чуть памяти (обычно 32-256 мб) и немного времени (обычно не более 30-90 секунд). Кроме того, спецификой любого более-менее посещаемого проекта является необходимость обслуживать различное число посетителей в разное время суток, и простым увеличением ресурсов сервера добиться необходимого качества очень сложно.
В связи с этим конфигурирование веб-систем для работы с проектами на платформе Bitrix Framework имеет свои особенности.
PHP-приложения
Раньше HTML-проекты представляли собой обычный статический документ, который содержал специальные теги разметки. С точки зрения администратора веб-сайта, данные документы считываются веб-сервером и передаются по TCP/IP протоколу. Не выполняется никаких дополнительных приложений, не потребляется дополнительная память, не используется база данных. Это очень просто и удобно, но этого уже недостаточно для современных проектов.
Наличие программной среды в системе управления сайтом позволяет создавать динамические интернет-проекты, оперативно и легко управлять информацией, анализировать эффективность проектов, менять содержимое вашего сайта в зависимости от тех или иных потоков посетителей и многое другое. Можно сказать, что все современные веб-проекты создаются с использованием того или иного языка программирования.
Программный продукт "1C-Битрикс: Управление сайтом" разработан на языке программирования PHP. На данный момент поддерживается PHP версии 8.0.0 и выше.
PHP: (англ. PHP: Hypertext Preprocessor — «PHP: препроцессор гипертекста») — скриптовый язык программирования общего назначения с открытым исходным кодом, применяемый для разработки веб-приложений. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров и является одним из лидеров среди языков программирования, применяющихся для создания динамических веб-сайтов.
Обратите внимание на отличие PHP от скриптов, написанных на других языках, например, на Perl или C: вместо того, чтобы создавать программу, которая занимается формированием HTML-кода и содержит бесчисленное множество предназначенных для этого команд, создается HTML-код с несколькими внедренными командами PHP. Код PHP отделяется специальными начальным и конечным тегами, которые позволяют процессору PHP определять начало и конец участка HTML-кода, содержащего PHP-скрипт.
Значительным отличием PHP от какого-либо кода, выполняющегося на стороне клиента, например, JavaScript, является то, что PHP-скрипты выполняются на сервере. Если бы у вас на сервере был размещен PHP-скрипт, клиент получил бы только результат выполнения скрипта, причем он не смог бы выяснить, какой именно код выполняется. Вы даже можете сконфигурировать свой сервер таким образом, чтобы HTML-файлы обрабатывались процессором PHP, так что клиенты даже не смогут узнать, получают ли они обычный HTML-файл или результат выполнения скрипта.
С точки зрения администратора, принципиально важен тот факт, что PHP является интерпретируемым языком и PHP-скрипт исполняется только на сервере. Интерпретируемый язык - это значит, что сколько бы раз вы не запрашивали страницу на языке программирования PHP, она будет каждый раз обрабатываться на сервере специальным интерпретатором PHP, будет проверяться синтаксис языка, правильность конструкций и вызовы функций, и только после этого, код PHP будет исполняться.
Таким образом, в отличие от обычных HTML-страниц, сайты на PHP потребляют больше оперативной памяти на один процесс веб-сервера. Веб-сервер может приступить к передаче страницы клиенту в большинстве случаев только после того, как страница готова и PHP выполнил свои инструкции. Это приводит к некоторому замедлению по сравнению с HTML-страницами в выдаче содержимого клиенту.
Внимание! Задача администратора сервера – настроить программное обеспечение для минимизации нагрузки на сервер, организации стабильной работы сервера и ускорения работы сайтов.
Базы данных
Дополнительным фактором, влияющим на производительность системы, является правильное использование баз данных. Все современные проекты для отображения динамической информации (новостей, каталога товаров и др.) используют СУБД (системы управления базами данных), а СУБД, в свою очередь, требует правильной настройки своих параметров.
Соединение с базой данных
База данных представляет собой независимое клиент-серверное приложение, которое запускается и работает в операционной системе. Внешние приложения соединяются с базой данных через TCP/IP или внутренние потоки, направляют SQL-запросы и получают в ответ от базы данных необходимые данные.
Возможно два типа соединения с базой данных для веб-приложения:
- обычное соединение;
- постоянное соединение (Persistent).
Обычное соединение устанавливается каждый раз во время выполнения страницы при первом обращении к базе данных. Установленное соединение освобождается (в большинстве случаев и закрывается) после завершения страницы.
Постоянное соединение (функции PHP обычно называются *_pconnect) устанавливается один раз при первом обращении к базе данных и при повторных обращениях, даже из других страниц, используются уже открытые соединения к базе данных.
Учитывая, что открытие соединения к базе данных - процесс относительно дорогой по ресурсам и времени (происходит установление TCP/IP соединения, выделяются буферы памяти, проводится проверка и авторизация, настраиваются перекодировщики и выполняется целый ряд других функций), использование постоянных соединений является предпочтительным, если это не приводит к превышению числа одновременных соединений с базой данных. Целесообразность применения постоянных соединений прямо пропорциональна частоте обращений к базе данных, то есть посещаемости сайта.
Например, если на сайте за 15 минут в среднем бывает по 100 посетителей, применение define("DBPersistent", true);
целесообразно, если по 5, то, конечно же, нет.
Примечание: Устанавливая соединение с базой данных, при указании параметру
server значения
localhost
или
localhost:port
, PHP в большинстве своем будет пытаться соединиться с локальным сокетом без использования TCP/IP. Если вы все же хотите использовать TCP/IP, используйте адрес 127.0.0.1 вместо localhost.
Соединение без использования TCP/IP дает наивысшие результаты по производительности, особенно при передаче больших объемов информации из базы данных. Но если база данных расположена на другой машине и избежать соединения по TCP/IP не удается, использование постоянного соединения становится еще более выгодным.
В большинстве случаев база данных работает на той же машине, что и PHP-приложение и веб-сервер. Но вполне возможна ситуация, когда база данных установлена на соседней машине или даже у другого провайдера. "1С-Битрикс: Управление сайтом" устанавливает соединение с сервером базы данных через стандартные библиотеки, которые идут в поставке языка программирования PHP.
В
"1С-Битрикс: Управление сайтом" с версии 20.900.0 тип соединения с базой данных устанавливается в файле [dw]
/bitrix/.settings.php
[/dw][di]В файле:
/bitrix/php_interface/dbconn.php
до этой же версии[/di] в ядре D7.
Пример содержимого файла:
'connections' => array (
'value' => array (
'default' => array (
'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
'host' => 'localhost:31006',
'database' => 'admin_bus',
'login' => 'admin_bus',
'password' => 'admin_bus',
'options' => 2,
'handlersocket' => array (
'read' => 'handlersocket',
),
),
Используйте константу DBPersistent
, чтобы установить тип соединения с базой данных.
Для отключения постоянного соединения используйте:
define("DBPersistent", false);
Использование постоянных соединений может потребовать некоторой настройки Apache и MySQL. Убедитесь, что вы не превысите максимальное число дозволенных соединений. Читайте дополнительную информацию в документации PHP относительно используемой вами базы данных.
Работа с базами данных в Bitrix Framework
Какие проекты можно назвать большими?
Комплексное сочетание целого ряда факторов может привести к тому, что проект получает название «большой» и требует определенного конфигурирования и отношения:
-
большая посещаемость проекта в среднесуточном выражении;
-
высокие пиковые нагрузки;
-
невозможность кэшировать страницы в силу сложной бизнес-логики;
-
большие интерактивные проекты: форумы, блоги, журналы;
-
индивидуальные страницы для отдельных пользователей;
-
большие объемы данных;
-
недостаточность аппаратных ресурсов по отношению к предыдущим факторам.
Примечание: даже если у вас сравнительно небольшой проект, лучше настроить веб-сервер правильно, чтобы в случае неожиданного роста посещаемости, например, при рекламной кампании, сайт стабильно работал.
Почему умирают сайты?
Прежде чем переходить к выбору рекомендаций по конфигурированию, необходимо внимательнее изучить основные причины, которые приводят к нестабильной работе веб-сервера или даже к полному отказу в обслуживании. Четкое понимание причин позволит вам вдумчиво подходить к рекомендациям и максимально эффективно использовать все имеющиеся у вас аппаратные ресурсы.
Как работает веб-сервер
Рассмотрим типичную схему работы веб-сервера:

При запросе страницы сайта происходит обращение к веб-серверу, который запускает интерпретатор PHP для выполнения скрипта. Далее программа выполняется, взаимодействует с СУБД и отдает результат выполнения клиенту. Кроме того, веб-сервер отдает клиенту сопутствующие файлы – картинки, документы, css файлы и другую статическую информацию.
В современных сайтах при открытии каждой страницы клиенту отдается несколько десятков файлов – от действительно результата выполнения PHP программы до статических картинок.
Важно отметить, что для отдачи каждого файла используется, как правило, отдельный процесс Apache, который занимает память веб-сервера. В 2012 году средний размер процесса Apache в памяти – от 64 до 500 мб, и очень легко занять всю оперативную память процессами веб-сервера.
Узкие места
Выделим несколько узких мест в приведенной схеме:

- Передача данных клиенту. Решение проблем медленных каналов
- Производительность PHP. Уменьшение времени выполнения скрипта.
- Обмен с базой данных.
- Настройка СУБД на максимальную производительность
- Отдача статики. Решение проблемы медленных каналов.
Передача данных клиенту
Работа веб-сервера Apache организована таким образом, что процесс веб-сервера занимает память системы, пока полностью не завершит отдачу файла. Таким образом, в случае если у клиента медленный канал связи, то даже при быстром выполнении PHP скрипта сервер будет не справляться даже с маленькой нагрузкой.
Дополнительно, при отдаче статических файлов с помощью Apache ценная память веб-сервера используется расточительно – под выдачу статики, для обработки которой не требуется выполнять программы на PHP.
В течение всего времени передачи страницы клиенту веб-сервер будет держать в памяти практически бездействующий процесс Apache, который будет только дожидаться завершения передачи данных, но не сможет высвободить память и высвободиться сам, чтобы обработать другой запрос.
Очень часто администраторы не отдают себе отчет в том, насколько данный фактор влияет на стабильность системы и эффективное использование оперативной памяти.
Давайте сделаем простой расчет. Рассмотрим две системы: А и Б.
В системе А время генерации страниц составит 0.1 секунды, а время передачи страницы клиенту в среднем будет составлять всего 5 секунд (в реальной жизни среднее значение окажется еще больше). В системе Б мы будем считать время генерации страниц равным 0.1, а время передачи страницы пользователю равным нулю. Предположим, что на каждый сайт поступает по 100 запросов в секунду.
Система А
Обработка 100 запросов в секунду потребует одновременной работы 500 самостоятельных процессов веб-сервера. "Почему?" - спросите вы. А как же иначе, если даже обработав запрос за 0.1 с., наши процессы, получается, еще не способны обрабатывать другие запросы, а будут висеть в памяти и просто дожидаться, пока пользователи в течение 5 секунд будут получать страницу. На четвертой секунде веб-сервер получит еще 100 запросов и должен будет запустить еще 100 процессов. Соответственно, на пятой секунде в памяти должно находиться 500 процессов и только с этого момента процессы первой секунды начнут высвобождаться и обрабатывать новые запросы.
Таким образом, система А для нормальной работы будет запускать порядка 500 процессов, что потребует от нас в лучшем случае 32 Гб оперативной памяти. Обратите внимание, что даже если бы время генерации страниц было равно 0.001 секунды, это бы не увеличило производительность системы, так как процессы ожидают передачи данных пользователям на медленных каналах, а не времени генерации страниц. Т.е. производительность системы А никак не связана с производительностью PHP и продукта.
Система Б
За первую секунду на сервер поступит 100 запросов. Для обработки 100 запросов нам потребуется всего 10 процессов. Один процесс обрабатывает один запрос за 0.1 секунды. Как мы договорились для системы Б, время передачи страницы пользователю будет равно нулю. Т.е. за 1 секунду, один процесс веб-сервера способен обработать 10 запросов пользователей! К завершению первой секунды, все запросы будут обработаны всего 10 процессами и ко второй секунде все эти процессы будут свободны и готовы обрабатывать следующие запросы. Так же случится и на третьей секунде, и через час.
Таким образом, система Б для нормальной работы будет запускать всего 10 процессов, что потребует от нас порядка 640М оперативной памяти. И очень важно отметить, что уменьшение времени генерации страниц до 0.01 секунды позволит реально увеличить производительность системы в 10 раз, и нам будет достаточно уже только 1 процесса для обработки всех 100 запросов в секунду. Производительность системы Б зависит только от производительности PHP и продукта и не зависит от медленных каналов.
Это очень наглядный пример, который демонстрирует, насколько велико влияние медленных каналов пользователей на общую производительность веб-системы. Веб-сервер очень неэффективно расходует оперативную память на медленных каналах.
Немного забегая вперед отметим, что существуют методы, которые позволяют построить систему очень близкую к модели Б и полностью снять зависимость веб-системы от медленных каналов и увеличить производительность и устойчивость в несколько раз.
Производительность PHP, базы данных и статика
Рассмотрим остальные "узкие места".
Производительность PHP. Уменьшение времени выполнения скрипта.
До 60% рабочего времени веб-сервера тратят на повторную компиляцию PHP-кода перед исполнением. Ключевой способ снизить нагрузку на процессор – использовать прекомпиляторы PHP-кода, которые снижают нагрузку на систему за счет перевода PHP из интерпретируемого в частично компилируемый язык.
Обмен с базой данных
Если ваш проект работает на выделенном сервере, вы можете настроить взаимодействие с СУБД для уменьшения затрат времени на установку соединений. Для этого используется постоянные соединения с базой данных, что позволяет уменьшить общее время выполнения скрипта.
Настройка СУБД на максимальную производительность
Установки по умолчанию для большинства СУБД рассчитаны на некие средние величины. Для повышения производительности необходимо оптимизировать эти настройки.
Отдача статики. Решение проблемы медленных каналов.
Также как и при передаче данных клиенту, для повышения производительности хостинга необходимо решить вопрос с медленными каналами связи, но уже применительно к статической информации. Все сказанное для первого пункта применимо и для отдачи статики.
Причины "умирания" сайтов
Таким образом, при больших нагрузках проект может прекратить нормальное функционирование по следующим причинам:
- Нехватка оперативной памяти для нормальной одновременной работы процессов веб-сервера и базы данных. В большинстве систем на каждый запрос к сайту открывается отдельный процесс веб-сервера. Обычный размер процесса Apache с подключенным PHP-модулем и работающим приложением может составить порядка 64-500 мегабайт. В результате пиковых нагрузок происходит одновременный запуск очень большого числа процессов (иногда больше нескольких сотен процессов). И как следствие, начинается свопирование процессов, а это неизбежно сказывается на производительности базы данных, и производительность всей системы в целом резко снижается.
- Нехватка процессорных ресурсов для одновременного выполнения процессов и обеспечения адекватного для пользователя времени реакции. Данная ситуация может возникнуть в том случае, если в результате большого числа запросов к вашему серверу число одновременно выполняемых запросов превысит процессорные мощности сервера. И даже если у вас достаточно оперативной памяти и первая проблема не проявила себя, вы можете обнаружить, что система перестала адекватно отвечать на запросы, время выполнения страниц увеличилось в несколько раз, база данных перегружена очень большим числом запросов. Все это может привести к тому, что все без исключения пользователи не смогут работать с сервером.
- Недостаточная производительность базы данных при одновременных конкурентных запросах, невозможность полностью использовать ресурсы сервера. Данная ситуация очень часто возникает при работе с MySQL. Надо отметить, что обычно MySQL использует формат таблиц MyISAM. Это очень простой и эффективный вариант работы, но, к сожалению, при большом числе одновременных запросов такая база данных становится критически узким местом в производительности системы в целом. Во время вставки данных, обновления и некоторых других запросах, происходит эксклюзивное блокирование таблиц и, как следствие, все запросы выполняются только последовательно, а не одновременно. В результате, при росте нагрузки, время генерации страниц возрастает необоснованно резко и в итоге становится неприемлемо большим. Менее всего подвержены подобным проблемам проекты, использующие MySQL с форматом таблиц InnoDB.
- Общая несбалансированность веб-системы при пиковых нагрузках и быстрая регрессия производительности даже при незначительных стрессах. При пиковых нагрузках вся система испытывает перегрузки. В дополнение к перечисленным проблемам возможно возникновение проблем в дисковой подсистеме. В итоге, если под одной из составляющих начинается потеря производительности, то существенно падает производительность всей системы, начинается падение производительности в других частях и, в итоге, еще больше снижается работоспособность, производительность системы регрессирует и иногда наступает полная остановка в работе.
Двухуровневая конфигурация веб-сервера Front-End и Back-End
Наилучшим способом для устранения перечисленных проблем является создание двухуровневой системы Front-End + Back-End для обработки запросов.
Front-End – публичная часть проекта, обеспечивающая прием запросов от пользователей, трансляцию запросов к Back-End и выдачу непосредственного содержимого пользователю.
Back-End – исполнительная часть системы, которая обеспечивает выполнение PHP-скриптов, формирование контентных страниц и работу бизнес-логики приложений.
Рассмотрим пример конфигурации более детально. После применения оптимизации у нас должна получиться система примерно следующего вида:

Front-end
Что использовать?
Начнем с построения Front-end системы и определения целей и задач, которые будет решать данная часть двухуровневой архитектуры.
В качестве Front-End сервера можно использовать NGINX, SQUID, OOPS или любой аналогичный продукт.
NGINX представляет собой очень компактный и быстрый веб-сервер (HTTP-сервер). Он потребляет очень мало оперативной памяти, умеет самостоятельно обслуживать статические запросы и выполнять акселерированное проксирование без кэширования статических объектов. Например, если запрашивается графический объект, NGINX самостоятельно выполняет считывание данных с диска и передает файл пользователю.
SQUID и OOPS - это классические прокси-сервера, которые выполняют проксирование запросов и чаще всего кэшируют статические запросы, сохраняя в кеше или у себя на диске копии статических запрашиваемых объектов в течение определенного интервала времени.
Наилучшие практические результаты получены при использовании NGINX. Но использование кэширующих прокси-серверов также возможно с получением отличных результатов.
Двухуровневая архитектура выставляет перед пользователем Front-end легкий веб или прокси-сервер, который принимает все запросы от пользователей, исполняет все запросы, которые возможно обработать самостоятельно без обращения к Back-End. Если используется NGINX или аналогичный продукт, все статические объекты напрямую считываются с диска и передаются клиенту. Если используется кэширующий прокси-сервер, статические объекты, графические файлы и таблицы стилей запрашиваются с Back-end только при первом обращении к ним. После этого файлы хранятся в кэш Front-end в соответствии с политикой кэширования и отдаются пользователям без обращения к Back-end.
Цели и задачи
Основные цели, которых мы добиваемся созданием первого Front-end уровня:
- минимизация числа запросов, поступающих к Back-end веб-серверу. Надо добиться ситуации, когда Front-end будет обращаться к Back-end процессам только для получения содержимого PHP-страницы. Все запросы к статическим объектам должны обрабатываться легкими процессами Front-end самостоятельно или при использовании кэширующего прокси-сервера на всех запросах, кроме первого.
Совет: проверьте лог Back-end веб-сервера, чтобы убедиться, что вы настроили все правильно и действительно исключили лишние запросы. В логе должны быть представлены только страницы PHP, другие запросы не должны проходить к Back-end системе и не будут отражаться в лог файле.
- минимальное потребление оперативной памяти при обработке статических запросов. Число статических запросов существенно превосходит число запросов к PHP-страницам. Процессы Front-end потребляют в среднем 2-5М оперативной памяти и очень незначительно увеличиваются при обработке статических документов. Это позволяет в разы уменьшить потребление оперативной памяти всей системой в целом.
- защита системы от фактора медленных каналов. Как для статических запросов, так и для HTML-страниц, полученных от PHP-процессов Back-end веб-сервера, процессы Front-end могут передавать страницу пользователю достаточно долго, потребляя при этом очень мало оперативной памяти. Таким образом, Front-end, транслируя запрос к Back-end, получает ответ, высвобождает процессы Back-end для обработки других запросов, а сам передает страницу пользователю, снимая фактор медленных каналов. Система приближается к идеальной системе Б в примере, приведенном в уроке Передача данных клиенту.
Внимание! Убедитесь, что буферы Front-end достаточны, чтобы без ожидания на передаче принять от Back-end всю страницу. То есть фактически буфер в идеале должен быть равен размеру самой большой страницы у вас на сайте.
- механизм защиты Back-end от большого числа запросов за счет ожидания свободных процессов Back-end для продолжения работы. Проверьте и убедитесь, что Front-end будет ожидать 5-10-15 минут, пока не высвободятся процессы Back-end. Наличие такого механизма позволит нам настроить Back-end так, чтобы полностью стабилизировать систему и подготовиться к стрессовым нагрузкам.
Как вы видите, появление Front-end позволяет нам снять целую категорию рисков и подготовить систему к дальнейшей работе
Внимание! Если вы используете кэширующий прокси-сервер в качестве Front-End, обязательно настраивайте время кэширование документов. Графические файлы и таблицы стилей, XML-файлы и другие статические объекты с веб-сервера должны запрашиваются только в соответствии с политикой кэширования. После этого файлы хранятся в прокси-сервере и отдаются пользователям без обращения к Back-End и
Apache. Рекомендуется настраивать время кэширования для графических файлов на 3-5 дней. Пример настройки кэширования через файл
.htaccess в корне веб-сервера:
ExpiresActive on
ExpiresByType image/jpeg "access plus 3 day"
ExpiresByType image/gif "access plus 3 day"
Для работы этого примера необходимо, чтобы веб-сервер позволял переопределение переменных через файл .htaccess и модуль mod_expires был установлен. В некоторых случаях на Front-end политика кеширования настраивается независимо от настроек Back-end.
Таким образом, Front-end будет кешировать все графические изображения. Запросы к контентным страницам не будут кешироваться и будут перенаправляться к Back-end.
Back-end и порядок взаимодействия
Back-end
Back-end представляет собой обычный веб-сервер Apache, который исполняет PHP-приложения.
Back-end готов исполнять запросы на графические и статические документы, если вы используете кэширующий прокси-сервер для Front-end. Но очень важно, чтобы число запросов к статическим элементам через Back-end было минимальным и 99% запросов приходилось на выполнение именно PHP-страниц. Не забывайте, что использование Back-end для обработки статических запросов обходится очень дорого.
Конфигурируя Back-end, можно добиться значительного выигрыша в производительности и стабилизировать систему по расходу памяти. В большинстве случаев Back-end представляет собой обычный веб-сервер Apache, работающий на нестандартном порту, к примеру, на порту 88 и отвечающий только на запросы с localhost или IP адреса Front-end.
Совет администратору: Лучше использовать несколько внутренних IP адресов типа 127.0.0.2, 127.0.0.3 и т.д. с 80-м портом, иначе возможны нежелательные редиректы на неработающий порт у Front-end.
Процесс взаимодействия
Рассмотрим процесс взаимодействия Front-End и Back-End при обработке запроса пользователя к обычной странице сайта.
- Запрос от пользователей принимается Front-end, например, по адресу http://www.1c-bitrix.ru/ на 80 порту. На нашем сайте мы используем NGINX в качестве Front-end.
- Запрос принимается и транслируется к Back-end (веб-сервер Apache с PHP), который обрабатывает запросы по адресу http://127.0.0.2:80/.
- Запрос исполняется Back-end веб-сервером, отрабатывает программный продукт на PHP и генерируется HTML-текст страницы для пользователя.
- Подготовленная HTML-страница от Back-end передается Front-end как ответ на запрос пользователя, соединение между Front-end и Back-end закрывается (желательно не использовать KeepAlive на Back-end), и процесс Back-end высвобождает оперативную память или начинает обработку другого запроса.
- Front-end передает готовую сформированную страницу посетителю столько времени, сколько требуется пользователю, даже если он работает на медленном канале. Потребление памяти Front-end для передачи страницы пользователю минимально.
- Получив страницу, браузер посетителя посылает последовательно серию запросов на графические элементы и таблицу стилей. Все запросы принимаются Front-end и обрабатываются без обращений к Back-end, т.е. все статически документы самостоятельно вычитываются с диска без использования медленных и дорогих процессов Back-end.
Пример уменьшения объема памяти
Пример уменьшения объема занимаемой оперативной памяти и числа процессов при подключении Front-end сервера (без настройки на отдачу статических файлов).
В этом примере был подключен NGINX, который все запросы, в том числе и запросы к статике, передавал back-end (Apache). Никаких дополнительных настроек на Back-end не выполнялось. Время подключения nginx – 12:50.
Используемая веб-сервером память:

Число одновременно выполняемых процессов Apache:

Как показала практика, двухуровневая конфигурация Front-end + Back-end существенно разгружает машину, уменьшает объемы потребляемой памяти, значительно ускоряет время обработки запросов и позволяет больше памяти выделить для работы базы данных. Такая конфигурация также позволяет значительно разгрузить сервер при обработке большого числа статических файлов, например, музыки, дистрибутивов программных продуктов, презентаций и других схожих объектов. Например, простым подключением NGINX удалось снизить нагрузку на веб-сервер в 5 раз.
Стабилизируем Back-end по расходу оперативной памяти
Стрессовые нагрузки
Даже создав двухуровневую конфигурацию, очень важно стабилизировать системы по расходу памяти независимо от нагрузки и защитить сервер от перегрузки.
Для стабилизации системы по расходу памяти и минимизации числа запущенных процессов Back-end мы рекомендуем в настройках сервера Apache установить параметр MaxClients в значении от 5 до 50, в зависимости от объема оперативной памяти. Значение этого параметра не должно превышать 80% от объема доступной памяти сервера за вычетом памяти, выделенной под СУБД. Устанавливая MaxClients, вы ограничиваете возможное число одновременно запущенных процессов Back-end. Тем самым, удается поставить жесткий лимит по потреблению памяти и исключить выход машины из строя при стрессовых нагрузках.
Пример поведения сервера при неправильно установленном MaxClients
Зависание сервера при слишком большом значении MaxClients:

На приведенном скриншоте произошло следующее:
Запущена команда top в Linux, показывающая объем занятой и свободной памяти, число выполняющихся процессов и объем памяти, занимаемый ими. В данном примере достаточно посещаемый веб-сайт работал на мощном сервере с двумя 4-х ядерными процессорами и 5 Гб оперативной памяти. Размер swap-файла – 4 Гб.
MaxClients был установлен в 100. Каждый процесс Apache занимал около 250 Мб, что привело к полному исчерпанию и оперативной памяти, и файла подкачки на 40 процессах Apache. В связи с отсутствием доступной памяти процессоры сервера не смогли справиться с нагрузкой и сервер зависал.
Таким образом, число MaxClients необходимо подбирать, исходя из системных ресурсов и нагрузки.
Методика подбора параметра
Методика подбора может быть следующей. Посчитайте, сколько памяти у вас занимает один Back-end процесс. Например, 50 Мб. Если мы установим MaxClients равным 4, значит максимальное потребление памяти может составить 200 Мб. Для машины с 512 Мб оперативной памяти MaxClients желательно выбрать между 5-10. Для правильной конфигурации Front-end, когда вся статика обрабатывается без участия Back-end, это позволит вполне комфортно обрабатывать порядка 50 тысяч хитов в сутки или примерно 10-20 тысяч уникальных пользователей.
Для крупных проектов с конфигурациями из двух машин или при наличии больших объемов памяти рекомендуется производить выбор значения MaxClients в процессе нагрузочного тестирования.
Важно! Подбирайте MaxClients так, чтобы система при стрессовых нагрузках потребляла не более 90% процессорных ресурсов и никогда не доходила до 100%. Это позволит вам стабилизировать использование процессорных ресурсов и быть уверенным, что не начнется общая регрессия по производительности во время пиковых нагрузок.
Обратите внимание, что очень важно настраивать время ожидания для Front-end таким образом, чтобы при отсутствии свободных процессов в Back-end, Front-end ожидал освобождения ресурсов. Тем самым организуется очередь запросов, и Back-end защищается от перегрузки.
Так же рекомендуется подбирать параметры управления процессами Back-end в соответствии с установленным лимитом MaxClients. Например, если MaxClients = 5, тогда рекомендуется установить:
MinSpareServers 5
StartServers 5
MaxClients 5
Т.е. это означает, что при старте сервера сразу будет запущено столько процессов Back-end, сколько максимально возможно соединений. Процессы никогда не будут выгружаться из памяти и будут готовы в любой момент принять и обработать запрос от Front-end. При запуске системы мы с вами сразу увидим объем используемой Back-end оперативной памяти, что позволит остальную память распределить для базы данных.
Совет! Рекомендуется для начала выбирать минимальное значение
MaxClients, например, 5. В процессе работы проекта проверять время исполнения страницы. Если на быстром канале наблюдается ситуация, когда время выполнения страницы (параметр
?show_page_exec_time=Y
) в пиковые моменты показывает стабильно минимальное значение, а визуально мы наблюдаем существенную задержку перед открытием страницы, то это может свидетельствовать о нехватке процессов Back-end. Иными словами о том, что запросы принимаются Front-end и долго удерживаются в ожидании высвобождения Back-end процессов.
В этом случае можно рекомендовать увеличить MaxClients, но обязательно с учетом общего баланса системы по расходу памяти.
MaxClients и базы данных
Еще одно преимущество использования MaxClients связано с базами данных.
Наличие лимита позволяет включить постоянное соединение к базе данных (только если у вас свой сервер с 1-2-я проектами) и уменьшить время соединения с базой данных и число работающих процессов базы данных. Если величина параметра MaxClients меньше или равна максимальному числу соединений с базой данных, то это гарантирует, что никогда не будет запущено больше этого числа процессов Back-end. Следовательно к базе данных не будет открыто больше соединений. Фактически, всегда в памяти будут находиться MaxClients загруженных процессов Back-end с открытыми соединениями к базе данных, готовые к обработке запросов.
Внимание! Практика показывает, что администраторы поверхностно относятся к данной рекомендации и не устанавливают лимиты или устанавливают их необоснованно большими. Это приводит к полному дисбалансу двухуровневой системы и потере стабильности при больших нагрузках (см. рисунок выше).
Еще раз подчеркнем, что соблюдение этих рекомендаций позволяет:
- Стабилизировать конфигурацию по расходу памяти при любых нагрузках;
- Защитить сервер от процессорных перегрузок и общей регрессии производительности;
- Безопасно использовать постоянное соединение к базе данных.
Производительность PHP
PHP прекомпиляторы
Важно! До 60% рабочего времени веб-сервера тратят на повторную компиляцию PHP-кода перед исполнением.
Ключевой способ снизить нагрузку на процессор – использовать прекомпиляторы PHP-кода. В настоящее время поддерживается акселератор OPcache (рекомендуется, доступен сразу «из коробки» в PHP v.5.5+).
Не забывайте выделять достаточный объем оперативной памяти для хранения разделяемого кэша скомпилированных PHP-файлов. Обычно бывает достаточно 32-64 Мб, но для уверенности можно увеличить объем выделяемой памяти до 128 Мб, в расчете на файлы административного раздела. Прекомпиляторы используют разделяемый кэш для хранения скомпилированного PHP кода в оперативной памяти, который доступен всем рабочим процессам веб-сервера, при этом скомпилированный PHP код хранится в кэше в единственном экземпляре (без дублирования).
Для уменьшения потребляемой памяти процессами веб-сервера, в котором запускается PHP, желательно исключить из компиляции или динамической загрузки все неиспользуемые модули.
При этом очень важно, чтобы в кэш прекомпилятора помещалось достаточное количество скриптов на PHP. Одна из самых часто встречающихся ошибок - это отсутствие каталога для сохранения откомпилированного кода.
Для ускорения работы с PHP-сессиями рекомендуется сохранять файлы сессий в каталоге, который представляет собой виртуальный диск в памяти или использовать установку session.save_handler=mm
в php.ini. Если есть возможность, рекомендуется использовать системный RAM диск. При этом необходимо отключать опцию Передавать пароль в зашифрованном виде на закладке Авторизация страницы настроек Главного модуля.
Панель производительности
Важным инструментом по настройке производительности PHP является модуль Монитор производительности, входящий в комплект всех продуктов "1С-Битрикс". Протестировать настройки системы можно в административной части на странице Панель производительности (Настройки > Производительность > Панель производительности). Неоптимальная конфигурация PHP:

Как правило, выполнение рекомендаций позволяет увеличить производительность системы до достаточных величин. Численное значение параметра Конфигурация показывает основную характеристику сайта – скорость отдачи страниц клиенту. Чем больше число, тем лучше.
Некоторые типовые ошибки
Ошибка Segmentation fault может произойти:
- В результате "падения" РНР при использовании отложенной загрузки классов;
- При использовании Zend server могут "упасть" скрипты в cron или консоли.
В первом случае необходимо определить в dbconn.php:
define("NO_BITRIX_AUTOLOAD",true)
Во втором случае надо:
Сжатие страниц
Компрессия при передаче данных между сервером и клиентом обеспечивает сжатие страниц для ускорения вывода содержания сайта пользователям.
Сжатие в несколько раз уменьшает объем передаваемых HTML-данных между сайтом и браузером клиента, что существенно увеличивает скорость работы как для посетителей, так и для администраторов сайта.
Предпочтительнее сжимать страницы на Front-End. При отсутствии такой возможности можно сжимать данные на Back-End.
Возможные способы:
- mod_deflate;
- модуль [dw]Компрессии[/dw][di]Начиная с версии main 20.0.1300 модуль Компрессия удалён из продукта. Рекомендуется настроить сжатие контента в веб-сервере.[/di], входящий в продукты "1С-Битрикс";
- стандартные модули PHP;
- стандартные модули Apache.
Для исключения излишнего расходования процессорных ресурсов рекомендуется применять сжатие только на одном уровне. Например, при использовании сжатия Front-end сервером рекомендуется не использовать сжатие на уровне Apache и отключить модуль компрессии "1С-Битрикс: Управление сайтом".
Дополнительные рекомендации для двухуровневой конфигурации
По умолчанию, при работе в двухуровневой конфигурации, в качестве адреса клиента будет указываться адрес, на котором работает NGINX или другой акселератор. Для правильной работы модуля статистики необходимо обеспечить передачу реального IP адреса с Front-end в Back-end.
Например, для NGINX используется следующая технология: сервер NGINX устанавливает специальный заголовок в запросе, а специальный модуль Apache (rpaf или real_ip) учитывает этот заголовок вместо стандартного.
Если же такой модуль не установлен, то вы можете сами изменить адрес клиента. Например, если адрес клиента передается в переменной HTTP_X_FORWARDED_FOR
(так делает прокси-сервер SQUID) или HTTP_X_REAL_IP
, то для замены переменной в продукте необходимо в файле /bitrix/php_interface/dbconn.php вставить подобный пример кода:
if(isset($_SERVER['HTTP_X_FORWARDED_FOR']) || isset($_SERVER['HTTP_X_REAL_IP'])) {
foreach(array('HTTP_X_FORWARDED_FOR', 'HTTP_X_REAL_IP') as $key => $value) {
if(
isset($_SERVER[$value])
&& strlen($_SERVER[$value]) > 0
&& strpos($_SERVER[$value], "127.") !== 0
) {
if($p = strrpos($_SERVER[$value], ","))
{
$_SERVER["REMOTE_ADDR"] = $REMOTE_ADDR = trim(substr($_SERVER[$value], $p+1));
$_SERVER["HTTP_X_FORWARDED_FOR"] = substr($_SERVER[$value], 0, $p);
}
else
$_SERVER["REMOTE_ADDR"]= $REMOTE_ADDR = $_SERVER[$value];
break;
}
}
}
Кроме того, в конфигурации Apache на Back-end желательно отключить KeepAlive
. Поскольку Front-end находится или на этой машине, или "рядом", более быстрое высвобождение ресурсов предпочтительнее.
Достигнутые результаты
В результате построения двухуровневой архитектуры и выполнения ряда рекомендаций мы должны получить следующие результаты:
- система стабилизирована по расходу памяти; Front-End и Back-End занимают заранее отведенный объем памяти, который не будет расти даже при увеличении нагрузки;
- в стрессовой ситуации система будет стабильно и равномерно обрабатывать запросы, Back-end не будет увеличивать число одновременно выполняемых процессов выше установленного лимита MaxClients, Front-end будет принимать все запросы от пользователей и ожидать освобождения процессов Back-end;
- использование процессорных ресурсов ограничено числом одновременно работающих процессов Back-end в соответствии с MaxClients, не начнется регрессия производительности;
- возможно безопасное использование постоянного соединения с базой данных без опасения превысить число возможных соединений; в памяти все время находится установленное число Back-end процессов, готовых к обработке запросов и с установленным соединением с базой данных;
- процессорные ресурсы существенно высвобождены за счет прекомпиляции PHP-кода;
- пользователи комфортно работают со сжатыми страницами.
Пример настройки двухуровневой архитектуры
В качестве примера рассмотрим конфигурацию виртуальной машины VMBitrix. В состав конфигурации входят:
- Веб-сервер Apache в качестве Back-end
- NGINX в качестве Front-end
- Zend Server CE в качестве настроенного модуля PHP (с прекомпилятором)
- Дополнительные настройки СУБД MySQL и других параметров сервера.
Для рассмотрения и управления настройками перейдите в консоль виртуальной машины или подключитесь к ней через ssh или sftp.
Настройка веб-сервера Apache
Конфигурационные файлы
Основным конфигурационным файлом веб-сервера является /etc/apache2/apache2.conf
(в других системах файл может называться /etc/httpd/httpd.conf
). Далее, подключается файл с настройкой портов прослушивания для веб-сервера и другие файлы. Иногда это все размещается в одном файле, иногда (как в виртуальной машине – в разных).
Рассмотрим основные параметры этих файлов.
/etc/apache2/apache2.conf
Timeout 300 #если 300 секунд не происходит никаких операций, завершить процесс
KeepAlive Off #все запросы у нас короткоживущие
User ${APACHE_RUN_USER} #пользователь, под которым работает веб-сервер
Group ${APACHE_RUN_GROUP} #группа, под которой работает веб-сервер
/etc/apache2/ports.conf
Listen *:8888 #веб-сервер работает на порту 8888
/etc/apache2/envvars
Осуществляется установка переменных окружения – пользователя и группы.
export APACHE_RUN_USER=bitrix
export APACHE_RUN_GROUP=bitrix
/etc/apache2/conf.d/prefork
Осуществляется настройка числа процессов сервера.
#работает с этим расширением
StartServers 4 #4 одновременных сервера
MinSpareServers 4
MaxSpareServers 4
MaxClients 4 #4 одновременных клиента
MaxRequestsPerChild 200 #после 200 запросов перезапускать процесс
Таким образом, настройки веб-сервера достаточно простые. Фактически, в стандартной конфигурации достаточно изменить только порт, на котором работает веб-сервер и параметр MaxClients и связанные с ним.
Некоторые ключевые моменты настройки
Для конфигурации используются нестандартные порты. Например, 192.168.1.1:8888. В этом случае можно обращаться к Apache снаружи мимо фронтенда и проверить его работу. Это достоинство способа. И могут возникнуть лишние редиректы. Это ограничение способа, которое, впрочем, обходится.
Либо использовать внутренние адреса на стандартных портах. Например, 127.0.0.2:80. Нельзя будет обращаться снаружи мимо фронтенда, но зато нет проблем с редиректами.
Ограничение процессов (StartServers) зависит от параметров системы. Разумное число - 20-30 процессов, точнее надо вычислять. Посмотрите сколько памяти у вас может занять один процесс, поделите общее количество памяти на размер одного процесса, это даст примерное число процессов.
По логам проверяйте, что бы вся статика отдавалась Frontend'ом. В логах не должно быть обращений к статическим файлам: gif, jpg, css и подобным.
Пример: число процессов веб-сервера
Как определить максимальное число процессов веб-сервера? Естественно, только опытным путем. При этом начальное значение можно подобрать достаточно просто - нужно посмотреть, сколько занимает процесс apache во время типового обращения к сайту:
- Зайдите в Linux и запустите команду
free
. Она покажет вам общий размер оперативной памяти и свободный размер:
# free
total used free shared buffers cached
Mem: 255676 224340 31336 0 33468 67964
-/+ buffers/cache: 122908 132768
Swap: 530136 51800 478336
В примере показано, что в системе ~256 Мб памяти, ~500 Мб swap (виртуальная память на диске). Системной памяти занято ~120 мб, вся неиспользуемая память отдана под файловый кэш
- Наберите команду
top
- Откройте любую страницу сайта, параллельно смотря значение в программе top. Вверху появится процесс с названием apache2:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14687 bitrix 20 0 153m 45m 28m R 6.7 18.2 0:05.34 apache2
В этом примере столбец RES как раз и показывает примерное количество памяти, выделяемое на один процесс. Таким образом, для типового сайта на "1С-Битрикс: Управление сайтом" - это около 50 Мб. Соответственно, параметр MaxClients выбран 4 исходя из соображения, что должна остаться память под операционную систему и работу СУБД.
Из этого примера видно, что для достаточно посещаемого сайта (не интернет-магазина) минимальные требования по памяти для веб-сервера (или VPS) – от 512 Мб. Для интернет-магазина с обменом с 1С минимальный объем памяти на сервере или VPS должен быть не менее 1 Гб.
Настройка Front-end NGINX
Конфигурационный файл
Каталог с конфигурацией NGINX - /etc/nginx
. Рассмотрим его конфигурационный файл /etc/nginx/nginx.conf
:
user bitrix; #пользователь, под которым работает nginx. Желательно совпадение с пользователем apache
worker_processes 8; #8 одновременных процессов
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
worker_rlimit_nofile 10240; #максимальное число открытых файлов
events {
use epoll;
worker_connections 10240; #максимальное число соединений с одним процессом. Система может одновременно работать с max_clients = worker_processes * worker_connections, т.е. с 81920 соединений, в том числе статических файлов
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
#формат логов
log_format main '$remote_addr - $remote_user [$time_local] $status'
'"$request" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
log_format common '$remote_addr - - [$time_local] "$request" $status $bytes_sent "$http_referer" "$http_user_agent" $msec';
access_log /var/log/nginx/access.log common;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
client_max_body_size 10m; # максимально допустимый размер тела запроса клиента, указываемый в строке "Content-Length" в заголовке запроса
client_body_buffer_size 128k;
proxy_connect_timeout 300; #время на ожидание соединения
proxy_send_timeout 300;
proxy_read_timeout 300;
proxy_buffer_size 64k;
proxy_buffers 8 64k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 10m;
gzip on; #сжимать передаваемые данные
gzip_proxied any;
gzip_types application/x-javascript text/css;
server { #виртуальный хост
listen 80; #порт 80
server_name bitrix; #адрес узла. Если узел всего один – можно написать любой
server_name_in_redirect off; #лучше поставить в ON – передавать запрошенное имя сайту
access_log /var/log/nginx/access.log common;
index index.php;
error_page 500 502 503 504 /500.html;
error_page 404 = /404.php;
#установить дополнительные заголовки для определения адреса клиента в статистике сайта
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host:80;
client_max_body_size 1024M; #максимальный размер передаваемого файла
client_body_buffer_size 4M;
root /var/www; #корневая папка сайта
#включить https режим при нахождении в корне сайта файла .htsecure
if (-f /home/bitrix/www/.htsecure) {
rewrite ^(.*)$ https://$host$1 permanent;
}
#выбрать, какие данные пересылать backend серверу, а какие – показывать напрямую
#в данной конфигурации все пересылается backend серверу
#обилие вариантов потребовалось компании Битрикс для того, чтобы при добавлении в конфигурацию отдачу статических файлов напрямую через NGINX динамические запросы на псевдостатические файлы все-таки перенаправлялись на backend
location / { expires 3d;
if ($request_method = OPTIONS ) {
proxy_pass http://127.0.0.1:8888;
}
if ($request_method = PROPFIND ) {
proxy_pass http://127.0.0.1:8888;
}
if ($request_method = PROPPATCH ) {
proxy_pass http://127.0.0.1:8888;
}
if ($request_method = MKCOL ) {
proxy_pass http://127.0.0.1:8888;
}
if ($request_method = COPY ) {
proxy_pass http://127.0.0.1:8888;
}
if ($request_method = MOVE ) {
proxy_pass http://127.0.0.1:8888;
}
if ($request_method = LOCK ) {
proxy_pass http://127.0.0.1:8888;
}
if ($request_method = UNLOCK ) {
proxy_pass http://127.0.0.1:8888;
}
}
location ~ ^(/extranet/docs|/docs|/workgroups|/company/profile|/bitrix/tools|/company/personal/user).*/$ {
proxy_pass http://127.0.0.1:8888;
}
location ~ ^(/extranet/docs|/docs|/workgroups|/company/profile|/bitrix/tools|/company/personal/user) {
if (-d $request_filename) {
rewrite ^(.*)(/*)$ $1/ last;
}
proxy_pass http://127.0.0.1:8888;
}
location ~ ^(/bitrix/html_pages)
{
root /var/www;
index index@.html;
if (!-f $request_filename)
{
rewrite ^/bitrix/html_pages(.*)@(.*)\.html$ $1.php?$2 break;
rewrite ^/bitrix/html_pages(.*)\.html$ $1\.php break;
proxy_pass http://127.0.0.1:8888;
}
}
location ~ \.php$ {
root /var/www;
if ($request_method = POST ) {
break;
proxy_pass http://127.0.0.1:8888;
}
if ($http_cookie !~ "PHPSESSID=" ) {
rewrite ^(.*)\.php$ /bitrix/html_pages$1@$args.html? last;
}
proxy_pass http://127.0.0.1:8888;
}
location ~ /$ {
root /var/www;
if ($request_method = POST ) {
break;
proxy_pass http://127.0.0.1:8888;
}
if ($http_cookie !~ "PHPSESSID=" ) {
rewrite ^(.*)/$ /bitrix/html_pages$1/index@$args.html? last;
}
proxy_pass http://127.0.0.1:8888;
}
location ~ (/|\.php|\.asmx|/rest.*)$ {
proxy_pass http://127.0.0.1:8888;
}
location ~ /\.ht {
deny all;
}
location ~ /favicon.ico {
proxy_pass http://127.0.0.1:8888;
}
location ~ ^(/bitrixsetup\.php)$ {
proxy_pass http://127.0.0.1:8888;
proxy_buffering off;
}
}
#аналогичная конфигурация для https (удалена)
}
В данной конфигурации настройка NGINX проведена так, что все обращения к серверу будут перенаправляться на Back-end сервер. Однако, можно избранные файлы отдавать через NGINX. В этом случае будет достигнуто дополнительное увеличение производительности.
Некоторые нюансы настройки
# cat /proc/cpuinfo | grep "processor" | wc -l
worker_processes 8;
Регулируем размер очереди, который мы можем обрабатывать worker_processes. Сами разработчики NGINX рекомендуют выбирать число в соответствии с числом процессоров в системе.
# max_clients = worker_processes * worker_connections
events {
use epoll;
worker_connections 10240;
}
worker_connections - сколько запросов одновременно может обрабатывать один процесс. NGINX легкий и надёжный. Он способен выдержать такое число. В результате общее число коннектов, которые будут обрабатываться - это значение worker_processes умноженное на значение worker_connections.
# больше - больше памяти, меньше - чаще пишем на диск
client_body_buffer_size 4m;
client_body_buffer_size отвечающий за то как часто будет производиться запись на диск (а не держать из в памяти) при загрузке пользователями каких-то данных на сервер. При достаточно большой памяти можно установить это значение побольше, чтобы реже писать на диск и слегка разгрузить систему.
# максимально быстро получаем ответ от бэкенда
proxy_buffering on;
Включение proxy_buffering позволяет облегчить работу с клиентами с медленными каналами. Такие клиенты будут медленно соединяться с NGINX, медленно от него получать данные. Но сам frontend данные с backend'а получает быстро и не загружает веб-сервер.
gzip on;
gzip_proxied any;
gzip_static on;
gzip_types application/x-javascript text/css;
gzip_min_length 1100;
Обязательно включайте сжатие статики, что также ускорит отдачу данных.
Дополнительную информацию по настройке NGINX вы можете получить на сайте www.nginx.ru и wiki.nginx.org.
Отдача графики напрямую NGINX
Для того, чтобы графические файлы отдавались напрямую NGINX, вам необходимо добавить в конфигурацию сервера строки, подобные этим:
location ~* \.(jpg|jpeg|gif)$ {
root /var/www;
access_log off;
expires 3d;
}
В приведенном примере все файлы с расширением jpg, jpeg или gif будут считываться напрямую NGINX, причем корневой папкой для хранения файлов будет /var/www
.
Оптимизация базы данных
Оптимизация работы с базой данных MySQL является одной из важнейших стратегий в оптимизации системы в целом.
У каждого производителя базы данных есть целый раздел в документации, который посвящен вопросам производительности и оптимизации её работы.
Вы должны понимать, что типовая поставка базы данных обычно подразумевает минимальное серверное оборудование, минимальную память и диски. Т.е. стандартные конфигурации не учитывают возможности вашего оборудования и вашего приложения. Вы обязательно должны настраивать базу данных для обеспечения оптимальной работы.
Основные принципы
Если кратко попробовать сформулировать стратегию оптимизации, то прозвучит это примерно так:
- как можно меньше дисковых операций чтения данных; старайтесь увеличивать размер буфера кэширования, чтобы база данных как можно меньше читала данные с диска;
- как можно меньше сортировок данных на диске; старайтесь увеличить буфер сортировки таким образом, чтобы избежать двойных сортировок и сортировок на диске.
- увеличивайте параллельность исполнения запросов за счет запуска большого числа процессов базы данных, выбора форматов хранения данных, обеспечивающих параллельность работы;
- отложенная фиксация транзакций на диске; очень желательно настроить базу данных так, чтобы при изменении данных или их вставке не производилась немедленная запись на диск, а изменения собирались и фиксировались с некоторым интервалом; это позволяет значительно быстрее возвращать управление продукту после выполнения SQL запросов.
Примечание: Надо отметить, что при этом несколько снижается надежность. В случае сбоя системы те данные, которые еще не "сброшены" на диск, будут потеряны.
Давать конкретные рекомендации по настройке базы данных достаточно сложно, так как сервер базы данных - это сложное приложение и вам обязательно нужно проконсультироваться с документацией поставщика по вопросам настройки.
Но стоит отметить особое преимущество, которое мы получили в результате создания двухуровневой конфигурации. Созданная нами система сбалансирована по расходу оперативной памяти, и мы точно знаем свободный объем памяти и можем безопасно для системы использовать эту память для конфигурирования базы данных. В большинстве систем порядка 60-80% оперативной памяти удается выделить для базы данных и это позволяет значительно ускорить работу всей системы в целом.
Постоянное соединение с базой данных
Важным параметром, влияющим на потребление памяти базой данных MySQL, является максимальное число одновременных соединений, определяемое параметром max_connections
(для старых установок с БД Oracle – это параметр processes
).
При использовании двухуровневой архитектуры Front-end/Back-end можно в несколько раз уменьшить число одновременных соединений и высвободить больше памяти для сортировки данных в памяти и буферизации.
Если установлено число MaxClients в настройках веб-сервера Back-end, можно считать, что максимальное число соединений к базе данных будет соответствовать максимальному числу одновременных соединений.
Рекомендуется подбирать параметр max_connections
таким образом, чтобы иметь резерв в 10-20% свободных соединений от максимального значения.
Настройка базы данных MySQL
InnoDB или MyISAM?
Оптимизация работы с базой данных для MySQL-версии продукта является одной из важнейших стратегий в оптимизации системы в целом, так как продукт активно работает с базой данных.
Простой формат данных MyISAM хранит каждую таблицу с данными или индекс в отдельном файле. В целом, на небольших по нагрузке сайтах данный формат является наиболее быстрым, хотя и не обеспечивает полной целостности и надежного хранения данных за счет отсутствия транзакций.
Основным недостатком MyISAM с точки зрения производительности является блокировка на уровне таблицы при выполнении тех или иных операций. В результате, при большой нагрузке MySQL именно MyISAM таблицы становятся основным узким местом в системе, мешая увеличивать утилизацию машины и число обрабатываемых запросов. Это также приводит к увеличению времени работы страницы за счет ожидания используемых таблиц на уровне MySQL.
Рекомендуется переводить все таблицы проекта в формат данных InnoDB. Формат InnoDB, начиная с версии MySQL 4.0, входит в стандартную поставку продукта и обеспечивает надежное хранение данных, транзакционность и блокирование данных на уровне строки.
Два важных момента, которые дают основание предпочесть таблицы InnoDB перед MyISAM:
- Надежность. В MyISAM высока вероятность сбоя таблиц, особенно больших, особенно при высокой посещаемости, особенно часто изменяемых. Есть риск потерять несколько (десятков, сотен) записей и целостность данных. В InnoDB чинить отдельные таблицы не придется. Если упадет, так все сразу. Но на практике это - исключительное явление, практически не встречаемое. Благодаря транзакционности, риск нарушения целостности минимальный.
Недостатки InnoDB: нужно внимательно следить за свободным местом на диске; накапливающаяся фрагментация данных (лечится периодическим переводом таблиц из InnoDB в MyISAM и обратно).
- Скорость. На невысокой посещаемости MyISAM ведет себя быстрее, как на модификацию, так и на чтение. Однако, при росте посещаемости достаточно быстро сказывается отсутствие транзакций и блокировка на уровне таблиц. При некоторой величине посещаемости проект просто реально умирает. В InnoDB запись будет медленнее (транзакции же), зато при высокой посещаемости блокировки наступят намного, намного позже, чем для MyISAM.
Как поменять тип таблиц на InnoDB
Поменять тип таблиц на InnoDB можно следующим образом:
- В административном меню Настройки системы > Инструменты > SQL запрос выполнить команду:
SHOW TABLES
- В результате вы получите список всех текущих таблиц продукта. Для каждой таблицы необходимо выполнить команду:
ALTER TABLE <ИМЯ ТАБЛИЦЫ>, type=InnoDB
В FAQ приведен пример для создания скрипта для перевода таблиц в InnoDB.
- После перевода таблиц вашей базы в InnoDB надо добавить в файл
/bitrix/php_interface/dbconn.php
нижеследующий код:
define("MYSQL_TABLE_TYPE", "InnoDB");
Переход на тип таблиц InnoDB позволяет избежать возникновения узкого участка в производительности при работе с базой данных и в полном объеме использовать системные ресурсы.
Внимание! Обязательно конфигурируйте
InnoDB. Для лучшей производительности базы данных при работе с InnoDB рекомендуется настроить
my.cnf
для MySQL в разделе
параметров для InnoDB innodb_*
.
Наибольшее внимание следует обратить на следующие параметры и примеры:
set-variable = innodb_buffer_pool_size=250M
set-variable = innodb_additional_mem_pool_size=50M
set-variable = innodb_file_io_threads=8
set-variable = innodb_lock_wait_timeout=50
set-variable = innodb_log_buffer_size=8M
set-variable = innodb_flush_log_at_trx_commit=0
Рекомендуется: Для сокращения времени ответа сервера можно использовать отложенные транзакции и, в частности, устанавливать переменную set-variable = innodb_flush_log_at_trx_commit=0
.
Если MyISAM уже не используется активно, можно высвободить память в пользу InnoDB параметров.
Желательно, чтобы кэш данных вмещал в себя основной объем данных, используемых продуктом в работе. Обычно для работы базы данных выделяется порядка 60-80% свободной памяти в системе.
Рекомендуется: Производить многопотоковую (multithreading) сборку MySQL для улучшения производительности системы и возможностей по параллельной обработке запросов.
Пример настроек
Пример рекомендуемых настроек для сервера с 2 Гб оперативной памяти, работающего с операционной системой FreeBSD/Linux:
set-variable = table_open_cache=4096
В составе продукта около 250 таблиц, поэтому рекомендуется увеличивать кэш для заголовков таблиц.
set-variable = key_buffer_size=16M
set-variable = sort_buffer_size=8M
set-variable = read_buffer_size=16M
Эти параметры используются только для MyISAM. Если в базе нет таблиц MyISAM, то лучше установить минимальные значения.
set-variable = query_cache_size=64M
set-variable = query_cache_type=1
Кэширование результатов запросов. Обычно бывает достаточно 32 Мб (смотреть на статус Qcache_lowmem_prunes). Максимальный размер результата по умолчанию - 1 Мб, его можно регулировать.
set-variable = innodb_buffer_pool_size=780M
Основной буфер - чем больше, тем лучше.
set-variable = innodb_additional_mem_pool_size=20M
Вспомогательный буфер на внутренние структуры, большой делать не имеет смысла.
set-variable = innodb_log_file_size=100M
set-variable = innodb_log_buffer_size=16M
Чем больше размер лог-файла, тем реже надо будет записывать в основной файл данных. Суммарный размер лог-файла может быть сопоставим с величиной innodb_buffer_pool_size
(по умолчанию ведется два лога).
set-variable = innodb_flush_log_at_trx_commit=0
Отложенная фиксация транзакций, раз в секунду
set-variable = tmp_table_size=32m
Размер временных таблиц рекомендуется увеличивать до 32 Мб.
Рекомендуется так же увеличивать join_buffer_size
до 2 Мб, это существенно влияет на скорость выполнения ряда запросов.
set-variable = join_buffer_size = 2M
Совет администратору Переход на InnoDB может привести к значительному замедлению некоторых масштабных операций записи и обновления данных. Это связано с тем, что все операции по изменению данных начинают выполняться с использованием транзакций. Кроме того, в отличие от MyISAM для кэширования таблиц InnoDB не используется кэш операционной системы, а все кэшированные данные хранятся в кэше БД, определяемом параметром innodb_buffer_pool_size
. Вы должны сами определить оптимальность перехода вашего проекта на формат данных InnoDB.
Внимание! Если по каким-то причинам вы решили продолжить работу с типом данных MyISAM, обязательно проведите конфигурирование MySQL для увеличения объемов кэшируемой информации, областей сортировки и минимизации числа дисковых операций. Использование для базы данных 60-80% оперативной памяти может ускорить работу стандартного проекта в несколько раз.
Временная папка
При наличии достаточного количества ОЗУ рекомендуется выносить временную папку MySQL на ramdisk в памяти.
Для этого:
- Убедитесь, что в ядре реализована поддержка tmpfs.
- Создайте новую точку монтирования и дайте все права на использование:
# mkdir /mnt/tmpfs/
# chmod 777 /mnt/tmpfs/
- Дайте команду (от рута или через sudo):
# mount -t tmpfs -o size=1024M tmpfs /mnt/tmpfs/
или
$ sudo mount -t tmpfs -o size=1024M tmpfs /mnt/tmpfs/
где 1024M есть размер RAMdisk в Мегабайтах.
Внимание! К размеру папки нужно подходить осторожно: если вы попросите создать ramdisk больше, чем имеете оперативной памяти, система начнёт сгружать всё в swap-файл и реальный результат подключения временной папки может быть отрицательным.
Настройка базы данных Oracle
Внимание! С 1 января 2017 года прекращена поддержка продуктов «1С-Битрикс» на базах данных Oracle Database и MS SQL Server. Для установок, использующих эти БД, недоступны обновления и возможности новых релизов.
Урок в курсе оставлен для тех, кто использует установку с Oracle. Он не обязателен к изучению и его можно пропустить.
Общие рекомендации по настройке Oracle совпадают с рекомендациями Oracle по конфигурированию системы для уменьшения дисковых операций чтений, сортировки и перестроения.
Стоит обратить внимание на системные переменные управления памятью. Рекомендуется использовать до 60-80% оперативной памяти для кеширования данных за счет управления переменными:
db_cache_size
shared_pool_size
pga_aggregate_target
Начиная с версии Oracle 10, рекомендуется использовать Automatic Shared Memory Management:
- при установке БД, выбрать % ОЗУ, которая будет доступна БД в пределах 60-80% от ОЗУ сервера с помощью параметра SGA_MAX_SIZE
- во время эксплуатации БД количество памяти, доступное Oracle можно откорректировать (в большую или меньшую стороны) с помощью параметра SGA_TARGET без перезапуска БД. Индикатором правильности установки параметров управления памятью будет отсутствие дисковых операций swap, также имеет смысл контролировать общесистемный размер используемого swap пространства – не более 100 MB.
Для экономии места SGA (shared_pool) и уменьшения расходов процессорных ресурсов на разбор SQL-запросов, отличающихся только значениями констант, рекомендуется установить параметр
cursor_sharing = FORCE
либо
cursor_sharing = SIMILAR
отключив расчёт гистограмм для столбцов таблиц в параметрах сбора статистики:
begin dbms_stats.set_param( 'METHOD_OPT', 'FOR ALL COLUMNS SIZE 1' ); end;
Если Oracle установлен на той же машине, что и веб-сервер, рекомендуется использовать протокол IPC (PROTOCOL = IPC
) и (KEY = EXTPROC
) для соединения с базой для исключения работы через IP-стек.
Если реализована двухуровневая схема обработки запросов с Front-end и Back-end и установлен параметр MaxClients, то можно без опасений использовать постоянные соединения между PHP и Oracle (Persistent connection), выполнив следующую установку в файле /bitrix/php_interface/dbconn.php
:
define("DBPersistent",true);
Примечание: Начиная с релиза Oracle 10g R2, возможно использование отложенных транзакций (Enhanced COMMIT) в случаях если бизнес-требования к проекту допускают возможную потерю данных нескольких последних транзакций. Использование отложенных транзакций существенно ускоряет проект, позволяет снять прямую зависимость от производительности дисковой подсистемы и существенно уменьшить время генерации страниц. Для использования этого механизма, необходимо установить параметр: COMMIT_WRITE='BATCH,NOWAIT'
.
Пример-упражнение
Пример-упражнение. Настройки MySQL для виртуальной машины
В качестве примера рассмотрим как настроена база данных MySQL в виртуальной машине VMBitrix.
Перейдите в папку /etc/mysql
и посмотрите настройки MySQL для виртуальной машины. Выключите виртуальную машину и установите ей большее значение ОЗУ (например, 512 мб). Посмотрите, как изменились настройки в файле /etc/mysql/conf.d/bvat.cnf
:
Для 256 мб:
[mysqld]
query_cache_size=32M
innodb_buffer_pool_size=32M
для 512 мб:
[mysqld]
query_cache_size=48M
innodb_buffer_pool_size=96M
Кроме того, при 512 мб система чувствует себя гораздо свободнее:
Доступная память при 256 мб:
# free
total used free shared buffers cached
Mem: 255676 224340 31336 0 33468 67964
-/+ buffers/cache: 122908 132768
Swap: 530136 51800 478336
Доступная память при 512 мб:
# free
total used free shared buffers cached
Mem: 515572 299208 216364 0 6944 186336
-/+ buffers/cache: 105928 409644
Swap: 530136 0 530136
Связано это с тем, что виртуальная машина VMBitrix содержит скрипты, активизирующиеся при загрузке и устанавливающие необходимые параметры системы. Ключевым параметром является объем оперативной памяти, установленный в системе.
Примечание: Кастомизацию настроек можно производить без отключения виртуальной машины. Для этого достаточно вносить изменения в файл /etc/mysql/conf.d/z_bx_custom.cnf
.
Оптимизация запросов к БД
Пример оптимизации запроса
Всегда минимизируйте запросы. Например, если в цикле идет запрос к элементу ИБ, то уже необходимо задуматься над минимизацией. Да, это займет больше времени, но вам скажут спасибо клиенты.
Нельзя:
foreach($arResult["ORDERS"] as $key => $val)
{
foreach($val["BASKET_ITEMS"] as $vvval)
{
$rsEls = CIBlockElement::GetByID();
}
}
Следует:
$arIDs = array();
foreach($arResult["ORDERS"] as $key => $val)
{
foreach($val["BASKET_ITEMS"] as $vvval)
{
$arIDs[] = $vvval["PRODUCT_ID"];
}
}
if(!empty($arIDs))
{
$rsEls = CIBlockElement::GetList(array(), array("ID" => $arIDs));
...
}
foreach($arResult["ORDERS"] as $key => $val)
{
foreach($val["BASKET_ITEMS"] as $vvval)
{
//наполняем данные, налаживая соответствие ID-ков
}
}
Фактически, вы сводите порой десятки, если не сотни, запросов к одному.
Специальные методы
Если для какого-либо изменения в БД предусмотрен специальный метод, то следует использовать именно его, а не более общий метод изменения БД.
Хороший пример - модуль интернет-магазина и работа с заказом: можно изменить флаг оплаты заказа путем CSaleOrder::Update, а можно путем CSaleOrder::PayOrder. Так вот, следует применять именно PayOrder, потому что в нем произойдет вызов соответствующих обработчиков.
Даже если вам надо изменить множество полей (того же заказа) и флаг оплаты, то произведите изменение через PayOrder, а затем уже апдейт остальных полей.