Hi,
How is the $request_time calculated in the case of a proxied request.
I’m
interested especially in the case where the resource is stale in cache.
Thanks
Hello!
On Mon, Nov 21, 2011 at 08:41:15PM +0200, Calin D. wrote:
Hi,
How is the $request_time calculated in the case of a proxied request. I’m
interested especially in the case where the resource is stale in cache.
$request_time is always time since start of the request (when
first bytes are read from client) till end of the request (when
last bytes are sent to client and logging happens).
Maxim D.
So the time spent doing a post_action is added to $request_time or not?
On Mon, Nov 21, 2011 at 08:41:15PM +0200, Calin D. wrote:
On Mon, Nov 21, 2011 at 20:55, Maxim D. [email protected] wrote:
On Tue, Nov 22, 2011 at 11:52:29PM +0200, Calin D. wrote:
Hi there,
How is the $request_time calculated in the case of a proxied request. I’m
interested especially in the case where the resource is stale in cache.$request_time is always time since start of the request (when
first bytes are read from client) till end of the request (when
last bytes are sent to client and logging happens).
So the time spent doing a post_action is added to $request_time or not?
It seems straightforward enough to test.
Define a post_action in a location of (for example) a php script which
does sleep(3), then see if $request_time is 3 seconds bigger in that
location than elsewhere.
When I try it in a location which just serves static files, I do see
$request_time = 3.002 in access.log.
You can do the same in your stale-in-cache location.
Good luck,
f
Francis D. [email protected]
Hello!
On Tue, Nov 22, 2011 at 11:52:29PM +0200, Calin D. wrote:
So the time spent doing a post_action is added to $request_time or not?
Added.
In general, post_action is a dirty hack which works in context of
a request. It delays all processing of the request (i.e. logging)
as well as processing of furhter requests in the connection in
question (if any). This is one of the reasons why post_action
isn’t documented, BTW.
Maxim D.
So it is safe to use post_action then?
I’m relying on it to serve cached response for users and update cache
entry
in background if needed, so that users get most of the time a cache hit.
Is there a cleaner way to do this?
Hello!
On Wed, Nov 23, 2011 at 01:25:46PM +0200, Calin D. wrote:
So it is safe to use post_action then?
I’m relying on it to serve cached response for users and update cache entry
in background if needed, so that users get most of the time a cache hit.
It’s not expected to cause crashes and/or protocol violations. It
may have unexpected side effects though (e.g. it delays processing
of further requests in the connection, as I alredy outlined
below).
Is there a cleaner way to do this?
The way I would recommend is to use "tail -F /path/to/log |
". Maxim D. > > > > > > > > > $request_time is always time since start of the request (when > > > > > _______________________________________________ > > > nginx mailing list > > > [email protected] > > > http://mailman.nginx.org/mailman/listinfo/nginx > > > > _______________________________________________ > > nginx mailing list > > [email protected] > > http://mailman.nginx.org/mailman/listinfo/nginx > >