Thanks for your good explanation! Now I have a question that addresses the difference to mod_python: I understand the wsgi apache module as a standardized interface to connect various wsgi capable web application frameworks,. That gives the developer the opportunity to choose the framework, and also to start the server separately (eg. without apache)
Are there any other advantages over mod_python? And in which situations is mod_python the prefered choice? Alex. -- [EMAIL PROTECTED] On 04.03.2008, at 00:42, Graham Dumpleton wrote: > > On Mar 3, 10:59 pm, Alex Greif <[EMAIL PROTECTED]> wrote: >> >> the background is that I intend to use apache with the mod_wsgi >> module. >> And with this configuration I wanted to know whether it is fast >> enough >> to use in a production environment. > > Yes, mod_wsgi is more than fast enough for use in a production > environment, and using WSGIScriptAlias in embedded mode is the fastest > configuration. Ie., less overhead than using AddHandler or other means > of enabling mod_wsgi for a script. > >> In general it seemed to be very easy to get apache working with wsgi >> and web.py. >> I only added one line with WSGIScriptAlias to my apache conf (except >> loading the module itself), and that was all. >> I wonder whether this is sufficient for a production configuration. > > The thing you have to realise is that initial handling of the request > by the server and any network overheads are not going to be your > bottleneck. People get really obsessive about trying to work out what > the fastest server configuration may be when it all means absolutely > nothing if the bulk of the request time is consumed by your > application or database queries. > > It is probably more important to find a server setup which you find > easy to set up and manage. That will allow you to spend more time > working out how to eliminate the real bottlenecks in your application, > whether that be the application code, database queries or how the > manner in which you construct HTML pages affects a client browsers > ability to download stuff as quickly as possible. > > Get all those things sorted out first, then revisit the server > configuration issue. What you can do at server level will then depend > on your application and what it is doing. For example, whether Apache > prefork or worker MPM is better, whether a separate media server for > static files would be better, whether disabling keep alive on URLs > which generate dynamic content will help etc etc. > > Now, I am not saying all this because of mod_wsgi being slower in > anyway, it isn't, with mod_wsgi in general being a much better option > performance and scalability wise than fastcgi or mod_proxy based > configurations. I say the above purely because that is where you > should be looking if you want to make your application faster rather > than wasting time worrying about network overheads and base > performance of the server. > > Obviously, the only server consideration at this point is simply not > to use CGI, beyond that you'll probably most solutions more than > adequate. Performance and scalability of the hosting mechanism would > normally only become an issue if you site were to become used quite > heavily. Most peoples sites never reach this point. > > Graham > >> -- >> [EMAIL PROTECTED] >> >> On 03.03.2008, at 10:27, Graham Dumpleton wrote: >> >> >> >>> On Mar 3, 7:51 pm, Alex Greif <[EMAIL PROTECTED]> wrote: >>>>> They are different alternatives depending on what you need to do. >>>>> The >>>>> most basic one to use is WSGIScriptAlias. >> >>>> BTW, is this a preferred way for production environment behind an >>>> apache server? (not for google :-) >> >>> Do you want to rephrase that, not sure what you are asking? >> >>> The mod_wsgi module means that your Python application is either >>> running directly in the Apache child process (best performance and >>> scalability), or in daemon processes directly forked from Apache and >>> managed by Apache (best for application isolation and running as >>> distinct users). Daemon mode is sort of similar to fastcgi >>> solutions, >>> but not really, as it is an integrated system where mod_wsgi handles >>> both sides. In fastcgi it is a separate processes created by way of >>> fork/exec and you need separate adapter such as flup where as in >>> mod_wsgi you don't. Also different to mod_proxy solutions where you >>> might run Python web application as standalone process and proxy >>> HTTP >>> requests to it. >> >>> Out of those four configurations, which are you asking about and >>> what >>> do you want to know? The mod_wsgi doesn't sit behind Apache like >>> mod_proxy solutions do and is also more tightly integrated than >>> fastcgi solutions, thus why am not sure what you asking. >> >>> Graham > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web.py" 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/webpy?hl=en -~----------~----~----~----~------~----~------~--~---
