Also, I'd like to point out a LOT of what you think is dynamic content in
Google land is static-ish.  Search Results don't change every second, and
the ones that do are popular enough that hundreds of 1000s of users are
hitting them.  Don't assume that just because you can't make something go as
fast as Google, that it's because Google is gimping you, more likely it's
because what you are doing, and what you perceive Google is doing are not
the same thing.

 

Oh, and cause I like to brag.  www.cdninabox.com rivals www.google.com for
fastness.  And Yeah any difference in the load times I blame Google for :-)
cause really great page construction means that page is FAST 498ms vs
Google's 244 MS

 

And I know that the reason I'm twice as SLOW as Google is all Ikai's fault. 

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Ikai Lan (Google)
Sent: Monday, May 02, 2011 11:03 AM
To: Google App Engine
Subject: Re: [google-appengine] Re: Is GAE expected to get faster in the
future?

 

I'm not sure where you are getting those numbers from, but the network
routing looks like this:

 

User makes request -> goes to a Google front end -> routed over Google's
network to the serving data center -> request is served

 

The network layer shouldn't add that much latency, though we really only can
make the speed of light go so fast (there's the secret G-relativity project
where we're looking to break this barrier, though).

 

When building webpages, however, once you are under a certain threshold, the
rendering latency is less impacted by round trip latency than you might
think. Niklas is right in suggesting using tools like YSlow. Asset
downloading and JavaScript rendering comprise a very large portion of what
users perceive as slowness. At the end of the day, appearing fast is more
important than actually being fast (see: iPhone application
loading/transition animations). The rules for fast web pages are here:

 

http://stevesouders.com/hpws/rules.php


Ikai Lan 
Developer Programs Engineer, Google App Engine

Blog: http://googleappengine.blogspot.com 

Twitter: http://twitter.com/app_engine

Reddit: http://www.reddit.com/r/appengine





On Sun, May 1, 2011 at 6:35 PM, Yohan <[email protected]> wrote:

Hi Brandon,

So how do you explain that Google serves pages in 50ms when GAE serves
pages at 300ms ? And what to say about Google instant. These guys can
do better than 300ms for sure.

I built my own config on a AWS instance relying on memcache+mysql+php
it would server under 50ms. If you look at appstats it says that the
requests are processed in 8-10ms but it still takes forever (300ms)
before i get it on my computer.  Something is taking too long in GAE
and i can't figure out why. This could be gzip, this could be network
latency (but then i would have the same latency for google.com pages).

Only static files are served super fast, certainly due to the google
CDN which hosts the files in several locations.

Also usually Load Balancers and routers are super fast : look at
Amazon infrastructure, your packet will go through a lot of machines
before reaching your EC2 instance but you still get super fast
response time.

Checkin via AppStats again, GQL and memcache READ can be quite fast
too (<10ms), plus you dont need a GQL query all the time. The PUT
though is very slow but it is understandable given the nature of the
architecture and the load on the DB. Forget about Queries though they
are way too slow even on small entities batches.

300ms-500ms latency seems okay for non busy websites but it starts to
add-up for uber busy sites : when you have 2000 req/s that means more
instances, more memory, etc. and thus even more latency since the
requests takes longer to process.

When the app is not doing much we should expect <100ms response time.
I understand that they are running their own flavor of memcache and
they adapted the API to make it compatible with the memcache API.
There must be other stuff going on too. I'd love to have real details
on what's going on from the moment the request is received to the
moment it is sent back.


On 1 mai, 17:53, "Brandon Wirtz" <[email protected]> wrote:
> Yes that should be 310ms its almost 3am, and I should be sleeping.
>
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Brandon Wirtz
> Sent: Sunday, May 01, 2011 2:39 AM
> To: [email protected]
> Subject: RE: [google-appengine] Is GAE expected to get faster in the
future?
>
> Work on your code.  Typically my requests are serving in 300ms . Of course
> there are a lot of factors, and there are different sweet spots based on
the
> type of thing you are doing, but you should race "Hello World" on the two,
> and Retrieve record containing "Hello World" on the two.
>
> Often very simple code reveals where the issues lie.
>
> Also even if GAE were 10% slower for a small application, the win is when
> you get to the "I'd need 4 machines to do this much work" because then you
> need a load balancer, and you can't do the SQL call via the local machine
> you have to connect via the network, all of these things add time.  
>
> In my experience:
>
> Traditional Setup
>
> 100ms from End user to infrastructure.
>
> 180ms to pass the load balancer
>
> 150ms for Apache/Php/Java to start working on the request (out put hello
> world)
>
> 150ms for SQL to start working on a request
>
> 200ms to get the SQL request
>
> 100ms to write and send to user.
>
> Total time 880ms to server text out of a database as HTML
>
> GAE
>
> 100ms from End user to infrastructure.
>
> 35ms to start working
>
> 75ms to retrieve via GQL
>
> 100 MS to send to user
>
> Total time 305MS
>
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Niklas Rosencrantz
> Sent: Sunday, May 01, 2011 1:48 AM
> To: [email protected]
> Subject: [google-appengine] Is GAE expected to get faster in the future?
>
> I know we can optimize our code so that it runs faster but still I find
> absolute response times from app engine are somewhat slow. Will it get
> faster in the future even though I don't redeploy a new more optimized
> version? I'm comparing with a physical dedicated rack server running a
Linux
> + JBoss with JSP servlets and mysql that responded very fast comapred to
> same view on app engine. Of course we can measure with yslow the relative
> response time which is good on app engine. Thanks for you comments.
> Niklas
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]
<mailto:google-appengine%[email protected]> .

> For more options, visit this group
athttp://groups.google.com/group/google-appengine?hl=en.

>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]
<mailto:google-appengine%[email protected]> .

> For more options, visit this group
athttp://groups.google.com/group/google-appengine?hl=en.


--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected]
<mailto:google-appengine%[email protected]> .
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

 

-- 
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Reply via email to