Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We Should Ditch Nginx

hipyoungstartup.com

Post reply on HN
Print view View original

31–40 of 176 posts

Re: We Should Ditch Nginx

#31

Post by gnaritas »

DigitalSea wrote: post #24
ridruejo wrote: post #15

Apache 2.4 with event MPM should give you comparable performance to nginx

Performance is pretty good in Apache 2.4, but compare RAM usage alongside NGINX and you'll notice that NGINX's event based threads approach takes a big dump all over Apache's separate process lets consume every bit of available RAM the server has until it starts throwing errors and filling log files. Apache is getting better, but it's not really on par with NGINX (yet, but it will be).

You didn't hear what he said, he's specifically not talking about the memory hogging process bases mpm. You seem to think Apache only works that way, but the worker modules are pluggable.

Re: We Should Ditch Nginx

#33

Post by DigitalSea »

gnaritas wrote: post #31
DigitalSea wrote: post #24

Earlier quoted context omitted.

Performance is pretty good in Apache 2.4, but compare RAM usage alongside NGINX and you'll notice that NGINX's event based threads approach takes a big dump all over Apache's separate process lets consume every bit of available RAM the server has until it starts throwing errors and filling log files. Apache is getting better, but it's not really on par with NGINX (yet, but it will be).

You didn't hear what he said, he's specifically not talking about the memory hogging process bases mpm. You seem to think Apache only works that way, but the worker modules are pluggable.

He's talking about Apache MPM Worker which while offering better performance over the traditional Apache MPM Prefork because it's threaded based like NGINX is, it still consumes more RAM than NGINX does, so my point remains...

Re: We Should Ditch Nginx

#34

Post by icambron »

jacques_chester wrote: post #23

This blog post demonstrates why the syslog feature is ideal for segmenting Nginx's market. Almost nobody cares about it, except the sort of place doing > tens of millions of requests per day. The sort of place that might have some money and the scale to realise that a few thousand bucks is cheaper than a bunch of engineer time. It's a good case study in smart pricing.

This. From the article:

>I don’t blame NGINX for wanting money in exchange for what is admittedly amazing software. I just don’t want any part of it.

Why not? You're using this awesome software whose value you appreciate and which is, you admit, open source. It's just not convenient enough for you. So why can't you pony up the money for your huge, high-traffic website?

Re: We Should Ditch Nginx

#35

Post by donavanm »

cbsmith wrote: post #27

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 mea…

> 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!

Re: We Should Ditch Nginx

#36

Post by voltagex_ »

Gigablah wrote: post #7

> Fork it. Well, there's a fork of nginx called Tengine, made by the Taobao folks: http://tengine.taobao.org/document/http_log.html

From a (very) brief glance, it looks like you could almost pull this code back into the open source version on nginx. https://github.com/alibaba/tengine/blob/master/src/http/modu...

Re: We Should Ditch Nginx

#37

Post by dknecht »

CloudFlare generates 50gb/s of logs globally and have handled collecting this volume in two ways. Historically the logs are sent to a local syslog-ng through the use of a PIPE and the forwarded to central logger. This can be done with nginx with no patches by just treating the PIPE as file. Just make sure you do a little buffering inside nginx.

access_log /dev/nginx_access log_format_name buffer=64k flush=10s;

Since this is a pipe there is still some blocking IO, but no worse off then writing to local file.

The way we are migrating will be non-blocking IO through the use of Lua Resty log module ( https://github.com/cloudflare/lua-resty-logger-socket ).

We will write up a blog post at some point but hopefully this is useful to you. In the future we are going to be going one step further and have NGINX emit protobuff files. Feel free to email dane AT cloudflare.com if you have any questions.

Re: We Should Ditch Nginx

#38

Post by ams6110 »

secstate wrote: post #12
skj wrote: post #4

Earlier quoted context omitted.

This position is without merit. People have every right to say that one particular free option is not what they're looking for, and explain why it's not what they're looking for.

While I agree with your statement on it's face, in the context of the OP, this is just whinging. The author is not just offering constructive criticism on a possible fork of NGINX, he's calling the NGINX business out for "withholding" features. The tone is distinctly one of being "owed" a feature common to another popular FOSS project, instead of being grateful for everything NGINX provides (which is a lot, and proba…

And using it for his own commercial purposes to boot. Really comes across as a crybaby.

Re: We Should Ditch Nginx

#39

Post by neya »

Not relating to the Author's opinion, I would just like to know if there's a legitimate, competent competitor to Nginx apart from Apache? Just curious as I've already had a bad experience with monopolies in the past.

Re: We Should Ditch Nginx

#40

Post by _aucc »

I wonder if:

A) The author is using a load balancer that can do centralised logging in a sane fashion perhaps they can turn off end logging on nginx all together.

B) The author has looked in to the Lua nginx scripting capabilities for direct logging without touching disk.

C) Place a greater emphasis on SaaS logging with javascript on the client side.

It sounds as if their architecture needs a massive re-think.

Post reply on HN