On Jan 21, 4:16 am, GSP <[EMAIL PROTECTED]> wrote: > Are there any specific performance advantages to using mod_wsgi over > mod_proxy?
It really depends on what 'performance' means to you. Running an application in mod_wsgi embedded mode will give you lower network overhead as you avoid the additional step required to proxy to a back end. The actual serving of requests is also faster in mod_wsgi. Although the maximum request throughput for a simple hello world program will be better, this isn't where the bottlenecks usually are. Instead it is the TG application itself and any access to the database layer. In other words, the time saved per request is swallowed up in the much larger response time once the application specific overheads kick in. Thus, how well your own application performs will dictate whether the performance gains will be noticeable. If you own application can only manage 40 requests per second where as the maximum the WSGI adapter can handle for a simple hello world program is 2500, you aren't going to see much difference whatever hosting solution you use (excluding CGI). Where use of mod_wsgi embedded mode in particular may help derives from the fact that Apache scales up to meet the demand of incoming requests. So, where as when running TG in a single backend process it can eventually run out of threads to handle concurrent incoming requests and requests will start to back up, Apache will create additional child processes containing your TG application on demand to cope with the spike in traffic. When any spike has disappeared, Apache will kill off any processes now no longer required. If using mod_proxy, you would have to make a design decision in advance to start up multiple TG application instances and then configure Apache to load balance across them. These will always be running though and so the memory will always be in use whereas Apache would shutdown processes once it didn't need them thus releasing memory for use by other applications, although how many it keeps as spares can easily be configured. One benefit with this mod_proxy model though is that it is a bit easier to load balance across TG application instances on multiple machines. This is because you already have Apache doing this. If using only Apache, you would need to go the extra step of setting up another front end load balancer. For example, you might use lightweight solutions such as Pound or nginx for this. Using mod_wsgi daemon mode the overheads are a bit more than embedded mode because it also involves an extra hop, but it still works out better than mod_proxy. Using daemon mode you can still create multiple processes to handle requests and have TG application runs as special user as well. Because there is no need to setup a separate supervisor system to keep the TG applications running like with mod_proxy solutions, it is arguably a bit easier to configure and setup than a mod_proxy solution. Using Apache also has other benefits of being able to have processes recycled automatically after a certain number of requests are handled. This can be useful to combat slow memory leaks in applications. If using mod_proxy this is harder as you need to create a special system to monitor memory usage from outside the TG application and periodically shutdown the application and restart it. The way Apache handles restarts of processes hides the fact that it is occurring from users, but with mod_proxy solutions depending on how it is all setup, you may temporarily see users getting bad request errors while things are restarted. So it really depends on what you are doing and whether your application is significant enough that performance (using whatever measure) is an issue. Because either approach can be setup to scale in various ways, it is generally better to look at what you believe is simpler to configure and manage. Graham > On Jan 20, 4:02 am, dazza <[EMAIL PROTECTED]> wrote: > > > I followed your instructions and the documentation on the wsgi site and it > > all works REALLY well. I've tried mod_proxy andmod_wsgiand wsgi is a > > little more complex but a lot better option for me. > > > On Jan 19, 2008 12:06 AM, Graham Dumpleton <[EMAIL PROTECTED]> > > wrote: > > > > If people have got it working with TurboGears then please indicate if > > > you have and what may have to be changed in the instructions. If I > > > don't hear from anyone I'll remove the instructions and note > > > TurboGears as not supported anymore instead. > > > > Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
