3 ms·

Really, it isn't too hard to patch the logging in nginx and/or have a named pipe that writes to syslog. My team made a patch to have it log to UDP multicast, an

by cbsmith 13y ago

Really, it isn't too hard to patch the logging in nginx and/or have a named pipe that writes to syslog. My team made a patch to have it log to UDP multicast, and it wasn't too bad. If you're really pissed at the nginx guys, contribute the patch back. Sure, I quibble with their approach to a commercial model, but I really think this is a case of "me thinks she doth protest too much" in both the literal and implied meaning.

donavanm 13y ago
> Really, it isn't too hard to patch the logging in nginx and/or have a named pipe that writes to syslog. Be careful with high performance expectations on named pipes. The fifo is in memory, but the inode is on disk. It really sucks to block on stat() and friends when you dont expect it. Oh! And those FIFOs act as a 64kb buffer. Need more buffering? Put another pipe on it!
- cbsmith 13y ago
  syslog is also a syscall, and has limited buffering. A named pipe can actually potentially amortize overhead more effectively. (And just because an inode is involved does not mean that a call to stat() involves a trip to disk.) If you are really worried about buffering, you can always have a consumer of the named pipe with its own buffering before writing to syslog (yes, that can get ugly). In a perfect world, I'd actually prefer to write to a ring buffer in shared memory (one per worker to avoid too much contention) and then have another process that empties it as fast as it can. Either way, it's actually not that hard to hack in to nginx. If someone were to contribute a patch that did logging the "right" way and host it on say... github, I think you'd find the nginx commercial folks would have a response that works out pretty well for everyone. The catch is, it requires someone to do something.
ars_technician 13y ago
They wouldn't take it because it competes with the enterprise features. Do you see why this model is fundamentally incompatible with open source now?
- cbsmith 13y ago
  As I said, I have quibbles with their commercial model. I get the problem. In reality though, you can always fork, which puts pressure on them to embrace desirable patches if they are provided from outside, and to move their enterprise features into the main branch. If they keep stuff out of the their main branch that people can route around, it significantly reduces the commercial value they can realize.

by cbsmith 13y ago

donavanm 13y ago

> Really, it isn't too hard to patch the logging in nginx and/or have a named pipe that writes to syslog. Be careful with high performance expectations on named pipes. The fifo is in memory, but the inode is on disk. It really sucks to block on stat() and friends when you dont expect it. Oh! And those FIFOs act as a 64kb buffer. Need more buffering? Put another pipe on it!

cbsmith 13y ago
syslog is also a syscall, and has limited buffering. A named pipe can actually potentially amortize overhead more effectively. (And just because an inode is involved does not mean that a call to stat() involves a trip to disk.) If you are really worried about buffering, you can always have a consumer of the named pipe with its own buffering before writing to syslog (yes, that can get ugly). In a perfect world, I'd actually prefer to write to a ring buffer in shared memory (one per worker to avoid too much contention) and then have another process that empties it as fast as it can. Either way, it's actually not that hard to hack in to nginx. If someone were to contribute a patch that did logging the "right" way and host it on say... github, I think you'd find the nginx commercial folks would have a response that works out pretty well for everyone. The catch is, it requires someone to do something.

ars_technician 13y ago

They wouldn't take it because it competes with the enterprise features. Do you see why this model is fundamentally incompatible with open source now?

cbsmith 13y ago
As I said, I have quibbles with their commercial model. I get the problem. In reality though, you can always fork, which puts pressure on them to embrace desirable patches if they are provided from outside, and to move their enterprise features into the main branch. If they keep stuff out of the their main branch that people can route around, it significantly reduces the commercial value they can realize.