Jean-Christophe Roux wrote:
Hello,I am struggling with an issue and I have the following set up that reproduces the problem.I am running apache 2.2 on Centos 5.0.On the client side, I have a web page that polls the server every second. Using prototypejs, it looks like that:setInterval('polling();', 1000); function polling() { new Ajax.Request ( 'polling_server.php', { onSuccess: function(transport) { } } ); } the polling_server.php does nothing: <?php ?> Most queries takes around 100-150 ms for a round trip (measured using firebug)Sooner or later though, one of those requests will take a lof of time and will timeout after 74000ms. Also, there are sequences of requests that take a lot of time (5, 10 seconds sometimes more) and then the system gets back to the normal 100ms. it looks like a jam. I'd like to understand why this is happening so that I can fix it. How could I explore the issue further?Where does the 74000ms come from? Is it something I can change in apache?
---------------- End original message. ---------------------It is very doubtful that this is an issue with the Apache httpd if you are using one of the MPM models and have it configured with enough workers to handle the load.
However, you really have not given us enough information to even make an informed guess. Is there anything in your error or access logs indicating a problem (adjust the debug level of your error log if needed to get more detail)? What exactly is your architecture? Are you generating dynamic content in a CGI application or back-end server process? If so, is that running on the same machine or another? How much RAM do you have? How is Apache MPM configured?
I would suggest (with lack of further information) that it is most likely that network congestion is the problem or possibly something else in the system is resource limited a back-end server application perhaps? Possibly another server process such as an MTA hogging resources? Not enough RAM causing swap space to be heavily utilized?
Also, you must understand that the Internet as it exists today is a "best effort delivery system". This means that there is absolutely zero guarantee that traffic you send will ever be received by the other end or that there will be any sort of deterministic latency to the system. You cannot assume that the round-trip time for a request to be served will remain in the 100-150 mS window in a production environment with access from the public Internet. There are far too many random factors regarding routing, traffic bandwidth and other things to be sure that your application is going to reliably serve within a certain time window to all possible users.
Even on a LAN with a lightly loaded machine, other network traffic can affect your round-trip times. The only way you can ever be certain of this is in a trivial test application with two dedicated machines that has no real resemblance to a production environment.
Dragon ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Venimus, Saltavimus, Bibimus (et naribus canium capti sumus) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|