On Mon, 2007-10-22 at 23:24 +0000, Graham Dumpleton wrote: > The complexity I am referring to is not in configuring nginx, but that > you also have to install and configure some separate supervisor system > which starts up and ensures that your backend process is running.
I think this argument doesn't really hold. Either you "have to" install a supervisor process or you don't. If you do "have to", then you arguably need to install one for Apache as well, so the complexity is equivalent. If you don't "have to" (I've had Pylons and TurboGears sites up for months without restarts or supervisors), then once again the complexity is even. > You also need to integrate that into the system startup scripts whereas > web servers such as Apache on prepackaged Linux distributions > generally have that. If by "integrate" you mean add a line or two to /etc/rc.local (or your distro's equivalent), then I'll agree with you, but simultaneously fail to see your point. > This is extra software dependencies and extra work to setup. I'll take this added complexity, subtract the complexity of reducing Apache's memory footprint and still come out with an overall savings in complexity. I'll agree that Apache can be made more efficient (ignoring the threading vs async debate) but doing so is far more complicated and error-prone than installing Nginx and a supervisor. Apache starts out big and must be pruned down, Nginx starts out small and pretty much stays there regardless. > Although it may be manageable if you are running a > single web application, it becomes a lot more work if you want to run > a mix of web applications, or multiple sites, all in distinct > processes as you may then need separate supervisor configurations and > startup scripts for each. Since the OP mentioned 96MB of RAM, I'll assume he's running single web app. Unless he requires mod_svn or some other esoteric module, there's simply no way Apache can win here. > Because Apache when using appropriate > modules can itself act as the supervisor for the applications, it all > becomes somewhat simpler as the configuration is all in one spot and > all the startup scripts become irrelevant as that would already exist > for Apache. I know this is difficult for an Apache expert to grok, but configuring Apache is everything except easy to understand. Some of this is due to Apache's rather large feature-set, but some of it is also due to Apache's rather weird and limited configuration syntax. > Also, as I keep trying to put out, speed of request handling and > proxying is generally not the problem as your bottleneck is more often > than not going to be in your Python web application or in the way it > interacts with a database. Thus, for most it would be far more > important to use a system which has less dependencies on third party > packages and is easier to setup. In general I agree, but if Apache is sucking down 1/10th or more of your memory (and with 96MB, that's certainly likely), then it will certainly reduce overall system performance significantly as disk caching will suffer and you'll be forced to swap much sooner. > True, the answer may not always be Apache, especially, if forced to > use a memory constrained environment more tailored to PHP web > application hosting. I generally find Apache preferable to Nginx when one or more of the following conditions is present: 1) Some esoteric feature of Apache is needed. 2) The customer/user is an Apache expert. 3) I don't care about the installation and hope someone else has to maintain it. > If Python folks expect to work > within the constrained environments offered for PHP web applications, > then the large frameworks have to find ways of cutting down on memory > use somehow. I'm not sure the blame is being aimed in the right direction here. I don't think PHP is what Pylons is competing with and I have a definite concern that tailoring it to run in a $7/month hosting account would require too deep of cuts. RoR is much more of a direct competitor, and has been noted, Pylons uses a fraction of the RAM RoR does (not to mention CPU). Quite frankly, were I consulting with a customer in the same position as the OP, what I'd be suggesting is they quit trying to run their site in a toy environment. I think a 96MB VPS is fine for testing, but not a realistic deployment environment for much more than a personal blog or photo album. As an aside, my Pylons (paste+cherrypy) app for Breve only uses around 48MB after a couple months of uptime (there are four Pylons backends load balanced by Nginx): hosting ~ # ps -U twisty -o rss,vsz,command RSS VSZ COMMAND 48000 132720 /usr/bin/python /var/www/virtual/twisty-industries.com//bin/paster serve breve1.ini 48312 133264 /usr/bin/python /var/www/virtual/twisty-industries.com//bin/paster serve breve2.ini 46024 130860 /usr/bin/python /var/www/virtual/twisty-industries.com//bin/paster serve breve3.ini 47920 132860 /usr/bin/python /var/www/virtual/twisty-industries.com//bin/paster serve breve4.ini This leads me to believe there is something wrong with the OP's application or perhaps the leak exists in a layer outside the Pylons core (i.e. template engine). Regards, Cliff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
