ngx.update_time / ngx.time

[Aapo Talvensaari]

Hi,

How does the Lua Nginx time cache work? How long the value is cached? I mean that when it is worth to call ngx.update_time? ngx.time-related functions seem to be 1 second in granularity. Is the cache held more than a second?

Regards

Aapo

[Robert Paprocki]

It pulls from the ngx core. The internal core saves a millisecond-precision value for the current time. See https://www.cryptobells.com/openresty-time-resolution-with-ffi-a-more-accurate-approach/ for a few more details on ngx time structs. 

--
You received this message because you are subscribed to the Google Groups "openresty-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aapo Talvensaari]

On Tuesday, 21 April 2015 17:05:43 UTC+3, rpaprocki wrote:

It pulls from the ngx core. The internal core saves a millisecond-precision value for the current time. See https://www.cryptobells.com/openresty-time-resolution-with-ffi-a-more-accurate-approach/ for a few more details on ngx time structs.

Is there any reason to _ever_ call ngx.update_time. ngx.now is the most precise time source there is available on ngx.*, and it is millisecond in precision. If nginx core updates the cache for every millisecond, there doesn't seem any effect on calling ngx.update_time. So my question is: is there a use case for it (or have I understood something wrong)? If it really doesn't have any uses I propose to make it no-op then, :-).

[Robert Paprocki]

Nginx core doesn't update the cache every millisecond- that's the point if it being cached, to avoid an expensive syscall. 

One use case I can imagine would be very crude profiling wherein you log the time stamp from ngx.now() at the beginning of your code run, then print the real runtime by calculating the diff between the first value and a new call to ngx.now(); that second call would need to be prefaced by update_time(), otherwise the diff would be zero (and I'm sure agentzh will yell at me for suggesting such a terrible way to profile run time ;) ). 

--

[Aapo Talvensaari]

On Wednesday, 22 April 2015 04:13:48 UTC+3, rpaprocki wrote:

Nginx core doesn't update the cache every millisecond- that's the point if it being cached, to avoid an expensive syscall.

The question remains.... how long Nginx holds the value in a cache? More than a millisecond? Less than a second? 

[mex]

Hi Aapo,


http://forum.nginx.org/list.php?2 might help

[Aapo Talvensaari]

On Wednesday, 22 April 2015 10:33:26 UTC+3, mex wrote:

http://forum.nginx.org/list.php?2  might help

I tried the search already, but couldn't find the answer (maybe I just didn't spot it).

So the question (still remains) is how precice time can you expect from ngx.now if you are _not_ calling ngx.update_time (when it is updated, what's the mechanism behind the scenes)?

[mex]

you can ask this questions to the nginx-gyus directly though
the forum, which is just a frontend to the nginx-mailinglist

usually the nginx-team is very responsive to technical questions

[Aapo Talvensaari]

On Wednesday, 22 April 2015 11:11:22 UTC+3, mex wrote:

you can ask this questions to the nginx-gyus directly though
the forum, which is just a frontend to the nginx-mailinglist

Tried to ask it on IRC, but no answer. I started to dig through nginx sources, and found that this is actually configurable:

http://nginx.org/en/docs/ngx_core_module.html#timer_resolution 

[Yichun Zhang (agentzh)]

Hello!

On Wed, Apr 22, 2015 at 7:31 PM, Aapo Talvensaari wrote:
> I started to dig through nginx
> sources, and found that this is actually configurable:
>
> http://nginx.org/en/docs/ngx_core_module.html#timer_resolution
>

Configuring timer_resolution is not recommended because it suppresses
the cached time updates on every event cycle, leading to unnecessary
time lagging (or unnecessary epoll_wait/etc syscalls if set very small
resolution values).

By default, the nginx cached times are always updated upon new events
(being a timer expiry event or an I/O event from epoll/kqueue/etc). As
long as you are not doing extensive CPU-bound operations in nginx,
this strategy should produce quite accurate times for logging purposes
and etc.

So it's hard to say how long the time is cached without configuring
timer_resolution. Because the default strategy is adaptive and driven
by I/O events.

Regards,
-agentzh

[Aapo Talvensaari]

On May 7, 2015 15:26, "Yichun Zhang (agentzh)" <age...@gmail.com> wrote:
>
> Hello!
>
> On Wed, Apr 22, 2015 at 7:31 PM, Aapo Talvensaari wrote:
> > I started to dig through nginx
> > sources, and found that this is actually configurable:
> >
> > http://nginx.org/en/docs/ngx_core_module.html#timer_resolution
> >
>

> Configuring...

So the cache gets also updates for going on request if there is a new request coming on during the request processing, e.g. the time is updated (by the new events and also affects previously started but not finished ones when calling ngx.now etc.) also for requests that have already been started?

[Yichun Zhang (agentzh)]

Hello!

On Fri, May 8, 2015 at 2:57 AM, Aapo Talvensaari wrote:
> So the cache gets also updates for going on request if there is a new
> request coming on during the request processing, e.g. the time is updated
> (by the new events and also affects previously started but not finished ones
> when calling ngx.now etc.) also for requests that have already been started?
>

Yes. There can be multiple I/O events or timer expiring events during
an individual request's lifetime. And there must be at least one I/O
event for a newly created request (unless the request is so small that
it is preread into the previous request's receive buffers on the same
connection, which is pretty fine as well).

Well, it's the nature of event-driven I/O models ;)

Regards,
-agentzh