2009/2/19 simon <[email protected]>: > > Just like to share some findings I've had over the past week with a > django site that does a reasonable amount of traffic, up to 15k pages > per hour. I thought I'd try switching to apache 2.2 worker with > modwsgi in embedded mode for the lot, both django and media. If we can > thread it these days, why not let it serve media with keep alives and > all. Under this configuration, I suspect the extra of apache vs > lighty, nginx etc for serving media would be negligible. Previously, > we used to run lighttpd for media with 2.0 prefork modpython for > django. > > Anyway, when we first went live with modwsgi, the server kept buckling > under load. > > Turned out to be ThreadStackSize. I reckon that could be spelt out a > little louder in the docs (which are otherwise fantastic, btw). We're > on debian lenny. So here it is -- > > ThreadStackSize 524288 > > For now I seem to have settled on this -- > > StartServers 4 > MaxClients 256 > MinSpareThreads 256 > MaxSpareThreads 256 > ThreadsPerChild 64 > MaxRequestsPerChild 10000 > ThreadStackSize 524288 > > That's with embedded mod wsgi under worker mpm. Keepalive timeout 5 > seconds, which seems long enough to me. > > I've compared this against various combinations of running daemonised, > prefork/processes vs theads etc but this seems to provide both lower > cpu and higher throughput.
Hmmm, I am a bit surprised that thead stack size mattered. Unless operating systems are different, the thread stack size should only matter as far as virtual memory size reserved, at least initially. This would only convert to physical memory if the stack was actually used, but if it went as far as allocating significant amounts of the stack to be an issue, then would have expect smaller stack size to be a problem due to being too small. I'll have to do some reading about what thread stack size in operating systems really means. The only reason I can think of where large stack size would be an issue, if not actually being physically allocated, is that it creates a sparser image in virtual memory. Thus the context switcing behaviour may be quite a bit different. My operating system memory management knowledge is very very rusty though, so my idea of what is going on is probably very wrong and doesn't fit with modern operating systems. If anyone has good pointers to sites which explain how stack allocation works in Linux or other modern operating systems, would be appreciated. Up to know I believe the thread stack size to only be an issue where VPS system counted virtual memory into VPS limits. BTW, are you attempting to use WSGIImportScript to preload your WSGI script and therefore Django code modules? Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" 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/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
