On Feb 16, 2011, at 3:07 PM, Massimo Di Pierro wrote: > > 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.
It need only be symbolic; I think that this falls into the "known bug" category. I found it by Googling. To be more certain, it'd be good if someone could revert psycogpg2 (with no other changes) and reproduce the problem. > > 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) >>> ========
