3
2

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

asked 30 Nov '10, 14:31

azurewraith's gravatar image

azurewraith
963510
accept rate: 100%

1
(01 Dec '10, 05:10) dalke

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:

WSGIDaemonProcess OSQA processes=5
WSGIProcessGroup OSQA

OSQA can be replaced with some simple name that is meaningful to you, and a good value for processes is number of CPUs (cores) plus 1 (note however that you will get no benefit out of having multiple processes unless you do in fact have multiple requests processing at once on your site, i.e. get a lot of traffic).

Finally, benchmark. Find out what configuration is best on your particular platform.

link

answered 01 Dec '10, 23:25

tgies's gravatar image

tgies
216138
accept rate: 50%

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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×298
×33
×4
×1
×1

Asked: 30 Nov '10, 14:31

Seen: 683 times

Last updated: 02 Dec '10, 01:58

powered by OSQA