Hi All, I am confused by these messages because earlier %D was defined to include the time for the processing all lines after the first one of the packets containing the request and the time to process the request itself. If true then the following emails about checking the network and ipB itself make sense. Also, any request will takeup CPU resources on the server and other servers depending upon where the image is hosted and if is cached. The only case where maybe the request does not takeup direct server CPU time is if the request goes through an intellegent network card and it is smart enough to know to serve the image file from it's cache but I am not sure those cards can do that. I have seen Apache Components group performance test results that indicate the response time for a single request where there is no other requests occuring is under a millisecond and that includes going through a servlet. I have confirmed myself for a servlet containing no code using the Apache APR with Tomcat 7.0.8 the response as measured on at the client running on the server Tomcat is located using uri localhost is under 600 microseconds. To my understanding that bypasses the network card. If I ran the same test from a cheap laptop running on my 1Gb Ethernet I get around 2-3ms. Regards, -Tony ----- Original Message ---- From: Mark Montague <mark@xxxxxxxxxxx> To: users@xxxxxxxxxxxxxxxx Cc: Janne H <jannehson51@xxxxxxxxx> Sent: Thu, March 31, 2011 7:10:22 AM Subject: Re: What is %D in access log meassuring? On March 31, 2011 8:37 , Janne H <jannehson51@xxxxxxxxx> wrote: > Well, I'm still a little confused. > I'm trying to find out why the accesslog shows the line > > > ipA [31/Mar/2011] "GET /file.jpg HTTP/1.0" 200 42981 "-" "ApacheBench/2.3" 3560 > ipB [31/Mar/2011] "GET /file.jpg HTTP/1.0" 200 42981 "-" "ApacheBench/2.3" >93574 > > (the ipA is much "closer" to the server than ipB). First, are these results consistently repeatable over a large number of measurements? If not, then it is likely just normal statistical variation due to normal network traffic, CPU scheduling, or something similar. Otherwise... What does 'much "closer"' mean? What is the network topology (all links, hardware, configuration) between ipA and your web server? Between ipB and your web server? What is the hardware (number and speed of CPUs, amount of RAM, etc.) for ipA and ipB? What OS and version are each running? How heavily loaded is each one during the test (CPU, I/O)? How is the kernel and networking stack on each one configured? I recommend using a network sniffer to analyze differences in network traffic for a request sent from ipA versus a request sent from ipB. Try and find out where the delay is occurring for ipB. If (and only if) the network trace shows that the delay is in waiting for your server to generate and send packets to ipB -- as opposed to your server waiting for packets from ipB -- then use performance analysis tools on your server such as strace, truss, DTrace, or SystemTap to figure out what your kernel, and web server processes are doing during that time. Keep in mind that you're looking at a 90 millisecond (90,000 microsecond) difference between the two clients. Depending on your situation, this may or may not actually be a significant real-world problem, and hence it may or may not justify a large amount of time and effort for finding the cause. > i also tried a curl download with a limit on 1000 bytes/s but the time logged >in access-log many orders of magnitute away from the acctual time it took to >receive the image (about 42 seconds) So I guess the time that is logged is "when >apache has sent the final bytes to the level below in the network stack? %D measures how long Apache spends processing the request. It does not measure how long other things on your server (kernel, host-based firewall, etc.) take to process the data, nor does it measure how long it takes data to actually reach the client. If you are interested in how long the request takes on the client (including how long it takes the response to travel from the server to the client), then you will need to measure that on the client, not on the server. -- Mark Montague mark@xxxxxxxxxxx --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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
|