Спасибо за ответы, но это сильно погоды не изменяет =( ведь это как
дефолтный конфиг.
Вот с таким конфигом:
worker_processes 1;
error_log logs/error.log info;
events
{
worker_connections 1024;
}
http
{
include mime.types;
default_type application/octet-stream;
Судя по логам - ab просто не дождался ответа. Это может быть
банально нормально, если время ответа тестируемого index.php
достаточно большое, а php-процессов - мало.
Хотя я не совсем понимаю, что понимается под словами и
прибивается процесс php-cgi, если он действительно умирает - то
Hello!
On Thu, Apr 18, 2013 at 11:03:34AM +0300, Rosavitskiy Valintin wrote:
On 18.04.2013 10:50, Maxim Dounin wrote:
Hello!
On Thu, Apr 18, 2013 at 02:03:30AM +0300, Валентин Росавицкий wrote:
18.04.2013 1:53, Maxim Dounin пишет:
Hello!
А в чём проблема, кроме необходимости слегка
Hello!
On Thu, Apr 18, 2013 at 05:25:19AM -0400, FireFenix wrote:
Судя по логам - ab просто не дождался ответа. Это может быть
банально нормально, если время ответа тестируемого index.php
достаточно большое, а php-процессов - мало.
Хотя я не совсем понимаю, что понимается под словами
Добрый день!
Своими силами проблему никак решить не могу. В дополнение прикладываю
часть debug.log из которого видно, что идет внутренний редирект к
странице 500.html,
когда имеет место 404-ая ошибка и апстрим на нее не ответил.
А вот в случае 403-ей ошибки, когда апстрим не отвечает, то
Так и попробуйте для начала так же, как раньше делали -
fastcgi_cache + fastcgi_cache_use_stale, всё должно получиться.
С учётом наличия ещё одного кеша - я бы рекомендовал конфигурить
что-то нибудь неоченьдолгоживующее, и видимо только для
востребованных ресурсов (fastcgi_cache_min_uses).
Спасибо, Максим!
Теперь все встало на свои места. Буду внимательней к документации.
On 18.04.2013 17:50, Maxim Dounin wrote:
Hello!
On Thu, Apr 18, 2013 at 02:31:04PM +0400, Alex Belyansky wrote:
Добрый день!
Своими силами проблему никак решить не могу. В дополнение
прикладываю часть
