I am also not happy with the CGI performance of GAE.

Some interesting numbers:

welcome/default/index:

cold request time: ~1500ms
warm request time: ~150ms  (about 1/10 time of a cold request)

a warm process is reaped in just *60 sec* if there is no activity.

If you have a low activity site, where requests are less frequent than
1/minute then every request will be a cold request (~1.5 sec/request
not including datastore access).

In other words, on low activity sites, byte code caching does not
help, since everything is recompiled on every request...

I wonder if cron can be used to maintain a warm process.  The min cron
interval is 1 minute, so it would be possible to hit a dummy handler
with cron that does nothing just to keep a warm process.

Robin

On Apr 14, 9:23 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> Whatever you discover please let us know. It will help us improve.
>
> Massimo
>
> On Apr 14, 8:26 pm, Ted G <tedg...@gmail.com> wrote:
>
> > Thank you for the tips. I'll work through these and determine if I can
> > find a specific root cause of the performance problem.
>
> > I've been testing on a particular page of the application that lists a
> > number of items along with thumbnail images for those items. The
> > thumbnails are images placed into an upload field of the item record
> > and then displayed within the page using the following as the image
> > src:
>
> > {{ =URL(r=request,f='download',args=[channel.image]) }}
>
> > The page itself takes a while to initially respond, and then each
> > thumbnail in turn takes a while to download.
>
> > As a test, I replaced the above image src with the following:
>
> > /img/channel?id={{ =channel.id }}
>
> > and used App.yaml to direct the /img to a request handler using GAE's
> > native wsgihandler where I perform the following to download the
> > thumbnail image instead of using the web2py download():
>
> >             record = channel.get_by_id(int(self.request.get
> > ('id')))
> >             self.response.headers['Content-Type'] = contenttype
> > (record.image)
> >             self.response.out.write(record.image_data)
>
> > While the delay before the page first loads has not changed, the
> > subsequent display of the thumbnails on the page is now very fast
> > (which are the only requests now not being handled by web2py).
>
> > Not sure what to make of this at this point, but I wanted to first
> > ensure there was not a GAE or DB issue before digging deeper into what
> > part of my web2py implementation is slowing things down.
>
> > I have not modified the gaehandler.py and as a first step did move
> > sessions to ram cache instead of db, but have not seen any noticeable
> > performance increase.
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to