tests are done with a simple "hello, world" app. Cases 1-3 differs from having session enabled or not. Case 5 is done with a "hacked" gluon/main.py version. So case 1 should "reproduce" the same behaviour the author described (standard web2py, session enabled). None of them showed any memory leak. A memory leak shows up generally growing with number of requests, not on concurrent accesses, however with 1000 concurrent and 2 rounds of 2 millions of requests (that is 4 millions in total) no "evident" memory compsumtion showed up.
Il giorno mercoledì 26 settembre 2012 09:25:54 UTC+2, Jose C ha scritto: > > > 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) > > You'd expect so... although not sure how many users have apps handling > 1,000 concurrent connections. (As an aside it would be nice if any power > users out there could give some feedback on their experience). However > the author of the article states on comp.lang.python as well as in his blog > in response to Massimo that "... during test I have noticed huge memory > leak." > > You mentioned you'd hacked on one of the files. Can you confirm that when > you checked the memory usage it was the standard version of web2py 2.0.9, > or was it using your hacked version of the code? I'd imagine the test would > need to be run with sessions on and web2py as out-of-the-box if we're to > have a chance of reproducing the memory leak. > > Thanks. > --
