I suspect this is the GIL causing troubles with Rocket. I read http://packages.python.org/rocket/usage.html#architecture-considerations
It seems that Rocket's people insist on using threading vs forking: this could be a major problem because of CPython's GIL. IMHO such implementation urges a migration to the processing module (http://pypi.python.org/pypi/processing) which comes included with python 2.6. I would investigate where there could be some resource starvation or lock on a per process basis (threads are single process for CPython) when using Rocket. ciao, michele 2010/7/8 mdipierro <mdipie...@cs.depaul.edu> > I use apache + mod_wsgi and therefore there is no httpserver.log > logging. I will enable it. > > On 8 Lug, 08:15, Iceberg <iceb...@21cn.com> wrote: > > Me too experience similar issue as Rahul did. Issue:> > [sometimes, once > every few hits, it loads signifacantly slower > > > > weirdest thing is when you re-click the link it loads instantly, when > > > > you left it working to load on itself, it is slow.. like 4 to > > > > 8seconds ] > > > > ... or even dozens of seconds. :-/ > > > > My findings, well, not really: > > > > - Both my develop machine (windows xp home edition with latest > ServicePack), and my production machine (a Linux), have such issue > occasionally. Both environments uses web2py's built-in server, rocket or > cherrypy. Both serve no more than 10 people or so. > > > > - I could not find a pattern to reproduce the problem. On my development > laptop, I just got an impression that it is more likely to happen for the > first request after the web2py has been idle for long time due to no > workload. So perhaps it is because the OS had swapped out all memory owned > by web2py, therefore web2py need to "warm up" again. This is not web2py's > fault, I think. > > > > On my Linux production server, similar "pattern" exists (but I am not > sure, did not dig into httpserver.log to confirm that). > > > > Besides, the out-of-response is also likely to happen when user visit my > app's statistics page with 10+ charts showed by flash. Perhaps the sudden > burst of 10+ concurrent requests race each other? > > > > @Massimo: You can check your production server's httpserver.log to see > what is the longest (slowest) response time. If it is small enough, that is > good, otherwise ... oh by the way, do you use web2py's built-in server (now > rocket), or do you use apache-like frontend? That could make difference. > > > > Best regards, > > Iceberg, 2010-Jul-08, 20:50(PM), Thu > > > > ----------------------- Original Message ----------------------- > > From: mdipierro <mdipie...@cs.depaul.edu> Sender: > web2py@googlegroups.com > > To: web2py-users <web2py@googlegroups.com> > > Date: Thu, 8 Jul 2010 02:23:56 -0700 (PDT) > > Subject: [web2py] Re: web2py performance issue or rather my fault? > > > > ------------------- > > > > > Whatever the problem is it must be resolved. The strange thing is I do > > > not experience this on my production system (~50000 hits/day and > > > distinct 1600 visitors/day). > > > > > What could it be? > > > - cron when it runs spikes CPU usage. DO NOT USE. In production run > > > web2py cron in a separate process, not the one that runs the web > > > server. > > > - web2py session lock (the the same user can only access one page at > > > the time unless the lock is released via session._unlock()) > > > - sqlite lock (depending on the query and the complexity of > > > transaction this may take long) > > > - db connection pooling locks (when look up for open connection) > > > - cache locks (it is a global lock, to ensure data integrity) > > > - cache.ram can cause memory leaks if the key depends on variables > > > - problem with web server (Rocket or the apache or mod_wsgi, etc.) > > > > > On 8 Lug, 02:48, Rahul <rahul.dhak...@gmail.com> wrote: > > > > Hi All, > > > > I have experienced a similar issue with web2py. Issue: > > > > [sometimes, once every few hits, it loads signifacantly slower > > > > weirdest thing is when you re-click the link it loads instantly, when > > > > you left it working to load on itself, it is slow.. like 4 to > > > > 8seconds ] Earlier I reported this kind of issue in a separate > > > > thread. > > > > > > Some findings ---- > > > > Office Env: > > > > My web2py powered site will be up in production soon and I am > awaiting > > > > for getting in-house feedback. I am testing this on my local system > > > > with the below config > > > > OS: Win xp professional version 2002 with sp2 (old but works fine) > > > > Machine: Intel P4, 2.8 GHz and 1 GB ram. > > > > Web2py version latest (Version 1.79.2 (2010-06-08 22:45:26) ) > > > > I encounter the above said issue every time the system is left idle > > > > for some minutes (Ex: If I start the web2py server and I am using my > > > > web2py application continuously, it works well but if left idle for > > > > some 5 mins or so, it becomes slow as mentioned above) > > > > > > At home tough: > > > > Home Env: > > > > OS: Win xp professional version 2002 with sp2 > > > > Machine: Core2 Duo with 2 GB Ram > > > > Web2py version 1.76.5 (prior to server change) > > > > I deploy the same app and my site in the applications directory and I > > > > never get such delays... > > > > > > Conclusions: > > > > 1- May be its my system setup that could be the culprit > > > > 2- May be some thing is wrong with web2py or my code. > > > > > > One more thing I noticed was (when using executesql the query or page > > > > hit was a tad slower than when using the sql syntax provided by DAL) > > > > so I changed all executesql statements to equivalent DAL statements > > > > and these seemed to perform a bit faster. > > > > > > Finally, I'll check the existing code with latest web2py version on > my > > > > home environment and get back if required. > > > > > > I just thought that this could help in some way (since I am facing > the > > > > same issue) so jumped in between this conversation. Sorry for that > > > > though. > > > > > > Massimo, Thanks for a wonderful framework.. Everytime I see it and > use > > > > it, it keeps getting better and better.. > > > > > > Thanks, Rahul >
