This is a very important test. I believe web2py to be thread safe and in fact we thread.lock every access to shared objects even if operations are atomic, yet I will review it in detail.
Massimo On Feb 10, 12:38 am, VP <vtp2...@gmail.com> wrote: > 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 20https://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) > ========
