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
