У меня есть приложение php, работающее на IIS 7.5, php 5.4 работает как fastcgi. Приложение работает абсолютно безупречно, за исключением того, что длинные сценарии php, похоже, зависают; нет 500, они просто кажутся никогда не завершенными и возвращают результаты в браузер.
Я написал простой тестовый скрипт ниже, чтобы исключить возможность ошибки программирования в главном приложении:
<?php /* test timeout */ /*set_time_limit(110);*/ echo "Testing time out in seconds\n"; for ($i = 0; $i < 175; $i++) { echo $i." -- "; if(sleep(1)!=0) { echo "sleep failed script terminating"; break; } } ?> Если я запустил скрипт за 175 секунд, он зависает. Ниже он вернет результаты в браузер.
Вот параметры тайм-аута, которые я установил для php и fastcgi. Я также играл с настройкой этих очень низких, чтобы получить различные ошибки времени и преуспел, и это привело меня к выводу, что есть еще одна настройка, которую мне не хватает … возможно.
Исправьте меня, если мои презумпции ошибочны, но было бы справедливо сказать, что если сценарий истечет, браузер получит сообщение об ошибке, где, как если бы скрипт был убит IIS до завершения, в браузер ничего не возвращается, и вы получаете то, что похоже на зависание, что касается браузера?
FastCGI
activity timeout=800 Idle Timeout = 900 request Timeout 800
Php
max_execution_time=700
Если длинный сценарий не взаимодействует с браузером, то через 180 секунд большинство браузеров перестанут отвечать на сервер, возвращая результаты. Серверный скрипт не висел или не прерывался, а браузеры (то есть ff и хром) становились невосприимчивыми.
Чтобы проверить это, я запустил свой скрипт и посмотрел статус запроса. Диспетчер IIS-> выберите сервер-> выберите рабочие процессы (центральная панель) -> выберите пул приложений-> выберите запросы просмотра (правая панель) и просмотрите столбцы состояния и времени. Вам нужно будет повторно нажать «показать все», чтобы увидеть обновление значений.
Состояние изменилось с ExecuterequestHandler на ответ отправки, а затем скрипт закончен, как и следовало ожидать, но браузеры все еще выглядели так, как будто они ожидали ответа сервера.
Я обновил свой тестовый сценарий выше, чтобы гарантировать, что браузеры регулярно получали ответы на запросы:
<?php @ini_set("output_buffering", "Off"); @ini_set('implicit_flush', 1); @ini_set('zlib.output_compression', 0); @ini_set('max_execution_time', 800); header( 'Content-type: text/html; charset=utf-8' ); echo "Testing time out in seconds\n"; for ($i = 0; $i < 600; $i++) { echo $i." -- "; if(sleep(1)!=0) { echo "sleep failed script terminating"; break; } flush(); ob_flush(); } ?>
Выход не возвращался к бит-биту битвы, как надо, и проблема осталась.
Следующий шаг, я посмотрел на буферизацию ответа на сервере. Настройка была установлена на очень большое число и означала, что промывка не будет работать. Поэтому я устанавливаю ResponseBufferLimit равным 0 в соответствии с инструкциями, предоставленными @Dario в PHP-флеше, которые перестали работать в IIS7.5
Это решило проблему 🙂 Если это решение помогло вам, пожалуйста, перейдите к указанному выше вопросу и дайте Дарио еще +1 от меня, пожалуйста, и, возможно, один к OP для его вопроса и сценария.
благодаря