Alright people.... short answer: I think I figured this out (at least with my configuration)!!!!
After testing various configurations, here's the result with: ab -kc 100 -t 20 https://domain.com/imageblog/default/index/ (same imageblog app, 100 connections, 20 seconds stress test). Two things you will notice with this result. 1. ZERO failed request. No more wsgi premature script error!!!! 2. Complete requests is 1234, 61 requests/second on average. Compare to prior configuration: 588 total requests, 29 requests/ sec on average. Not to mention 15 failed requests due to wsgi premature script errors!!! This is insane!!! So how did I configure this? here it is: WSGIDaemonProcess web2py user=username group=username \ display-name=%{GROUP} processes=5 threads=1 The important option being 5 processes, 1 thread. With this configuration, my real app also did not get wsgi premature script errors anymore. And guess what... the requests/sec triples!!!! I am still curious about this. While my real app can possibly be not thread-safe, but the imageblog app should be thread safe (the index was simply a listing of images, i.e. read only). Why would there be a problem with more than 1 thread? ============ Document Path: /imageblog/default/index Document Length: 13083 bytes Concurrency Level: 100 Time taken for tests: 20.008 seconds Complete requests: 1234 Failed requests: 0 Write errors: 0 Keep-Alive requests: 1234 Total transferred: 16827432 bytes HTML transferred: 16171262 bytes Requests per second: 61.68 [#/sec] (mean) Time per request: 1621.377 [ms] (mean) Time per request: 16.214 [ms] (mean, across all concurrent requests) Transfer rate: 821.33 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 9.4 0 73 Processing: 82 481 890.5 317 5475 Waiting: 76 443 878.7 274 5393 Total: 82 483 894.7 317 5503 Percentage of the requests served within a certain time (ms) 50% 317 66% 342 75% 360 80% 372 90% 416 95% 489 98% 5351 99% 5397 100% 5503 (longest request) ========
