Налаштування модуля Push and Pull 1С-Bitrix
Онлайн-чат оновлюється лише при перезавантаженні сторінки. Сповіщення про новий заказ приходять з затримкою на кілька хвилин. «Жива стрічка» в корпоративному портальному Bitrix24 не оновлюється в реальному часі. Все це — наслідок відсутності налаштованого модуля Push and Pull, який забезпечує двосторонню комунікацію між сервером та браузером.
Що робить модуль Push and Pull
Модуль pull (Bitrix-ідентифікатор: pull) забезпечує серверний push подій на клієнт. Технічно реалізований через кілька транспортів:
- WebSocket — постійне з'єднання, мінімальна затримка (1–5 мс)
- Long Polling — клієнт тримає HTTP-запит відкритим, сервер відповідає коли є подія
- Server-Sent Events — односторонній потік від сервера
Вибір транспорту відбувається автоматично. Для WebSocket потрібен окремий NodeJS-сервер, що поставляється у складі Bitrix VM або встановлюється окремо.
Установка та активація модуля
У адміністративній панелі: «Marketplace» → «Установлені рішення» → знайти модуль push and pull. Якщо не встановлений — «Marketplace» → «Всі рішення» → пошук «Push and Pull».
Після встановлення в /bitrix/modules/pull/ з'являється модуль. Налаштування: «Налаштування» → «Налаштування продукту» → «Push and Pull».
Ключові параметри модуля:
-
Сервер Push — адреса NodeJS Push-сервера (наприклад,
http://localhost:9010) - Сервер Pull (Long Polling) — адреса для long polling (може бути той же)
- Ключ безпеки — shared secret для підпису повідомлень
Конфігурація через b_option
Налаштування зберігаються у таблиці b_option, модуль pull:
SELECT * FROM b_option WHERE MODULE_ID = 'pull';
Ключові параметри:
-
PUSH_ENABLE— увімкнення push-сповіщень -
PULL_SERVER_ENABLED— увімкнення pull-сервера -
PUSH_SERVER_URL— URL NodeJS push-сервера -
PULL_SERVER_URL— URL pull-сервера -
PUSH_SECURITY_KEY— ключ безпеки
Long Polling без NodeJS
Якщо NodeJS не встановлений, модуль працює в режимі Long Polling через PHP. Для цього потрібно налаштувати окремий location у Nginx, який буде тримати з'єднання:
location ^~ /bitrix/pub/ {
proxy_pass http://127.0.0.1:9000; # PHP-FPM
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_read_timeout 25;
proxy_send_timeout 25;
# Не буферизувати відповідь — відправляти одразу
proxy_buffering off;
proxy_cache off;
}
Шлях /bitrix/pub/ — стандартний endpoint для pull-запитів у Bitrix.
Перевірка роботи
У браузері відкрити DevTools → Network. Знайти запит до /bitrix/pub/ або до push-сервера. Він повинен висіти відкритим (pending) — це й є long polling або SSE з'єднання.
З PHP відправити тестову подію:
use Bitrix\Pull\Event;
use Bitrix\Pull\Push;
// Відправити подію конкретному користувачу
$push = new Push(1); // userId = 1
$push->addUser(1);
$push->setMessage([
'module_id' => 'im',
'command' => 'test',
'params' => ['text' => 'Тестова повідомлення']
]);
$push->send();
// Через статичний метод
\CPullWatch::AddToStack('TEST_CHANNEL', [
'module_id' => 'main',
'command' => 'test',
'params' => []
]);
\CPullStack::Send();
Типові проблеми
Канал не підключається, помилка 502. NodeJS push-сервер не запущений або впав. Перевірте:
systemctl status push-server
# або
ps aux | grep node
Long polling працює, але затримка велика. proxy_read_timeout у Nginx менше 20 секунд — Nginx розриває з'єднання до відповіді сервера. Клієнт одразу переподключається, створюючи додаткове навантаження.
З'єднань занадто багато, worker_connections переповнен. При 1000 онлайн-користувачів — 1000 висячих HTTP-з'єднань. Потрібно збільшити worker_connections у Nginx та системний ліміт відкритих файлів:
# /etc/security/limits.conf
nginx soft nofile 65535
nginx hard nofile 65535
# Nginx
events {
worker_connections 8192;
use epoll;
multi_accept on;
}
Повідомлення теряються при рестарті PHP-FPM. Очередь подій b_pull_stack очищується агентом. При рестарті FPM агенти не виконуються — події накопичуються. Після рестарту виконати вручну або налаштувати cron для агентів Bitrix.