The issue is that every web app eventually starts dropping requests when the server exceeds its capacity. That capacity depends on the web framework, the details of the app, the ram and speed of the server. It is more likely if the web app an exclusive lock on some file and keeps it locked for some time.
When comparing web frameworks it important to try compare apples with apples. On a 256MB server on app may hit the threshold and start dropping request while another not. If a web2py app has migrate=True than lots of code is in effect serialized and it is more likely to hit the threshold on heavy load. In production you should 1) set migrate=false 2) bytecode compile your app 3) use cache (although it can be a memory hog) 4) move as much logic as possible (but table definitions) from models to controller functions so that it is executed ONLY when the action that needs it called and not per every request. Usually 1+2 give you a factor 2x-3x speed-up. This is not saying that there are not other problems. If there are they must be investigated. Massimo On Jul 21, 5:15 am, Iceberg <iceb...@21cn.com> wrote: > Hi Massimo, do you hint that all these measure are needed to minimize (if not > get rid of) the occasional slow response? > > 1) set migrate=False in the web2py code > 2) ... (N/A) > 3) disable session feature as long as your app does not need it. (But how > to? Is session.forget() enough?) > 4) bytecode compile the app to avoid execfile() call > > I have to admit that my apps do not follow any of above suggestion because I > thought they were not a must. Tell me if I was wrong. > > On the other hand, Kuba, who started this thread, later said "I moved to > apache/WSGI from Rocket. For me the problem disappears." So I guess there is > a standalone rule #5: Use apache/WSGI etc. instead of the built-in Rocket ? > > Best regards, > Iceberg, 2010-Jul-21, 18:01(PM), Wed > > ----------------------- Original Message ----------------------- > From: mdipierro <mdipie...@cs.depaul.edu> Sender: web2py@googlegroups.com > To: web2py-users <web2py@googlegroups.com> > Date: Wed, 21 Jul 2010 01:55:27 -0700 (PDT) > Subject: [web2py] Re: web2py performance issue or rather my fault? > > ------------------- > > > One more thing.... because of design flask with generate and reuse pyc > > file. In the case of web2py python code is executed. You have to > > explicitly "bytecode compile" via admin. I am not sure if you have > > done that. > > > Massimo > > > On Jul 21, 3:36 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > Hi Thadeus, > > > > I looked at the code you used for comparing web2py and Flask. > > > > This is NOT A FAIR COMPARISON > > > > Here is why: > > > > 1) you did not set migrate=False in web2py. This means at every > > > request you lock the entire database table metadata to check whether > > > the table has migrated. You do this while you have an open transaction > > > with the postgresql database. For such short code, this essentially > > > serializes all your requests. You should run it once with migrate=True > > > and then run the tests with migrate=False. > > > > 2) in the case of Flask you use raw SQL for the queries. In the case > > > of web2py you use DAL syntax. On such a short program I cannot say > > > what the DAL overhead may be but certainly you have it in one case and > > > not the other. > > > > 3) The web2py program has sessions enables (has to parse cookies, > > > create and parse session files, store the session, files, generate new > > > cookies and lock session files - at every request). You did not even > > > set session.forget() which means a new session file is saved at every > > > http request. The Flask program is doing nothing of this. > > > > Of course the Flask program under this conditions performs better. > > > > A more fair test would be: > > > 1) set migrate=False in the web2py code > > > 2) use SQLAchemy syntax for database queries in the flask code > > > 3) enable serverside session in Flask code > > > > Massimo > > > > On Jul 18, 12:20 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > > > > > Massimo, web2py.com is not a valid application to be testing this on. > > > > Most > > > > of what web2py.com does is just render a template and display it, it > > > > hardly > > > > does any kind of strenuous dbio. > > > > > As you know I have a few separate servers running different > > > > configurations. > > > > > I mainly decided to do this testing as to the problems I have had with > > > > my > > > > application at work (which runs apache + mod_wsgi). I wondered if my > > > > blog > > > > had the same issue (which when I ran ab tests on it and spiked its > > > > usage, it > > > > did). Interesting thing is my blog ran on cherokee + uwsgi. I doubt it > > > > is a > > > > configuration issue since I still have the same problem on two > > > > completely > > > > different apps running completely different setups all different except > > > > web2py. They both use postgres as well. > > > > > I am attaching the two apps that I tested, as well as a text file that > > > > contains the raw ab tests that I collected to run > > > > > -- > > > > Thadeus > >
