Uneven response time between connection to server to first byte sent

[Anders]

I don't know if this is related to only the Python version or also to
the Java version, but the response time from GAE servers (Python) is
very uneven. Sometimes the time from connection with the server to the
first byte sent is less than a second, but sometimes the response
takes several seconds between connection with the server to the first
byte being sent. It doesn't depend on the datastore or some other
backend it seems since it happens for pages who don't use any
(application-level) backend. And the response time can be very long
even after a recent (previous minute or so) fast response.

I have noticed this using ordinary web browsers, and also when using
tools like:

http://tools.pingdom.com/?url=http://www.blabline.com&treeview=0&column=objectID&order=1&type=0&save=false

Is there some kind of performance bottleneck that sets in from time to
time?

[Tim Hoffman]

Hi

What you are seeing the is the server starting up some of the time
(hence long response times) and sometime hitting a running server
(short response times)

Servers may recycle very quickly (ie in as little as 30 secs)

A typical server startup time for django and some other frameworks is
2-3 secs
You can see this in you admin console logs


Java will no doubt exhibit the same thing

Rgds

Tim

On May 18, 3:30 am, Anders <i...@blabline.com> wrote:
> I don't know if this is related to only the Python version or also to
> the Java version, but the response time from GAE servers (Python) is
> very uneven. Sometimes the time from connection with the server to the
> first byte sent is less than a second, but sometimes the response
> takes several seconds between connection with the server to the first
> byte being sent. It doesn't depend on the datastore or some other
> backend it seems since it happens for pages who don't use any
> (application-level) backend. And the response time can be very long
> even after a recent (previous minute or so) fast response.
>
> I have noticed this using ordinary web browsers, and also when using
> tools like:
>

> http://tools.pingdom.com/?url=http://www.blabline.com&treeview=0&colu...

[Anders]

Ok, thanks. Yes, I suspected some kind of startup/page swap thing was
going on. It seems to happen more frequently now than in the past. It
lowers the quality of the service by having such slow response times
happening frequently. For example, the load time for a page with 17
separate objects (such as images, javascript files etc) can take 6
seconds of which 5 seconds is just for the server to respond! That's a
severe performance bottleneck imo.

[Wooble]

Keep in mind that the "first byte sent" goes out when your handler is
completely finished with everything. If you're fetching a lot of data
from the datastore and want the page to start rendering earlier, you
might want to think about using AJAX.

[Anders]

Yes, but even say an index page with only 'static' html is affected by
slow responses from servers. Take ordinary Google Search for example
which has awesome load time performance. That performance is an
important part of the quality of Google Search. We probably can't
expect that kind of performance when using GAE, but I would like to
see some improvements in performance regarding server response time.

[bFlood]

i agree, I think the instances are getting recycled more aggressively
now. also, some more info on this post, including a comment from a
googler.
http://groups.google.com/group/google-appengine/browse_thread/thread/7cd20b6fcfd38e5d

i hate to say it but I'm beginning to wish we could pay for a single
instance to be left in memory for longer periods of time. they are
certainly not full virtual environments like in EC2 or Azure, so I'm
hoping this is feasible

cheers
brian

[Anders]

Oh, I missed that it had been discussed before (when doing a search
for past threads). Yes, it would be good to have application instances
remain longer in memory, and/or if possible to significantly speed up
the startup time for application instances.

On May 18, 4:17 pm, bFlood <bFlood...@gmail.com> wrote:
> i agree, I think the instances are getting recycled more aggressively
> now. also, some more info on this post, including a comment from a

> googler.http://groups.google.com/group/google-appengine/browse_thread/thread/...

[Anders]

I think that the response time has improved somewhat. Still, it can
sometimes take several seconds for a GAE server to respond.

To stress how important this is, consider what an expert working at
Google has to say: "* They clicked on your ad and your page was very
slow to load. (Another one where I am gone in about 3 seconds, max.)"

From: http://www.google.com/support/forum/p/AdWords/thread?tid=3e25d50f777a4a2b&hl=en

[Anders]

Another area where fast responses from servers is important is Ajax
calls. With Ajax, webpages and sites are becoming more and more like
ordinary desktop GUI interfaces, where fast server responses are
needed for high quality performance and user experience.

[Anders]

Another expert working at Google, Steve Souders, has statistics
showing how end users can abandon a site just because the load time is
only a few percent slower! That sounds almost outrageous but I think
Souders knows what he is talking about. He is an expert on client side
performance (and also knows a lot about server-side issues). Imagine
then if the GAE servers' response time sometimes makes the total load
time for a webpage 100% slower, or more! Yikes!

[Anders]

Just one last point (I don't want to appear too irritating ;-).
Consider the following quote:

"The difference in your behavior with content, if it's 50 milliseconds
faster, not to mention two seconds faster, is enormous. You really
interact with it differently. We have lots of experiments, we are
running all kinds of user interfaces experiments ... if there is
anything I can do is to really ask people who design websites to think
about the users and try to make it as fast as possible for them." --
Udi Manber, head of Search Quality at Google

From about 34:20 in the below video:

http://www.youtube.com/watch?v=RIs0SIYvYKQ

[Anders]

Ok, just one more comment. Both serious and tongue-in-cheek style.

To use a metaphor, I hope that Google App Engine will become like a
real car and not be a plastic toy car for kids. Maybe someone from
Microsoft or Amazon has managed to infiltrate the management of App
Engine at Google. Not only do (did) the sometimes exceedingly long
start-up times for application instances suck, there is also (at least
was) a lack of clock synchronization between GAE servers. This means
that an application like Twitter is not possible to implement using
Google App Engine. For example, the Twitter API allows max 50
something calls per minute in some cases. That's impossible to
implement reliably without predictable clock synchronization between
servers.

[Ian Lewis]

Anders,

For ajax calls you might consider creating a very simple handler that uses as few modules as possible when performing ajax calls. Then put that as a separate url in your app.yaml. In that case appengine would only load the modules it needs to serve that request and would hopefully not take as long (as say to load a whole framework like django). That might help reduce the latency of some of your ajax calls.

Ian

--
=======================================
株式会社ビープラウド  イアン・ルイス
〒150-0012
東京都渋谷区広尾1-11-2アイオス広尾ビル604
email: ianm...@beproud.jp
TEL：03-5795-2707
FAX：03-5795-2708
http://www.beproud.jp/
=======================================

[Anders]

Ok, thanks. The load-time performance for my app is excellent at the
moment. But if responses from the servers start to get sluggish again,
I may try what you suggest, even though I also want my index page to
load lightning-fast, even when the users come in with an empty browser
cache. Even calls to the datastore seem to be much faster nowadays
than some months ago. Very good. Now I may 'only' need to generate a
massive amount of traffic to my site. Peace of cake. Not! :D

> email: ianmle...@beproud.jp
> TEL：03-5795-2707
> FAX：03-5795-2708http://www.beproud.jp/
> =======================================