Hacker News new | past | comments | ask | show | jobs | submit login

You're arguing against several strawmen of your own invention. Preforking is still forking, for one. Under heavy load you're forking to keep up with new connections while existing processes are tied up very slowly serving responses to bandwidth constrained clients. Also, I never claimed forking is expensive. I said it's expensive compared to an event loop. Correcting things I didn't say might feel good but you're just lying to yourself. Regurgitating what you've read about how Linux processes and clone() works is stereotypical sysadmin bloviating.

Several other things you say are equally wrong. Claiming that Apache has been away from a process model for decades is dishonest. It's not even decades old and the Apache project itself contradicts you.

Preforking is still recommended for "sites requiring stability" and is in (most?) common usage http://httpd.apache.org/docs/current/mpm.html

> The server can be better customized for the needs of the particular site. For example, sites that need a great deal of scalability can choose to use a threaded MPM like worker or event, while sites requiring stability or compatibility with older software can use a prefork.

Your religious devotion to Apache and claim that "Apache is fast enough" ignores the reality of what nginx can do with so much less CPU and memory. It's not a technical argument but a religious one. Nginx is good enough. Apache is not. It never was, people have lived with it for too long because people like yourself buried their heads in the sand. You're still doing it.




> Preforking is still forking, for one. Under heavy load you're forking to keep up with new connections while existing processes are tied up very slowly serving responses to bandwidth constrained clients.

No, that's not strictly true. If you have min & max servers fixed at the same value and the max requests per child set absurdly high, you won't fork much if at all under heavy load. Pre-forking can result in a lot of forking and requests being blocked while you fork if a) you have a surge in traffic and b) your min servers isn't set high enough to cover the surge or alternatively c) your max requests per child is low enough that you are constantly having processes exit.

> I never claimed forking is expensive. I said it's expensive compared to an event loop.

Agreed, although that's kind of a meaningless statement (an event loop is something you go through on a per-request basis), and misses the real problem with the multi-process model: virtual address space for each process.

> It's not a technical argument but a religious one. Nginx is good enough. Apache is not.

Umm... that sounds like a religious argument in its own right. Apache is certainly good enough for plenty of people, and more importantly with all the dynamic content on sites, the web server tends to be a pretty unimportant factor in the performance of many sites. Apache brings other things to the table which are often valued for projects, and there is no reason that needs to be considered a "religious" decision.


> I never claimed forking is expensive. I said it's expensive ... yeah, no that seems to be exactly what you are saying. just nitpickinkg.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: