On Dec 1, 2009, at 7:00 AM, Ian Hobson wrote:

> My thinking.
>
> 1) Alter the server code so that it looks once, and replies. It will reply with many more "null" returns, but it will handle each request in a fraction of a second. The queue will disappear.
>
> 2) Alter the client code, so that it delays longer - say 3 seconds - after getting a heatbeat update before requesting the next.
>
> 3) Have the send shorten this delay - perhaps the reply will trigger the next heatbeat request - so that your posts come back quickly.
>
> 4) If the heatbeat is in progress when a send is requested, delay the send until the heatbeat's reply is recieved.
>
> Question - will this work? Why? Why not?
>
> Question - is point 4 necessary?
>
> Input and ideas gratefully recieved.
>
> Regards
>
> Ian

I am not sure of the details but i think you need to handle all the control and timing on the client side and let the php processes do what they are intended to do and that is find new chat messages and return them immediatly. Because having the 4 sec wait in the php process locks that process up for that entire 4 secs.. Thus if you only have 3 processes you can only have 3 reqs at any given time and it will be locked up for 4 secs each. I think best would be just return what is there and if nothing is there then have the client expecting this and handle it in the client.

Rob
_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx