Welcome! Log In Create A New Profile

Advanced

Re: FastCGI PHP - unable to prematurely close connection to browser

Rob Schultz
February 07, 2010 12:08PM
Hi,
Not really to change you method on doing things. but you still will encounter slow response times for users eventually since that PHP process is *still* processing things after that user is done and won't be ready for the next user until it is done processing that script. So theoretical if you had 5 max PHP processes to handle client requests and say each PHP script take 500ms to complete but only 100ms is until your Connection: close. If 6 users hit your server at once. That user would have to wait the full 500ms until a free PHP process is available to process his request and then take the additional 100ms for it to see content. So now his experience for the page to load up is it takes almost 600ms.

Something i would suggest is using a messaging queue and a "few PHP process's that are just designed to process the queue" this allows you to separate your user processing and your offline processing. Which will also allow you to offload your work to another server if it starts growing and such. here is website with some links to some message queues. http://blog.fedecarg.com/2008/11/03/getting-started-with-message-queues/

v/r,
Rob

On Feb 7, 2010, at 8:50 AM, cactus wrote:

> First of all - thank you for your answer, I really appreciate it.
>
> This is interesting - I have re-checked and it takes me 32ms to get the result on my development machine:
> Server Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny4 with Suhosin-Patch
> X-Powered-By PHP/5.2.6-1+lenny4
> (PHP is installed as mod_php)
>
> Still, it is very important for me to be able to postpone processing. If I can't do it on NginX I will probably have to find another server that can do this (overall load on the server is less important than quick response times in this case). I'm really hoping it's just a config thing... :)
>
>> From what I understand:
> - PHP offers no way to prematurely close the connection except by setting and reaching Content-Length
> - it is the web server (NginX / Apache) that can (should?) close the connection in this case
>
> I can't make PHP close the conenction, so my only hope is NginX. Can it be told to do so? Am I missing something?
>
> Thanks again!
>
>
>
> Hoang Hoang Wrote:
> -------------------------------------------------------
>> Hi,
>>
>> I just tested your script and found that I needed
>> to wait 10s to see the
>> response. I am using Windows XP, Apache 2.1.11
>> worker MPM, PHP 5.3.1
>>
>> It did not work asynchronously as you expected. Am
>> I missing something
>> here?
>>
>> Regards
>>
>> cactus wrote:
>>> Hi all!
>>>
>>> I am optimizing a few of the PHP scripts by:
>>> - doing all that generates output to browser
>>> - closing connection to browser
>>> - doing some more processing
>>>
>>> The processing bit cannot be avoided, but the
>> speed of execution (from
>>> visitors' point of view) is awesome this way.
>> The problem is that we
>>> have tried migrating the script to NginX +
>> FastCGI (it works on Apache +
>>> mod_php) but it doesn't close the connection
>> anymore, it keeps it open
>>> until the end... Which makes scripts slow again.
>>>
>>> I am using Content-Length to allow server to
>> figure out that all content
>>> was already generated. This is the test case:
>>>
>>> <?
>>> header("Connection: close"); // not sure we
>> need this one
>>> header("Content-Encoding: none");
>>> ignore_user_abort(true);
>>> ob_start();
>>>
>>> echo ('Lets output something.');
>>>
>>> // output Content-Length and flush buffers:
>>> $size = ob_get_length();
>>> header("Content-Length: $size");
>>> ob_end_flush();
>>> flush();
>>>
>>> // ****************
>>> // do some heavy processing here:
>>> sleep(5);
>>>
>>> function postproc() {
>>> flush();
>>> sleep(5);
>>> }
>>> register_shutdown_function('postproc');
>>> ?>
>>>
>>>
>>> The browser shows this page immediately in
>> Apache+mod_php but it waits
>>> for 10 seconds in NginX + FastCGI.
>>>
>>> I am a bit stuck here and would appreciate some
>> help... Is this a
>>> problem with FastCGI? Is there another way to do
>> it?
>>>
>>> Thanks!
>>>
>>> Posted at Nginx Forum:
>>>
>> http://forum.nginx.org/read.php?2,51310,51310#msg-
>> 51310
>>
>> --
>> Posted via http://www.ruby-forum.com/.
>>
>> _______________________________________________
>> nginx mailing list
>> nginx@nginx.org
>> http://nginx.org/mailman/listinfo/nginx
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?2,51310,51672#msg-51672
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx
Subject Author Posted

FastCGI PHP - unable to prematurely close connection to browser

cactus February 06, 2010 05:00AM

Re: FastCGI PHP - unable to prematurely close connection to browser

Hoang Hoang February 06, 2010 10:32AM

Re: FastCGI PHP - unable to prematurely close connection to browser

cactus February 07, 2010 06:30AM

Re: FastCGI PHP - unable to prematurely close connection to browser

Rob Schultz February 07, 2010 12:08PM

Re: FastCGI PHP - unable to prematurely close connection to browser

Reinis Rozitis February 08, 2010 06:42AM

Re: FastCGI PHP - unable to prematurely close connection to browser

cactus February 14, 2010 09:28AM

Re: FastCGI PHP - unable to prematurely close connection to browser

cactus February 07, 2010 01:30PM

Re: FastCGI PHP - unable to prematurely close connection to browser

Rob Schultz February 07, 2010 01:54PM

Re: FastCGI PHP - unable to prematurely close connection to browser

cactus February 07, 2010 02:48PM

Re: FastCGI PHP - unable to prematurely close connection to browser

Tobia Conforto February 08, 2010 04:32AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 125
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready