Manlio,

Yes, I see what you're saying. It is always going to be a problem if the listener cannot consume the data fast
enough. In any case, if you really dig deep, you can see that NGINX is asynch in that it
always reads from a socket only when it is ready to be read
(select/poll/epoll/kevent etc fires). But, as you know, NGINX uses non-blocking sockets. So when it wants to write to a socket (as far as my limited understanding goes),
it doesn't wait for it to be ready-to-write. It just goes and does a write to
the socket. If the kernel deems that the write would have blocked, it will
return EAGAIN (see send(2)) , rather than block the caller, if that's what
you're worried about.

Yes, with the speed and volume of debugging calls, it is likely that NGINX may
need a memory buffer to hold the debug logs till the socket can be written to,
but then, I guess that is overkill.

As someone pointed out, logging is one thing, profiling is quite another, and
monitoring is yet something else. Different needs.

But think about it. Agreed that NGINX is astonishingly fast in every aspect of
the game, but the ability to log to a socket can, at the very least, provide
centralized logging in cases where maybe several nginx proxies sit behind a load
balancer. The value of such a centralized log, IMHO can be a very good argument
for extending the support to log to a socket.

And it isn't as if NGINX needs to be configured by default to write to a socket.
I'm sure if ppl wish to configure it that way, they should understand that NGINX
should expect the log-consumer process to be fast enough.

Also, again off topic, what's NGINX performance when log files reside on an NFS
(or CIFS, etc) partition ? Has anyone tested that ? I should imagine that the
reliability of the network will affect NGINX ngx_log_* times

Regards, Mansoor