Ошибка 504 Gateway Time-out - бывает по разным причинам, главное, что ответ от сервера не приходит в определенное время
Самое просто решение (если код рабочий)Увеличить время ответа сервера, время выполнения скрипта |
Мы поставили 3500 секунд, но надо подбирать индивидуально
1. ngix повысить время ожидания веб-сервера 3500 секунд поставить
Подключитесь через ssh
Откройте конфигурационный файл
sudo nano /etc/nginx/nginx.conf |
Добавьте(измените) строки в блоке server:
http{
#...
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;
#...
} |
Добавьте(измените) строки в блоке server:
server {
#...
proxy_connect_timeout 3500;
proxy_send_timeout 3500;
proxy_read_timeout 3500;
send_timeout 600;
#...
} |
Перезапустите Nginx
в новом поколении
раньше так
2 Установить php max_execution_time 3500
или .htaccess (лучше для проверки)
php_value max_execution_time 3500, |
или в /bitrix/php_interface/dbconn.php
@ini_set("max_execution_time", 3500); |
3. Установить php session.gc_maxlifetime 3500
или .htaccess (лучше проверки)
php_value session.gc_maxlifetime 3500, |
или в /bitrix/php_interface/dbconn.php
@ini_set("session.gc_maxlifetime", 3500); |
4. Установить в
/bitrix/php_interface/dbconn.php
5. В параметрах безопасности группы тоже увеличить сессию(во всех группах, где состоит пользователь, из-под которого обмен происходит, в т.ч. неавторизованные пользователи) 60мин (3500/60=59 мин)
в
dbconn.php можно по условию
if ( $_REQUEST[ 'mode' ] == 'import' ) {
@set_time_limit(73500);
@ini_set("session.gc_maxlifetime", 73500);
}
else{
@ini_set("max_execution_time", 3500);
@set_time_limit(3500);
} |
Как проверитьВывести параметры
echo ini_get('max_execution_time');
echo ", ";
echo ini_get('session.gc_maxlifetime'); |
выполнить скрипт, который будет
спать немного меньше времени. чем Вы выставили:
sleep(3470); //немного меньше, чем вам надо
echo "hello world"; |
можно в командной строке
https://ваш_сайт/bitrix/admin/php_command_line.php?lang=ru
можно в тестовом скрипте
но тогда, если параметры выставили в /bitrix/php_interface/dbconn.php
подключите предварительно пролог
require_once($_SERVER['DOCUMENT_ROOT'] . "/bitrix/modules/main/include/prolog_before.php");
|
Искать причину в коде и править кодПричина 1
Куча кастомных обработчиков событий, или мало но очень тяжелые (долго исполняются), или много запросов к базе можно оптимизировать
Смотреть в init.php, в модулях
Решение: переделать обработчики, убрать обработчики, оптимизировать запросы к базе
Причина 2Большая структура разделов, она выполняется за 1 шаг, если количество товаров-свойств в пакете можно уменьшить, то структура создается за 1 шаг.
Решение: только увеличить время ответа сервера, время выполнения срипта (см. выше)
Причина 3при загрузке файла с ценами prices_***.xml
в компоненте bitrix/catalog.import.1с/component.php
на 7 шаге ($NS["STEP"] == 7)
вызывается метод
$result = $obCatalog->ImportElements($start_time, $arParams["INTERVAL"]); |
который описан тут
/bitrix/modules/iblock/classes/general/clm2.phpметод обновляет фасетный индекс инфоблока, запускается без учета по времени выполнения срипта
Iblock\PropertyIndex\Manager::runDeferredIndexing($this->next_step["IBLOCK_ID"]); |
И он выполнялся у заказчика 2 минуты! Соответственно 1С получает 504 Gateway Time-out, и обмен завершается ошибкой.
метод runDeferredIndexing описан тут
/bitrix/modules/iblock/lib/propertyindex/manager.phpцикл
foreach (self::$elementQueue[$productIblock] as $elementId)
self::elementIndexing($indexer, $elementId); //тут долго выполняется |
Решение 2. закомментировать данную строку
self::elementIndexing($indexer, $elementId); |
но после выполнения обмена надо запустить создание фасетного индекса