time to read packets for HTTP query

[Frederik Nosi]

Hi,

On 09/11/2015 11:20 AM, Lukas Tribus wrote:
> Hi,
>
>
>> I'm running a SAAS service running via NGINX and have been running tcpdump
>> to look at the incoming packets for HTTP queries. Many of the HTTP queries
>> are bigger than the MTU of 1,500 bytes and therefore arrive as 2, 3, or 4
>> packets. I noticed that for some customers there are significant delays
>> between packets. The average size of these delays acts as a kind of
>> fingerprint for each customers. The inter packet delay various from a few
>> milliseconds to 100ms plus! Some customers have no delay. There are all
>> shades of grey.
>>
>> When processing a SAAS query I log how long the processing time took etc. So
>> it would be useful to log how long NGINX took to read the HTTP query packets
>> too. Using tcpdump and a script to analyze the packet dump is not very
>> handy. So I'm wondering if there is a mechanism in NGINX to report somehow
>> the total time necessary to read all the packets of a particular HTTP query?
>> I was thinking that if available, I could add it to the HTTP query in the
>> form of an HTTP header? If not, how easy would it be to implement such a
>> mechanism?
> What about $request_time [1]?

Does not seem to do what the GP asked, from the docs:

$request_time
request processing time in seconds with a milliseconds resolution 
(1.3.9, 1.2.6); time elapsed since the first bytes were read from the client

Instead as i readed the question, the GP wants to know the difference 
betweeen the first request packet and last request packet coming from 
the client. Not sure if it can be obtained (hope i'm wrong). At least 
when it's a new tcp connection (first http request from the client, no 
keepalive) that means that you have to know when a SYN packet came, but 
that is something that only the TCP stack knows.

Having a look at a strace of a live nginx, the new connection call 
sequence is:

accept4
recvfrom
[...]
recvfrom


Maybe the sum of the delays between revcfrom calls in a single request 
can do, maybe somebody can come with a patch.

As a sidenote, this other nginx variables seem interesting too:

from http://nginx.org/en/docs/http/ngx_http_core_module.html :

$tcpinfo_rtt, $tcpinfo_rttvar, $tcpinfo_snd_cwnd, $tcpinfo_rcv_space
information about the client TCP connection; available on systems that 
support the TCP_INFO socket option



>
> Lukas
>
>
> [1] http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_time 		 	   		
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

Frederik