NGINX module reporting 0 time to access.log

Server NGINX
1

Hey all,

We’ve written a module to connect NGINX / OpenResty with ZMQ endpoints
(GitHub - neloe/ngx_zmq: An upstream ZeroMQ module for nginx), but all requests through the module
report a 0.000 time back to access.log, making it impossible to
determine
which of our subsystems is the problem area in terms of latency. Is
there a
flag or callback somewhere that needs to be implemented in order to
report
this time properly?

Semi-related to the issue above… We’re seeing an odd behaviour where
we
get idle CPUs but 2s-120s oscillating latencies. Flame graphs reveal
we’re
spending most of our time in nginx’s http handler and epoll waiting, but
I’m
not sure what else I expect them to say.

Any help or advice is greatly appreciated.

Thanks!

  • Chase Holland

Posted at Nginx Forum:

2

On Monday 01 December 2014 22:09:14 chase.holland wrote:

Hey all,

We’ve written a module to connect NGINX / OpenResty with ZMQ endpoints
(GitHub - neloe/ngx_zmq: An upstream ZeroMQ module for nginx), but all requests through the module
report a 0.000 time back to access.log, making it impossible to determine
which of our subsystems is the problem area in terms of latency. Is there a
flag or callback somewhere that needs to be implemented in order to report
this time properly?
[…]

The whole code is one big problem. It just blocks a worker process on
network
IO and endless loops. You should never write code this way in nginx.

wbr, Valentin V. Bartenev

3

Valentin V. Bartenev Wrote:

there a

nginx mailing list
[email protected]
nginx Info Page

Hi Valentine,

Thank you for your quick response! Could you be more specific on what is
blocking the worker process? Does an instance of an nginx module only
get
one context per process (thus we need to do our own threading), or is
each
instance of the module thread-based to match nginx’s threads?

Thanks!

  • Chase Holland

Posted at Nginx Forum:

4

Hello!

On Tue, Dec 2, 2014 at 12:57 PM, chase.holland wrote:

Thank you for your quick response! Could you be more specific on what is
blocking the worker process?

Just FYI: you can always find the blocking IO calls via tools like the
off-CPU flame graphs:

Does an instance of an nginx module only get
one context per process (thus we need to do our own threading), or is each
instance of the module thread-based to match nginx’s threads?

Nginx worker processes are single-threaded. For any I/O operations,
you should use nonblocking IO mode and solely rely on the nginx event
loop to dispatch any IO events for your fd’s. Otherwise your nginx
will just degrade to the Apache’s prefork mpm.

(BTW, use of your own OS threads to work around such things will just
degrade your nginx’s performance to Apache’s worker mpm.)

Regards,
-agentzh