On Tuesday, September 25, 2012 11:37:01 PM UTC+2, Jose C wrote: > > Interesting... did you also happen to note the memory usage on runs 1,3 & > 5? Any sign of the "large memory leak" that the author of the benchmark > says he encountered, and that Bruno also alluded to in a previous post? > > Nope. A leaking web2py will have worried a lot of users if shows up in a simple app like this (i.e. if it leaks while processing this app, the "bases" of the web2py code are leaking somewhere and everyone would have noticed that)
However, here the results in "used MB of RAM" of my rig . NB: all options of "graceful reloading" of worker if they hit a limit is removed. Frameworks are "free to expand" to whatever they want on RAM. Here "1 round of ab" is a bench with 1000 concurrent requests on a total of 2 millions: - initial 1417 (just the desktop, firefox, exaile playing music :P) - uwsgi started 1440 - while doing 1st round of ab 1510-1513 - finished 1nd round (uwsgi still active, but ab is not there anymore) 1498 - while doing 2nd round of ab 1507-1510 - finished 2nd round 1494 - terminated all 1420 So no leaks (apparently). Cases 1-3-5 behave exactly in the same way. case 2) - initial 1428 - uwsgi started 1429 - 1st round 1453-1457 - finished 1st round 1447 - 2nd round 1470-1472 - finished 2nd round 1452 - terminated all 1427 case 4) - initial 1428 - started 1430 - 1st round 1475-1497 - finished 1st round 1460 - 2nd round 1497-1507 - finished 2nd round 1466 - terminated uwsgi 1432 --
