On May 21, 1:09 am, Jonathan Vanasco <[EMAIL PROTECTED]> wrote: > > If you are going to run a large site which is able to respond well to > > bursts in traffic, running Python embedded in Apache running prefork > > MPM, with huge amounts of memory in the box is generally the best > > approach. This is because although memory usage will be high, being > > non multithreaded you can use any cpu/cores to best advantage, plus > > you benefit from Apache's ability to create dynamically more processes > > to handle demand when required and then reap them when no longer > > required. > > This is for a startup that will initially have 1pylons + 1 postgres > server, and scale out accordingly. They're a video startup, and have > some bigger names backing them, so I'd expect them to scale large > quickly. > > However... I have years of experience with mod_perl, and have found > the overhead of apache to be nearly worthless. By proxying static > stuff off of apache onto nginx, and offloading code portions into > nginx/php or twisted, we were able to gain a lot of efficiency. > Apache does its job exceedingly well , but its bloated.
Also see my comments in other post, but when you say 'proxy' I hope you don't really mean 'proxy'. Although I explained that it is a good idea to off load static media to a separate server, I then really don't understand, as a lot of people do do, why you would also then want to make that static media server the front end and 'proxy' requests for the dynamic web application through it to something else, such as Apache, or even fastcgi processes. All you are doing in doing this is adding additional latency into your requests due to the extra hop. If building a large site and are using a separate media server then use different IPs for each. Preferably this should be a completely different machine. If it has to be the same machine and you can't get additional IPs to allow port 80 to be used for each, then use different ports. If one really has to use a software proxy, then also perhaps look at dedicated solutions like Pound. It may be the case that nginx serves okay as a proxy, but it isn't purpose built for that and so solutions like Pound may provide a more flexible solution which is easier to configure and manage when load balancing across many machines. Better still perhaps is to use hardware based solutions, or DNS features, if needing to load balance across a cluster of machines. Proxying also adds additional overhead even for the fastcgi like case. This is in part why Apache prefork MPM and an embedded solution is better if you want to squeeze out as much performance as possible. That is, the process accepting the connection is the one handling the request, not some backend process it is in turn talking to. Yes you loose ability to run code as a non Apache user, but if the Apache is dedicated to the application, you can make the whole server run as the required user instead of the Apache user anyway, so not an issue. Graham --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
