Properly configure mod_wsgi

[Wtower]

Current configuration for mod_wsgi is embedded #10 .

Add the following options in vhost.conf for WSGIDaemonProcess:

processes

Use only if relevant options is specified: the default implies single-process (not the same as specifying explicitly 1, which implies multi-process with 1 process).

threads

Add option. It is recommended to start with 3-5 for a small site. It depends on the cores and if the requests are CPU or I/O intensive. Shouldn't go more than 25.

inactivity-timeout

Add option to allow smaller sites process restart and reduce memory. 300 sec is a reasonable period. Don't set too low and watch new relic requests chart.

Other options

Other options for the future include restart-interval and/or maximum-requests to force restart of process. Use to prevent memory leaks for busier sites. Use in combination with graceful-timeout.

Also queue-timeout is interesting to ignore long queued requests in case of traffic outburst.

SSL

Use WSGIProcessGroup only in the 2nd vhost.conf for SSL (see the bottom of the documentation).

Monitor

Measure the memory footprint after launching the daemon and after running some requests.

[Wtower]

Additional options:

display-name

Helps identify the processes in top and htop. More.

touch

If the apache restart handle is not run, then after deploy touch the wsgi file in order to restart application (test).

Metrics

After several experiments using a typical small django app, the above configuration is very important:

embedded mode

In embedded mode with Apache prefork the page render time was up to 2500msec and the memory footprint 160MB.

daemon at startup

The daemon mode at startup or after inactivity restart gives a page render time of up to 1500msec and before render the memory footprint is 24MB.

daemon mode process started

After the first page render the render time is up to 200msec and memory footprint 64MB.