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
-~----------~----~----~----~------~----~------~--~---

Reply via email to