Comments on: Long live Apache; Why NginX is the next king of httpd - and Lighttpd needs a little more work http://jetfar.com/apache-nginx-lighttpd-future-compared/ Django, Python, Geo, Web, Entrepreneurship Thu, 21 Aug 2008 02:43:56 +0000 http://wordpress.org/?v=2.6-bleeding2 By: Nuno Mariz http://jetfar.com/apache-nginx-lighttpd-future-compared/#comment-103 Nuno Mariz Fri, 23 May 2008 10:29:11 +0000 http://dev.manlynsw.com/wp/?p=23#comment-103 I've had the same problem with my VPS(s) and I'm a django user too. Right now I'm using Nginx(or lighttpd in some machines) to serve static content and apache mpm worker to serve my applications. So far I'm pretty happy with it, the memory footprint was reduced and the stability is intact. I’ve had the same problem with my VPS(s) and I’m a django user too.
Right now I’m using Nginx(or lighttpd in some machines) to serve static content and apache mpm worker to serve my applications.
So far I’m pretty happy with it, the memory footprint was reduced and the stability is intact.

]]> By: rich http://jetfar.com/apache-nginx-lighttpd-future-compared/#comment-18 rich Thu, 27 Mar 2008 21:06:18 +0000 http://dev.manlynsw.com/wp/?p=23#comment-18 Hi Vic, Thank you kindly. I should point out that since then there are a couple of points to update. 1) My experiences with nginx were excellent. The only slight complication is you need to manage your own fcgi processes, you can borrow some handy tools to do this from the lighttpd distro. 2) Despite my good experiences, and probably because I'm a bit of a geek, I've given Graham's modwsgi2 a shot - which meant changing to apache. 3) I'm using worker mpm with 2-6 processes of 25 threads, and 1 mod_wsgi daemon per apache process. 4) This uses only slightly more memory than nginx did, and theoretically should scale to my needs. 5) I haven't load tested this new config yet. 6) I've ported this blog from super-slooow dreamhost to my slice - and it's page load times are 1/10th of what they were. This is using php5 via fastcgi 7) Apache fcgi is easier because the spawning is taken care of nicely 8) Guess I should write another post! - rich Hi Vic,
Thank you kindly.

I should point out that since then there are a couple of points to update.

1) My experiences with nginx were excellent. The only slight complication is you need to manage your own fcgi processes, you can borrow some handy tools to do this from the lighttpd distro.

2) Despite my good experiences, and probably because I’m a bit of a geek, I’ve given Graham’s modwsgi2 a shot - which meant changing to apache.

3) I’m using worker mpm with 2-6 processes of 25 threads, and 1 mod_wsgi daemon per apache process.

4) This uses only slightly more memory than nginx did, and theoretically should scale to my needs.

5) I haven’t load tested this new config yet.

6) I’ve ported this blog from super-slooow dreamhost to my slice - and it’s page load times are 1/10th of what they were. This is using php5 via fastcgi

7) Apache fcgi is easier because the spawning is taken care of nicely

8) Guess I should write another post!

- rich

]]> By: Vic http://jetfar.com/apache-nginx-lighttpd-future-compared/#comment-17 Vic Thu, 27 Mar 2008 11:10:47 +0000 http://dev.manlynsw.com/wp/?p=23#comment-17 Rich, We have been living through *Severe* VPS performance problems for one of our projects for quite some time now. Based on what you've described above, I'm tempted to give NgineX a try. Thanks for the nice article and analyses. (BTW, clarity of diction is usually not considered to be the strongest of points amongst 'techies' - your writing really shines from this perspective too. :-)) Best wishes. Vic Rich,

We have been living through *Severe* VPS performance problems for one of our projects for quite some time now.
Based on what you’ve described above, I’m tempted to give NgineX a try.

Thanks for the nice article and analyses.
(BTW, clarity of diction is usually not considered to be the strongest of points amongst ‘techies’ - your writing really shines from this perspective too. :-))

Best wishes.

Vic

]]> By: Graham Dumpleton http://jetfar.com/apache-nginx-lighttpd-future-compared/#comment-7 Graham Dumpleton Wed, 05 Mar 2008 09:04:48 +0000 http://dev.manlynsw.com/wp/?p=23#comment-7 The important thing to remember is that there is more than just performance. People get hung up on trying to find what they think is the fastest hosting solution. In practice though, the difference in performance between different hosting solutions for typical large applications using Django or other Python frameworks is less than a few percent when one looks at the total overhead of the application. In other words the bottleneck isn't the hosting solution but the application and any database it talks to. Thus it is more important to find a solution which you are simply happy with, meeting your reliability requirements and that you at least find easy to configure and manage. That is all that is really important. Sure if you have got the next YouTube then performance is an issue, but very people would be in that situation. Anyway, have fun investigating the different solutions. Given you have a memory constrained VPS, as far as Apache goes I would recommend worker MPM, and run Django in 1 or 2 separate multithreaded processes using mod_wsgi daemon mode. This is best for keeping memory usage down. Because you would be using multithreading, just need to make sure your application is multithread safe. There have been a number of discussions in the past about memory constrained VPS systems on the Google group for mod_wsgi. The important thing to remember is that there is more than just performance. People get hung up on trying to find what they think is the fastest hosting solution. In practice though, the difference in performance between different hosting solutions for typical large applications using Django or other Python frameworks is less than a few percent when one looks at the total overhead of the application. In other words the bottleneck isn’t the hosting solution but the application and any database it talks to. Thus it is more important to find a solution which you are simply happy with, meeting your reliability requirements and that you at least find easy to configure and manage. That is all that is really important. Sure if you have got the next YouTube then performance is an issue, but very people would be in that situation.

Anyway, have fun investigating the different solutions. Given you have a memory constrained VPS, as far as Apache goes I would recommend worker MPM, and run Django in 1 or 2 separate multithreaded processes using mod_wsgi daemon mode. This is best for keeping memory usage down. Because you would be using multithreading, just need to make sure your application is multithread safe. There have been a number of discussions in the past about memory constrained VPS systems on the Google group for mod_wsgi.

]]> By: rich http://jetfar.com/apache-nginx-lighttpd-future-compared/#comment-6 rich Wed, 05 Mar 2008 05:52:11 +0000 http://dev.manlynsw.com/wp/?p=23#comment-6 Hi Graham, Thank you for stopping by and for leaving a comment. You know - I had noticed modwsgi in my browsing, but I am guilty of not really having given it fair consideration. Thank you for bringing it to my attention; I notice that it's a topic close to your heart - I promise to look more closely in the coming weeks. I personally believe that removing any *moving part* from a configuration (eg: flup) is in principle, a very good thing. I will try mod_wsgi. I will certainly be doing some more organised load testing before launch, I would be missing out if I didn't give modwsgi a good thrashing at the same time. I also noticed this: http://wiki.codemongers.com/NginxNgxWSGIModule They do say imitation is the strongest form of flattery! (PS: I certainly haven't given up on Apache - but I am amazed at the capacity you can squeeze from a 256MB VPS if you really try) - rich Hi Graham,
Thank you for stopping by and for leaving a comment.

You know - I had noticed modwsgi in my browsing, but I am guilty of not really having given it fair consideration. Thank you for bringing it to my attention; I notice that it’s a topic close to your heart - I promise to look more closely in the coming weeks.

I personally believe that removing any *moving part* from a configuration (eg: flup) is in principle, a very good thing. I will try mod_wsgi. I will certainly be doing some more organised load testing before launch, I would be missing out if I didn’t give modwsgi a good thrashing at the same time.

I also noticed this: http://wiki.codemongers.com/NginxNgxWSGIModule

They do say imitation is the strongest form of flattery!

(PS: I certainly haven’t given up on Apache - but I am amazed at the capacity you can squeeze from a 256MB VPS if you really try)

- rich

]]> By: Graham Dumpleton http://jetfar.com/apache-nginx-lighttpd-future-compared/#comment-5 Graham Dumpleton Wed, 05 Mar 2008 05:13:51 +0000 http://dev.manlynsw.com/wp/?p=23#comment-5 Hmmm, since you have read my comments, am surprised you haven't also stumbled across mod_wsgi. For hosting WSGI applications capable applications (such as Django) embedded in Apache, mod_wsgi is faster than mod_python and has less memory overhead. The mod_wsgi module also incorporates a daemon mode such that one can get the same sorts of benefits of fastcgi but in a more self contained package that doesn't require a separate adapter such as flup. Daemon mode of mod_wsgi even runs faster than mod_python even though separate processes are used. So, don't give up on Apache just yet. :-) Hmmm, since you have read my comments, am surprised you haven’t also stumbled across mod_wsgi. For hosting WSGI applications capable applications (such as Django) embedded in Apache, mod_wsgi is faster than mod_python and has less memory overhead. The mod_wsgi module also incorporates a daemon mode such that one can get the same sorts of benefits of fastcgi but in a more self contained package that doesn’t require a separate adapter such as flup. Daemon mode of mod_wsgi even runs faster than mod_python even though separate processes are used.

So, don’t give up on Apache just yet. :-)

]]>