Looks like Jonathan may be the winner here. I think VP raised the issue so he should decide whether the issue is solved. Is anybody else having problems after upgrade to the latest psycopg2?
If this problem was dear to you any symbolic contribution towards the prize will be appreciated. Massimo On Feb 10, 8:19 am, Massimo Di Pierro <massimo.dipie...@gmail.com> wrote: > I offer $300 to whoever can identify within 3 weeks and without > ambiguity the cause of this problem. The bounty applies even if the > problem turns out to be not in web2py but in one of the Python > modules, in Apache or in the mod_wsgi implementation. It does not > apply if the problem is due to known bug that has already been fixed > by the responsible party (for example if you are using an old un- > patched python version like 2.5.0 or an old mod_wsgi version). > > 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) > > ========
