|
I've seen bits and pieces of server configuration bits on the Webfaction Q&A site, but is there an optimum apache configuration for running OSQA? There seems to be a large amount of click latency ~0.5-1s on even simple pages in most configurations I've tested and a lot worse on others. Is there a way to run django instances faster like as quick as you would get with a 3 instance Mongrel cluster? Is there a quick custom server for django instances? Sorry, kind of new to django... |
|
Your apache configuration really doesn't make much of a difference until you start getting many concurrent users (i.e. you have multiple outstanding page requests at the same time). The first thing you should do, before you even worry about playing with your apache configuration, is get caching in place to reduce database access. CACHE_BACKEND in your settings file lets you configure your caching. See the Django docs for specifics on how to set this up. You can turn on file-based caching right now and start seeing huge improvements. However, the ideal solution, where possible, is to install memcached for in-memory caching. Caching is basically guaranteed to make a difference an order of magnitude greater than any difference that you could possibly make playing with your apache settings. Once you've done this, then you can start thinking about apache configuration. First principles: Use WSGI. Don't use mod_python. It is probably always slower and more demanding of RAM than mod_wsgi. Part of the reason for this is that WSGI allows your application itself to remain resident in memory between requests. To choose an MPM, you first need to ask yourself if memory is at a premium in your environment. In a very constrained environment like a VPS with 256-512MB of RAM, you probably want to use the prefork MPM with a minimal number of spare processes kept alive. Where more memory is available, you have some room to stretch out which will in turn let you get better use out of your CPUs. Use the worker MPM (tends to use more RAM but gets better parallelism). Run WSGI in daemon mode, as this will offload some processing from apache in a way that improves apache's performance characteristics for static content like images. Daemon mode also sort of gets you "free" optimization of threading configuration so you don't have to worry as much about tweaking the apache MPM configuration. Drop these directives in your apache site configuration to do this:
Finally, benchmark. Find out what configuration is best on your particular platform. Thanks! I can run the instance about as fast as meta.osqa.net on a box of my own, but on a virtualized server I'm seeing these insane 20-40s spin up times after inactivity like I would see if I had restarted apache on my personal box. The configs are not that different, any idea on what might cause that? Using WSGI, daemonized, and the process isn't restarting (has been resident for awhile)...
(02 Dec '10, 01:05)
azurewraith
If you've touched any script files in the OSQA directory, WSGI might be noticing and throwing away the application and reloading it again. What sort of caching do you have in place? Is it possible that your SQL server (where applicable) is being spun down or unloading things? Is there a lot of memory pressure on your system? Does the problem go away if you don't use daemonized mode, or does it get worse?
(02 Dec '10, 01:24)
tgies
1
Script files shouldn't be touched, as far as I'm aware. I've set up two instances in two different places (using the same database) and only the virtualized one is flaking out if allowed to idle > 10m. I use the same server for other Rails applications, it's not taxed for memory/CPU... I have not tried too many things, mainly because the virtualized server is not under my control. You've given me some things to look into though. Thanks.
(02 Dec '10, 01:58)
azurewraith
|
@tgies pointed out that there's a high rendering overhead. See http://meta.osqa.net/questions/5947/why-does-osqa-spend-so-much-time-rendering-templates .