Latency is Everywhere and it Costs You Sales

Link of the day:


Latency is Everywhere and it Costs You Sales - How to Crush it | High Scalability

"Analysis of sources of latency in downloading web pages by Marc
Abrams. The study examines several sources of latency: DNS, TCP, Web
server, network links, and routers. Conclusion: In most cases, roughly
half of the time is spent from the moment the browser sends the
acknowledgment completing the TCP connection establishment until the
first packet containing page content arrives. The bulk of this time is
the round trip delay, and only a tiny portion is delay at the server.
This implies that the bottleneck in accessing pages over the Internet
is due to the Internet itself, and not the server speed."

A must have tool for all web developers who care about performance

When optimizing web applications it is often a good idea to focus on the frontend.

Yslow is great Firefox addon analyzing web pages and checking some rules for high performance web sites. Unfortunately for IE there was so far no good solution.

Now there is!

AOL Pagetest is a great new free application that does similar things for IE.

Check
http://www.artzstudio.com/2008/07/optimizing-web-performance-with-aol-pagetest/
for a very nice video introduction to AOL Pagetest.

AOL Pagetest even computes the page loading time, which Yslow doesn't (it's tricky). It seems to use an approach, similiar to the one we use.

Great tool!

BlazeDS does not make use of the HTTP caching infrastructure

There were several comments to my post about my doubts about BlazeDS scaling well.

James Ward
said...

Hi Markus,

You have to also consider that RIAs in Flex are
architected very differently than typical web applications. In a
typical Flex application most requests to BlazeDS's servlet handler
will be to either get data (which is then usually held in memory on the
client until the user closes the page) or to update data. Most of the
time when these operations are performed the response will be different
so caching doesn't provide much. If a developer decides that something
should be cached they can easily store that data in a Local Shared
Object (a big, binary cookie in Flash) - or if the app is using AIR
then it can save the data in the local SQLite DB. There are also
emerging open source frameworks that assist in handling this caching.

-James (Adobe)

Thanks James for responding. Yes, I understand that Flex comes kind of from a different angle. A lot of the early Flex applications might have been used to show "real time" data, such as Stock tickers.
And yes with Flex you probably usually only get data from the server, but the same is true for modern web applications. GWT uses a similiar approach for remoting. PURE is a javascript framework that also only sends data. Both GWT and PURE will work well within the Web infrastructure( Web caching proxies for example), because the server can set how long the data should be valid. Actually this meta data about lifetime is send together with the response.
I don't see how I can do the same with BlazeDS.

Yes of course I can build a cache on the Flex side. But that is something that I would have to do in addition and also the life time of the objects in this cache could probably not be controlled by the server.

I therefore still believe that there's room for improvement for BlazeDS.

In a similiar response Stephen Beattie
said...

Hmmm. With a 'stateful' Flash/Flex front-end, there will be less
requests made to the server as only the data is generally requested
once the interface SWF has been downloaded. For the sort of application
where the data is changing frequently, not caching makes sense to me.
Besides you can always implement a level of caching on the server-side
to prepare the data. I fail to see how this affects scalability. If
your data isn't going to change then there's no real need for BlazeDS.
Just load it as gzipped XML or something you can server up with a cache
HTTP header.

Basically he says that BlazeDS is for "real time" data only. IMHO that is a major limitation, because I can't see a technical reason why BlazeDS could not support the HTTP caching infrastructure.

Anonymous
said...

[snip] I wouldn't want my transport to arbitrarily
decide what data to cache and what not to. I would want to build and
control that caching code myself. Not doing that can break
transactional isolation in an application.

[snip]

I want to be able to control from my server how long the data that was just send is valid, because the server for example might now that the data will only be updated once a day.

I doubt that BlazeDS scales

I'm currently researching whether BlazeDS for accessing Java Objects from a Flex client makes sense.
BlazeDS is supposed to be much more efficient than other alternatives such as JSON or SOAP.

Unfortunately it seems that Adobe's open source BlazeDS does not allow one to use HTTP's caching infrastructure. This pretty much renders the more efficient binary AMF protocol pretty much useless for scaling to many users. Fewer requests are almost always better than smaller requests.
Live Cycle Data Services Adobe's commercial variant of BlazeDS has sophisticated offline support. This might help to get things cached, but first it's commercial and second it might be to complicated, if you don't intend to develop full offline capabilites.

[Update:] More information in this blog post.