<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=KOI8-R" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
А в nginx случайно никак нельзя прописать лимит одновременных
подключений на fastcgi сервер? <br>
<br>
<br>
Борис Долгов пишет:
<blockquote
cite="mid:91c9771b0910040025j6e54f8c1q3144aabe0cb7931d@mail.gmail.com"
type="cite">
<pre wrap="">Лучше посмотрите strace'ом, на чем заблокировался php-worker и
попытайтесь устранить это вместе с php-программистами.
2 октября 2009 г. 13:35 пользователь <a class="moz-txt-link-abbreviated" href="mailto:nginx@rufox.ru">nginx@rufox.ru</a> <a class="moz-txt-link-rfc2396E" href="mailto:nginx@rufox.ru"><nginx@rufox.ru></a> написал:
</pre>
<blockquote type="cite">
<pre wrap="">Согласен, что намудрено. Туда просто программистами была заложена какая-то
идея по распределению серверов. В том месте, о котором написал в примере,
всё-равно настою чтобы упростили, т.к. это жутко не рационально. Да и
распределять в будущем будем скорее всего как-то по-другому. Но php виснет и
где-то в других местах. Просто пока не удалось отследить где именно.
Почему курл не знаю. Там насколько понял всего один параметр отдаётся. Оно
даже с file_get_content() работает. Но и с ним тоже виснет. Мне кажется, что
зависает из-за того что неправильно выстраивается очередь на обработчики.
Т.е. 2.php назначается обработчику, на который передали 1.php . А очередь
при этом обрабатывается каждым воркером в один поток. Может этим как-то
можно управлять?
Anton Bessonov пишет:
</pre>
<blockquote type="cite">
<pre wrap="">Что-то как-то намудрённо... Почему курл, если скрипт находится локально?
Почему не натравить парзер?
<a class="moz-txt-link-abbreviated" href="mailto:nginx@rufox.ru">nginx@rufox.ru</a> schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Например. Есть скрипт 1.php , который прежде чем выдаст ответ,
запрашивает инфу у 2.php (через curl)
запущено 50 обработчика php
Если обратится к 1.php в 51 и более паралельных запросов, все обработчики
полностью виснут. После этого приходится убивать php при помощи
killall -9 php-cgi
иначе не убивается
пока просто отделили под 2.php несколько обработчиков на другом порту
хотя и сейчас местами наблюдаются подвисания, но обычно отвисает сам
Проблема похоже в php. Может кто-нибудь уже решил её?
Кстати пока разбирался с этим замерял производительность связки на
тестовой машине (средний домашний двухядерник).
eaccelerator включён
Скрипт с обычным phpinfo(); обрабатывается примерно 430 раз в секунду
Рабочие скрипты не больше 100 в секунду. Причём, касательно этих 100,
такое ощущение, что где-то, что-то нужно "подкрутить", т.к. общая загрузка
системы во время теста 65-70%
Причём пробовал apache 1.3.x + mod_php и получил примерно такую же
производительность php (ниже процентов на 10).
Действительно что-то нужно донастроить, или это нормальные показатели для
php?
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>