<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> On 26 July 2011 13:57, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br>

><br>
> > Hello!<br>
> ><br>
> > Attached patch (against 1.0.5) introduces upstream keepalive<br>
> > support for memcached, fastcgi and http.  Note the patch is<br>
> > experimental and may have problems (though it passes basic smoke<br>
> > tests here).  Testing is appreciated.<br>
> ><br>
> ><br>
> Sounds great. Is it expected to work in this case:<br>
><br>
>  upstream fastcgi_backend {<br>
>        server unix:/tmp/php-fpm.sock<br>
>        keepalive 32;<br>
>    }<br>
<br>
</div>Yes (though I'm not sure if php is able to maintain connections<br>
alive, but quick look suggests it should).</blockquote><div><br></div><div>Out of interest I have tested the above (on 1.0.5) under heavy load and I have run into a problem. 40 - 90 seconds after startup all requests start returning 502 and the log is flooded with: </div>
<div><br></div><div>[error] 2120#0: *37802582 connect() to unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, [...] upstream: "fastcgi://unix:/tmp/php-fpm.sock:"</div>
<div><br></div><div>I am running php-fpm 0.5.14 with 32 * PHP 5.2.17 processes. </div><div><br></div><div>How long it takes seems to depend on request rate. It looks like the php-fpm listen backlog is overflowing (it's at 8178, but that's normally sufficient when keepalive is disabled).</div>
<div><br></div><div>Likely to be a php-fpm problem? Someone not reusing connections? </div><div><br></div><div>Thomas</div><div><br></div></div>