alex@alex-laptop:/tmp$ ab -c200 -n50000 http://localhost:8000/Hello/100
Concurrency Level: 200
Time taken for tests: 20.114 seconds
Complete requests: 50000
Failed requests: 0
Write errors: 0
Total transferred: 57350000 bytes
HTML transferred: 49500000 bytes
Requests per second: 2485.80 [#/sec] (mean)
Time per request: 80.457 [ms] (mean)
Time per request: 0.402 [ms] (mean, across all concurrent requests)
Transfer rate: 2784.38 [Kbytes/sec] received
alex@alex-laptop:/tmp$ ab -c200 -n50000 http://localhost:8001/Hello/100
Concurrency Level: 200
Time taken for tests: 42.483 seconds
Complete requests: 50000
Failed requests: 0
Write errors: 0
Total transferred: 57350000 bytes
HTML transferred: 49500000 bytes
Requests per second: 1176.94 [#/sec] (mean)
Time per request: 169.932 [ms] (mean)
Time per request: 0.850 [ms] (mean, across all concurrent requests)
Transfer rate: 1318.31 [Kbytes/sec] received
- Didip -
Because some tornado sites are using other modules incompatible or instable with pypy...
Ovidiu
There is a ctypes module for use postgresql, it's based on libpq maybe it could work with pypy. http://pypi.python.org/pypi/pypq/0.1.3
- Didip -
My current understanding of the issue is that it's not quite a leak
and has a disproportionate effect on "hello world" workloads.
Basically, memory allocated by C extensions is "invisible" to the pypy
garbage collector. It'll still be freed when GC runs, but it has no
effect on when GC happens, so there may not be a GC until pypy has
used much more memory than it normally would. In tornado's case, the
main culprit appears to be openssl objects used by the hashlib module
(used for computing etags). This should be fixed in the upcoming pypy
1.7 (http://mail.python.org/pipermail/pypy-dev/2011-October/008524.html),
although the underlying problem may crop up with other modules as
well.
-Ben