Hi Maxim,
On 09/11/2015 02:53 PM, Maxim Dounin wrote:
Hello!
On Fri, Sep 11, 2015 at 02:15:25PM +0200, Lukas Tribus wrote:
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
Hello!
On Fri, Sep 11, 2015 at 02:15:25PM +0200, Lukas Tribus wrote:
> > 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 clie
> 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
"request time" would imply the time (with our without parsing) of the
actual
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 notice
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 signific
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
bet
