Why is Ra-Ajax so slow...?

December 04, 2008
Today we had this question about Why Ra-Ajax is so slow on our newly created support system (Stacked) which we've btw Open Sourced for you to download from Google.

Is Ra-Ajax slow like a turtle?

And there's a couple of funny things I feel exists within the boundaries of this question. First of all the perception of that Ra-Ajax is slow is something we have overlooked for far too long. Second of all if we hadn't created Stacked and made the registration process so dead simple (uses OpenID) this user might never have asked us about this.

Make feedback *easy* on your projects I guess the lesson here is ... ;)

Anyway I *LOVE* this question, and I should have answered it a *LONG* time ago, I guess it took something like Stacked before I could get my hands out of my ass and start answering it...

Ra-Ajax *IS* slow(er), yes!


Ra-Ajax *is* slower then pure client-side DHTML libraries. This is in the nature of Ra-Ajax and comes from the fact that almost everything you do will trigger a server-side Ajax Request. That means that a pure client-side library will perform faster when choosing to for instance switch months in something like our Ajax Calendar.

However if there are parts of your application that needs extreme speed there is nothing that stops you from doing those things purely on the client, either through creating your own Extension Control directly in Ra-Ajax, or using jQuery "on the side"...

True story coming up!
When I worked for Gaiaware (my previous Managed Ajax library for ASP.NET) we had the third largest website in Norway as our customer (NRK) and when they created "Ut i vår hage" they had 20,000 users coming into the system per *MINUTE*! And this system was *heavily* infested with Gaia Ajax Widgets and it still ran on *one* server. Sure the first Thursday the show ran the server had a meltdown. And we were really scared to get the results. Obiousy NRK called us first thing in the morning the day after and we got the code to look at since they were deadly scared too and didn't want to repeat this the next Thursday.

They mentioned in a *very* hard tone that "if this problem isn't fixed PRONTO we will throw Gaia Ajax OUT and start using jQuery instead". And they actually had a parallel effort where one of their JavaScript gurus was dragging jQuery into the project "from the side". Replacing one portion of the project at the time to get "Gaia OUT"...!

When we got the code we discovered a problem with the usage of caching on the server. They had a bug when repopulating the cache which made all 60,000 users (or something) go to fetch a fresh version of their cache when the cache timed out. To make things worse, the fetching of the fresh data went across WebServices... :| !!

We implemented a lock and a dual check. It's an easy hack, yes I know, but it works... ;)

One check for cache miss outside the lock and another inside the lock to see if some other thread had updated the cache after the cache was checked outside the lock. Then we did a couple of other changes (concatenating JS files and such), but this was mostly to please NRK since we knew that the cache fetching was the problem. But their weblogs saw lots of refetching of our JavaScript files which made the servers meltdown, and they concluded with that the fetching of multiple JS files from the same server was the problem, even though we *knew* this was just a symptom. We knew this since when a website crashes the first thing a user does is to hit F5 which clears the cache and reloads all JavaScript. And the Cache bug obviously would crash the system...!

But we did some other custom changes anyway to smoothen their nerves! Remember NRK.no was (and is) the 3rd largest website in Norway. These guys had *priority* for us ... ;)

Anyway, next Thursday came and everything worked perfect! Friday after the second (and successful) run they removed the portions of their app which required jQuery in fact. Because now they wanted to do everything the "Gaia way" since it was 100 times easier and also proved not to be anywhere *NEAR* a performance problem for them.

There are a couple of interesting pieces of information here, first of all at that time I had done literally *everything* in Gaia Ajax of development. So I know for a *fact* how the Gaia Ajax Widgets Architecture looked at back then. And it had roughly 300KB of JavaScript divided into about 10-15 files. This is HUGE! In addition we used Reflection on all Gaia Ajax WebControls on the server. Once for *every* property to check which properties had changed. And all though we had some caching of things like PropertyInfo and so on, this demanded a significant amount of server resources.

Still it could serve 60,000 *simultanous* users (or something) on one server featuring live chat (polling every 10th second I think) and a lot of really cool goodies. When the second Thursday had passed NRK was so impressed by Gaia that one of their Chief Architects actually blogged about it and released his performance results where he could proove that Gaia performed almost 20 times as fast as ASP.NET AJAX. He concludes with that you "shouldn't use Prototype.js or jQuery but rather Gaia Ajax Widgets".

Pretty strong statement ... ;)

To compare these results a little bit to Ra-Ajax and put them in perspectives. Ra-Ajax has less then 20KB of JavaScript, in fact less then 10% of what Gaia had at that time, and as far as I know also today. In average you will spend something like 9KB of JavaScript divided into 3 different JavaScript files in Ra-Ajax, and there's no reflection at all on the server. Instead of using Reflection to load properties at runtime we're using a Dictionary object when changes are *done* to the Controls to remember which properties have changed. This should decrease the stress on the server-side by orders of magnitudes compared to Gaia.

Not only that but our Stacked installation which is basically a clone of StackOverflow.com which we now have spent less then one week implementing scores *82* (B grade) in YSlow. If you compare this to StackOverflow which Joel and Jeff have probably spent months, if not years developing you will see that StackOverflow scores *69* in YSlow.

In fact StackOverflow has D grade, 69 in score and in total 156.7 KB of download to the browser divided into 11 HTTP requests where 55.3KB are JavaScript files. Our Stacked installation has *82* in YSlow score (higher is better), a B grade, 109.5KB of total download, divided into 13 HTTP requests (only place where SO.com beats us) where 18.4KB was JavaScript. And in fact more then 50% of our JavaScript is Google Analytics (check it out if you don't believe me)

This means that StackOverflow has about *14 times as much JavaScript* as our version of Stacked have. When you put all these facts together you realize that you could probably build a better version of StackOverflow.com using Ra-Ajax. And in fact I intend to prove that with Stacked ;)

In fact I bet you could easily build Digg, YouTube and even Google.com using Ra-Ajax without feeling any huge penalties compared to any of the alternatives. Sure for "extremely huge website" like YouTube you need to take "extremely huge performance and scaling precautions", but that is no different with or without Ra-Ajax...

Ra-Ajax is DEADLY FAST! There are *no* performance problems in Ra-Ajax unless there's a BUG in it that we have managed to overlook or something. Check out the screenshots below, both are taken with an empty cache. The first one is taken from Stacked from a Norwegian laptop. The second one is StackOverflow.com. I'll let the images speak for themselves...


Stacked performance
Stacked - implemented using Ra-Ajax


StackOverflow.com performance
StackOverflow.com - implemented using Microsoft MVC and jQuery


In fact even our Viewport Ajax Calendar Starter-Kit loads on my computer in 1.427 seconds with an *empty cache*. And that sample features some *heavy* Ajax! Pretty cool considering I need about 10-20 seconds loading something similar from ExtJS... ;)

So why is Ra-Ajax slow then?


Our servers are in Norway, and Norway is *very* close to the "end of the world" when it comes to incoming lines and bandwidth from mostly any other country in this world. Norway doesn't have ONE international popular website, so it's probably close to the bottom of the list on non-Norwegian ISPs when it comes to traffic lines. Next to countries like Ghana and Tibet. This means that merely creating an HTTP request to Norway from e.g. the US is highly likely to be orders of magnitudes more expensive then making one to the US from inside the US...

Have that in mind when "measuring the speed" of Ra-Ajax...

Also our servers are the *cheapest servers money can buy*. We are LGPL and make NO money on Ra-Ajax, even though we try to sell Starter-Kits. (that's a HINT BTW if you're one of our users - Donate is HERE and to purchase a Starter-Kit is HERE!)

This means that if the Ra-Ajax Samples (at our servers) feels slow it is highly likely that the reason is either the fact that we're in No(r)way, or the fact that our server is the cheapest thing money can possibly buy, or the fact of that our servers historically are frequent victims of DOS attacks because of that I say things that upsets many people so much that they start DOS attacking us - like for instance that Silverlight SUCKS!

In fact below is a screenshot of a couple of Ajax Requests towards our TreeView Sample taken from an American friend of me. Matthew MacSuga...

Matthew measuring performance of Ra-Ajax from US

Thomas measuring from Norway

Now if you compare those two images above you will see that one performs three times as fast as the other one. This is because Matthew was doing this from the US. And even these numbers are *nice*. Often the difference is WAY worse than this, I've had users telling me FireBug reporting seconds passing while waiting for their Ajax Requests to return while I was trying at the same time and it took 25 milliseconds doing the *exact same thing* from No(r)way...

So if you think that Ra-Ajax is slow then I encourage you to download it and test it on your *own* servers. Or at least some server which is *not* at the end of the world. If you however discovers a bug in Ra-Ajax (there might be bugs in Ra-Ajax) you are free to submit it and we'd be VERY happy if you told us about it. Especially if it was a performance related bug. But my guess is that you will discover that Managed Ajax is way faster then whatever needs you could possibly have in this world. Not only are Managed Ajax 10x on Time2Market, it is also 10x on SPEED!

Managed Ajax rules! ... ;)

Note also that *IF* you for some reasons still think that Ra-Ajax is slow or your site experiences huge amounts of traffic then you can use all the same mechanisms in Ra-Ajax as you can in normal ASP.NET since Ra-Ajax is nothing but a thin mechanism on top of ASP.NET which means that all the scaling fatures of "normal" ASP.NET also can easily be incorporated in Ra-Ajax like Web Farms, caching and so on. To scale a Ra-Ajax application is identically to scaling a normal ASP.NET application...

And if you think that some specific operation is just TOO costy to go towards the server, there is nothing stopping you from pulling in jQuery or doing a Custom Extension control with tons of JavaScript doing that specific thing on the client and combining it with the places you want to use the "Ra-Ajax model" elsewhere. In fact Ra-Ajax have a very good WebMethod implementation for just these kinds of scenarios, though I have still not used them, and I probably never will either... ;)

But my guess is that you will not experience this unless you break something *else* in your application. Like for instance have seconds of server CPU spent in Page_Load or something. Or uses Session as if it was "free" etc...

But in case you think I'm wrong, you are free to publicly *destroy me* in blogs, forums and similar places. And tell ALL your friends how much Ra-Ajax sucks in regards to performance. So far I have seen NOBODY doing it though. In fact I am 100% confident in that Ra-Ajax rules! Also on performance! But No(r)way SUCKS! Especially our servers in regards to HTTP speed from non-Norwegian countries :(

But don't blame that on Ra-Ajax...

Addendum...
We *are* looking for sponsors to get better servers in the US, if you're interested send me an email to thomas@ra-ajax.org letting me know. Sitewide "thank you links" is your reward for a GREAT server... :)


.t

<< Previous - Selectors for WebControls - Querying into the Control hierarchy on the server
jQuery'ish Selector for WebControls [recursive FindControl] - Next >>

Copyright

All content at this blog is the Copyright of Ra Software AS but can freely be distributed under the terms of GNU Free Documentation License.

Copyright 2008 - Ra Software AS - Sitemap