Hacker News Reader

Comment by gnaritas | Hacker News Reader

People have been and still do exactly the same thing with Apache, this isn't unique to Nginx in any way.

Except the configuration is far simpler with Nginx. What's more, you can even couple this with upstream weighted loadbalancing or round-robin which is terribly awkward without modules on Apache.

Edit: Not to mention sticky sessions per proxy which simplifies user management.

Simpler, yes, that doesn't make Apache complicated. They're all simple. To say without modules makes no sense, modules are how Apache does features and the mod balance module makes all of that simple including sticky sessions. If you can write code, you can configure Apache easily.

"Simpler, yes, that doesn't make Apache complicated. They're all simple."

Didn't you just contradict yourself? How can it be simpler and all be simple? Simpler implies one is greater in simplicity so which is it?

FWIW, we were running Apache 1.3 with patches on OpenBSD. For us, using the 2.x branch wasn't possible without staying atop the modules for code issues/vulnerabilities. Considering other client expectations, we didn't have the resources to audit everything like that. The fact that OpenBSD 5.2 included Nginx by default was a nice plus for us too, but we started the move before then.

Where's the contradiction? He says that Nginix is simpler than Apache, which is also simple.

"which is it?"

He just said which one it was. I don't see how anyone could fail to understand this.

> Didn't you just contradict yourself?

No, I did not.

> How can it be simpler and all be simple? Simpler implies one is greater in simplicity so which is it?

Is English not your first language? I can choose 5 simple things, and then compare them to each other and say one is simpler. They're all still simple.

> FWIW, we were running Apache 1.3 with patches on OpenBSD. For us, using the 2.x branch wasn't possible without staying atop the modules for code issues/vulnerabilities.

Sounds like your OS was the real culprit for not keeping up with newer releases. Again, if Nginx works for you, great, you can promote that without putting down Apache which is quite simple and rock solid stable as well.

Insulting me is a pretty poor way of being persuasive. And English is my first language, thank you.

As someone who's apparently more fluent than I am in English, you should have noted that I'm not "putting down" Apache as much as showing that, out of the box, Nginx still is a better option than Apache. This isn't my opinion as much as it is empirically observed fact both in our environment as well as our clients' environments.

> Insulting me is a pretty poor way of being persuasive.

I didn't insult you, it was an honest question as I can't assume everyone here is a native English speaker and your confusion could have easily been a language thing.

> And English is my first language, thank you.

OK, great, then I don't know what was at all confusing about what I said.

> Apache as much as showing that, out of the box, Nginx still is a better option than Apache.

Such blanket statements are simply unsupportable. It depends entirely on the workload, needs, language, and configuration. Out of the box, Apache isn't configured for the process model that everyone complains makes it a pig.

You have been downvoted, lol.

This is the stupid HN system at work: Someone who doesn't understand English being a native speaker (simple vs simpler) can downvote you because he has "earned" that right, by submitting a gazillion articles with 1 point each.

I didn't downvote anyone on this thread. In fact, you can't downvote anyone who has replied to you or anyone you're replying to you. Article submissions are for everyone to read whether they're voted for or not. I frequently browse /newest because I see articles that never make the front page, that I enjoy regardless and I want to share what I find interesting.

While you're here, you may want to take a browse on the guidelines http://ycombinator.com/newsguidelines.html

>Sounds like your OS was the real culprit for not keeping up with newer releases.

Newer releases are quite bad from both a security and a stability standpoint. They did not make configuration simpler, so the idea that using the last reasonable release of apache was the problem doesn't make any sense.

'm not a native English speaker, but I might as well be because of my proficiency. The way you formulated those two sentences was a bit off putting for me, too.

There was no need to be rude.

> How can it be simpler and all be simple? Simpler implies one is greater in simplicity so which is it?

Two feet is not very far to walk. Three feet is farther, but it is still not a great distance to walk. Two things can both be short/simple even if one is a bit shorter/simpler.

There's no contradiction in his/her statement. You are just being obtuse

Either Nginx and Apache is pain in the ass to configure. No need to mention both have some unix challenges that you gotta solve for just starting to serve bunch of stupid shit. Have a look at boxcars

I installed Apache recently along with ownCloud on my Raspberry Pi. I had to strip it back out when I realized that Apache worker processes were keeping the CPU and RAM at 100% the entire time, when nothing was even connected to it.

I used to use Apache all the time way back when. The memories that stick with me are of a massive tangle of configuration rules, mod_*, and htaccess files. I've never looked back since going the way of Nginx. It's just so lightweight in comparison, both performance- and maintenance-wise.

That a bug. Probably an architecture dependant one or some package maintainer who messed up. Your experience with Apache httpd on your little homebrew computer gadget doesn't say anything about Apache httpd and how it is usually deployed.

Apache httpd is still bloody awesome.

Let me explain you what buggy means. Buggy means heavy, overweight, with thousands of configuration lines just to end up with something slow and crashing.

As stated in the same comment, my "little homebrew computer gadget" wasn't the only platform I've run Apache httpd on. It was just yet another environment in which it came out as sub-optimal when compared with Nginx in the same use case.

I don't think it's fair to use the rPi as your case-study. You would be hard-pressed to find a complete modern computer that is more different from the typical machine that runs httpd in a commercial environment.

As I said, the Raspberry Pi isn't the only platform I've run Apache httpd on, and that experience isn't the primary motivating factor behind my dislike for the software.

It just struck me how starkly the difference in resource consumption between it and Nginx was illustrated in that case in particular, as the rPi handles the latter just fine.

Sounds like something isn't right. You might have a setup where everything is enabled (at least from a high memory consumption point of view). You can get the Apache child processes down to ~2MiB (still a bit high by lighttpd and nginx standards) by disabling a lot of the modules. How many child processes started by default? Check your mpm settings, as you could be using the configuration for a beefy server environment.

He did start his comment with "For my style of coding". Maybe it's just simpler to configure these rules in Nginx than it is in Apache for lkrubner.

The problem is that he says Nginx enabled fast reverse proxy and that's just not true, nothing he described was enabled by Nginx, that was how people already did things in Apache. Apache is not hard to configure, it would support his style of coding just fine and very likely work just as well as Nginx for him.

The problem people have with Apache usually isn't really apache, it's with PHP forcing them to use the process based mpm which makes it a pig. This is PHP's fault, not Apache's. use the threaded or evened worker mpm's and it's not a pig at all.

Yes. It is remarkably simple to set up reverse proxies in nginx.

It is also remarkably easy to set up SSL (minus generating certificates) -- it's only 3 lines.

It's just as easy in Apache.

...No it isn't. It might be 'simple' for you, and it might be readily configurable once you know how to do it, but that doesn't make it easy.

I really can't tell if you're being deliberately obtuse about this. Don't you see all the people going "Yeah, it was faster to do this with nginx than it was with Apache"?

Are you the sort of person that's surprised PHP got so popular?

Oh, come on. It's pretty simple. You google a bit around for it and find some 3 year old blog post that tells you what to do. You'd probably have to do the same for nginx anyway.

I prefer nginx' configuration syntax over apache's though.

... hahaha exactly.

I didn't say it wasn't simple. But simple is just sufficiently managed complexity.

I'd like to point out that my first point was specifically towards reverse proxying...

This page should be all the proof I need: http://www.apachetutor.org/admin/reverseproxies

where as reverse proxies in nginx: http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.h...

So maybe you could make a case for nginx being less modular (or obviously so) -- but 1 config files with the right magic spell beats downloading x module and setting up x directory PLUS the magic file.

Also, I think that in general, nginx fits more into the many-apps-different-implementations-same-server vision of the modern day web app.

That would be pretty bad proof though. If you ignore the chit-chat, which is just the authors writing style, and the ugly colour scheme, the essential part is here: http://www.apachetutor.org/admin/reverseproxies#d13

That's 26 lines of configuration, compared to the nginx example, which is 54 lines. Both are kind of arcane looking, if you haven't used it before.

oh but what about installing the modules/files that are getting loaded?

True, they're not night and day, but it's still stuff to do. Also, the page I sent, the actual reverse proxy is only 14 lines, half of it is extra stuff... The section where it says "start with example.com".

And that's the whole server, whereas the

> Don't you see all the people going "Yeah, it was faster to do this with nginx than it was with Apache"?

Configuring Apache is easy as there are tens of thousands of tutorials showing you exactly how to add those two little lines of code to enable proxy and/or a cert. Both Apache and Nginx are easy to configure, Nginx is easier, that doesn't make Apache hard.

> Are you the sort of person that's surprised PHP got so popular?

Nope, I've worked with tons of PHP developers and I know exactly why it's popular. Wide support, easy copy to server deployment, and in large part, dumber programmers who want you to give them the codes because it's a copy and paste community in large part. All languages have a wide variety of users, but I've found the worst of the worst go to PHP like a month to a flame exactly because it's so simple to get started and despite how terrible a language it is.

I think of PHP as a templating language, to be honest. I like it (I still think the LAMP stack is cool), but the kind of code that it forces you to produce is often focused around document generation (as was the majority of the internet for a long time).

Maybe it's just the wrong tool for this time, and it used to be right tool in the past.

It is definately simpler to configure Nginx to reverse proxy, Apache needs a few more lines of configuration.

From http://httpd.apache.org/docs/2.2/mod/mod_proxy.html:

ProxyPass /foo http://foo.example.com/bar ProxyPassReverse /foo http://foo.example.com/bar

I've used it for years, it's not hard.

I was talking about installing Apache and setting it up as a reverse proxy vs. installing Nginx and setting it up as a reverse proxy. Nginx takes less configuration in that scenario. I've done both and neither are hard, but nginx is slightly easier.

Installing Apache is a single command, enabling mod proxy is a single command and two lines of config. So yes, they are both trivially simple to do, even if Nginx is slightly simpler. Neither should be seen as a barrier of complexity.

For the simple case Apache is only 2 lines. Nginx requires more, because Apache automatically sets the proxy headers and Nginx does not.

http://d-e-f-i-n-i-t-e-l-y.com/

Reply on news.ycombinator.com