httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Anecito <>
Subject Re: [users@httpd] What is %D in access log meassuring?
Date Thu, 31 Mar 2011 15:16:45 GMT
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.


----- Original Message ----
From: Mark Montague <>
Cc: Janne H <>
Sent: Thu, March 31, 2011 7:10:22 AM
Subject: Re: [users@httpd] What is %D in access log meassuring?

On March 31, 2011 8:37 , Janne H <>  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" 
> ipB [31/Mar/2011] "GET /file.jpg HTTP/1.0" 200 42981 "-" "ApacheBench/2.3" 
> (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 

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

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
  "  from the digest:
For additional commands, e-mail:

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message