Re: What is %D in access log meassuring?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 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



[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux