mod_wsgi is very slow compared to mod_python for my Trac installation

[Thomas Allen]

Having read many accounts suggesting improved performance and other
incentives for switching to mod_wsgi, I did. I believe that my setup
is fairly standard, and I can't determine the cause of this slowness.
Using mod_python, a Trac page loads in about 0.3sec, but with
mod_wsgi, the average page load is 1.3sec and upward. What am I doing
wrong? Below is the relevant section of my virtual host, as well as
the WSGI script I'm using:

WSGIScriptAlias /trac /var/www/designs703/trac/trac.wsgi
WSGIDaemonProcess trac threads=15 processes=4
<Directory /var/www/designs703/trac>
WSGIProcessGroup trac
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>

trac.wsgi:

import os
import trac.web.main
import trac.db.postgres_backend

os.environ['TRAC_ENV'] = '/var/www/designs703/trac'
os.environ['PYTHON_EGG_CACHE'] = '/var/www/designs703/trac/eggs'

application = trac.web.main.dispatch_request
trac.db.postgres_backend.PostgreSQLConnection.poolable = False

[Graham Dumpleton]

2009/3/9 Thomas Allen <thomas...@gmail.com>:

>
> Having read many accounts suggesting improved performance and other
> incentives for switching to mod_wsgi, I did. I believe that my setup
> is fairly standard, and I can't determine the cause of this slowness.
> Using mod_python, a Trac page loads in about 0.3sec, but with
> mod_wsgi, the average page load is 1.3sec and upward. What am I doing
> wrong?

Is that on every request for ever, or just an initial set of requests?

Like mod_python, mod_wsgi defaults to lazy loading of the application
and as such the first requests that hit each of the processes will be
slow in comparison to later requests once everything has been loaded.

Also, are you still loading mod_python? In some cases mod_python can
interfere with mod_wsgi and cause strange problems. When it occurs it
is usually results in crashes, but don't rule out other things.

What I would suggest is ensuring you have set LogLevel directive in
Apache to 'info'. This will cause mod_wsgi to output extra debug
information in Apache error logs about when it is starting up
processes, loading WSGI script file etc. Would possibly like to see
this so can rule out daemon process crashing at some point and having
to restarted for each request.

> Below is the relevant section of my virtual host, as well as
> the WSGI script I'm using:
>
> WSGIScriptAlias /trac /var/www/designs703/trac/trac.wsgi
> WSGIDaemonProcess trac threads=15 processes=4

How big is your Trac installation and how many requests per sec would
it get? For most sites you would get away with single process, so you
can drop 'processes=4' and let it default to running a single daemon
process and probably not see any difference given that also using
multithreading.

BTW, if the initial requests being slow is an issue, then, as with
mod_python one can configure application code to be preloaded to avoid
most of it.

Graham

[Thomas Allen]

Hi Graham,

In response to your suggestions:
* I've only run mod_wsgi with mod_python off and vice-versa, so that
couldn't be an issue.
* The Trac installation is only a few days old with maybe twenty wiki
pages and fifteen tickets.
* Load testing on this seems to be a waste of time. I'm using
mod_auth_digest authentication, and I get about 60 reqs/sec even for a
Django starter page, most likely do to this authentication. I may
briefly disable the security, but I'd really prefer not to.
* I know what you mean about lazy loading, and I believe that
mod_python has a similar behavior. An initial load takes 0.9-1.3
seconds using mod_python and 1.8-3.0 seconds using mod_wsgi. A
"primed" page load, so to speak, takes about 0.3s with mod_python and
about 1.2s for mod_wsgi.

I'll try your logging advice and post my findings.

Thanks,
Thomas

On Mar 8, 6:55 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> 2009/3/9 Thomas Allen <thomasmal...@gmail.com>: