+972 52-548-6969
Atlas weight issueswhat am I missing?
I have the strong feeling that I am missing something. We have just run into a major slow down in one of our pages, as a result of adding the CalendarExtender. This led me to do some searching, and I am not sure that I can believe the results.
Let us take this simple page:
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="test.aspx.cs" Inherits="ExplodingMonkeys.Web.test" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<asp:TextBox ID="Date" runat="server" />
</form>
</body>
</html>
When rendered to the browser, it weight 528 bytes. Now, let us add a <asp:ScriptManager runat="server"/> to the page. The size of the page exploded to 79 kilobytes, from this change alone.
I then added the following to the page:
<ajax:CalendarExtender runat="server" TargetControlID="Date" CssClass="ClassName" Format="MMMM d, yyyy"
PopupButtonID="http://ajax.asp.net/ajaxtoolkit/Calendar/Calendar_scheduleHS.png" />
The page size reached 143 kilobytes. I am pretty sure that I am missing something here. I enabled both caching and compression in the web config:
<
scriptResourceHandler enableCompression="true" enableCaching="true" />And then tried again. The results were better, but not really encouraging.
With just script manager: 79 KB (56 KB from cache)
With calendar extender: 143 KB (115 KB from cache)
Just to make it clear, there is a noticable delay on our pages, it went from being instantenous to taking four or five seconds. And I am talking about localhost testing, on powerful machines. (Again that HTTP 2 connections per server issue, I think).
Am I missing something, or are those the real numbers?
More posts in "Atlas weight issues" series:
- (01 Mar 2007) Take 2
- (28 Feb 2007) what am I missing?
Comments
Is that the actual page size or page size including scripts? If that includes the scipts, you may be seeing the debug scripts.
This is the page size with the scripts, and I am certainly getting the debug scripts, I though that enabling compression would drop the size, but it didn't.
I also tried recompiling in release, and I didn't see any difference.
Do you have debug disabled in your web config? We found that performance was way slower with Atlas scripts because it doesn't cache the scripts but instead downloads them again for every page.
May or may not be relevant.
CalendarExtender very strange control. We put 4 this controls on a page... It's nightmare. Page on load eat 100% processor for 10-30 sec. Each popup call eat processor for 5-20 sec.
As result, I replace a CalendarExtender with simple javascript popup datepicker.
I am having the same problem.
It kind of defeats the purpose of being all ajaxy if the website is now slow.
If you have the <compilation debug="true"/> switch set in your web.config file, ASP.NET AJAX will send down debug scripts to the browser. This has much more diagnostic information in them, and they will not be cached in the browser - which means they will be downloaded on each request.
When you set <compilation debug="false"/> the scripts will be both compressed and cached on the client. The debug diagnostic spew is also turned off.
If you add a <asp:scriptmanager/> control's core script is about 14-16k compressed (and cached forever for your site). You shouldn't see any slow-down with this (note: prototype's core library is now 75k).
Note that if you use FireFox to measure download size, it reports uncompressed size numbers and not the compressed versions - so that can throw you off. JavaScript typically compresses to ~20% of the origional size.
One last thing to check - make sure the CalendarExtender was built in retail mode, and not debug mode. In the current AJAX Control Toolkit drop it generates its JavaScript at build-time, and so if you have a debug version of the assembly you will have the uncompressed scripts. I believe the update later this week of the toolkit switches this (since this is a common gotcha).
Let me know if you still have issues after this and I'd be happy to help.
Thanks,
Scott
I have to agree with Scott here.
Atlas does add overhead to your page but not nearly as much as prototype and definitely scriptaculous.
I'm a prototype/scriptaculous user by the way.
I'm rather dissapointed that prototype is becoming such a slow beast and on top of it all it breaks other libraries like fvalidate for example.
IMHO ms ajax is a far better product than prototype is. But prototype is bundled with most of the popular MVC frameworks. Try handling json as easily in prototype as in ms ajax for example.
If you have a page that relies as heavily on prototype as the controls from the atlas controls toolkit do you will see that the prototype page is far slower than the atlas page.
I don't think your comparison is fair. Definitely with the calendar because that comparison should have been made with an equivalent prototype calendar.
MS does make a lot of mistakes but ms ajax isn't one of them.
Also nobody tells you you have to use the control toolkit.. you can do it the prototype way and build your own versions of them if those aren't what you were looking for. Nobody says you have to use control extenders etc.
I would like to take exception to this:
Um, if I am going to do it myself, what is the point of using atlas?
Thanks for letting me know about it, I posted the new finding here:
http://www.ayende.com/Blog/archive/2007/03/01/Atlas-Weight-Issues-Take-2.aspx
As far as I can see, the CalendarExtender is the one to blame here, and I have decided to drop it.
Just a note about prototype, after javascript clean (stipping comments, etc) the library is ~25Kb, and compressing that put me at ~15Kb.
It is then cached, both on the client and on http.sys
Ivan,
Talking about the richness of the javascript library, I am liking prototype much better.
I am not seeing much in MS Ajax that excites me, to tell you the truth. The server side extenders are nice, but they are very focused on their scenarios, and I tend to find their limitations very quickly.
Ayende,
I use prototype most of the time. I even put up a couple of widgets based on prototype.
I used the atlas client library long ago before I discovered castle. For me prototype has gotten to the place where I gather all the scripts with a handler compress them and render them out as one big javascript file because firefox takes ages to load otherwise.
I just found your dismissal of the atlas library pretty harsh and uncalled for. And I think you hold a lot of weight in the community so I wanted to give a counter weight.
I didn't mean to offend you or anything. And if I can quote you from one of your older posts where you defend the fact that in a project you were working on at that time you had a couple of different calendar controls because the ones out of the box don't do what you would like them to do. I didn't think it would make a difference for you to have to roll your own but a proper one then, one that fits your needs. Also I thought that comparison was also true for javascript components.
The calendar from the control tookit sure looks a lot like the one from component art which is also pretty heavy :)
I didn't really mean to start a discussion ;) In general I take in what you write like cookies and milk.
Anyway I've been meaning to try atlas with castle.. hopefully i can get to it quickly and I can get some homegrown benchmarks, I wouldn't hold my breath as I'm swamped for the moment. It made me curious as to which is faster and better.
I should have kept my mouth shut until I took the time to explore the ms ajax rtm library properly. And for that I apologize
I would really have loved a delete button for the comments right after I made my first one
Ivan,
You didn't offend me. And I would like to start a discussion. In the subject of ajax libraries, I am certainly would not consider myself an expert, and I would welcome any input.
About the several calendar controls, that was more an issue with the way I presented the information. Think about something like Outlook's calendar, where you have to display many items inside a calendar, not a date picker.
I generally don't have an issue with building my own stuff, I just want to make sure that I am not doing an NIH.
I much rather like it when people disagree with me, because then I can understand why. A world with a single point of view is a very boring world.
I would be the first to admit that I am probably biased. It is not that I don't think that MS Ajax isn't a good java script library, I find that is has some nice features, but I just don't see anything there to get excited about. Once again it goes back to "why do we need it over XYZ?"
The server side stuff is nice, but I am doing a lot more in the client side, and there I am running into limitations because the way I work and the way Atlas is designed are different. There is a lot more emphasis on events than on control flow, for instance.
I have evaluated a lot of the ajax frameworks out there. Atlas lost my intrest in september because of the number of bugs.
I agree but it's a javascript library :) not something to get really excited about in general.. What I look for is collection handling, response times for ajax requests, possible date handling etc.
A good point for ms ajax is the way it can localize things properly and the fact that it adds a lot of value to the datetime object. As stated before the tight integration with json if you use their webservices. They extend a couple more types than prototype does.
And yes I also agree that there are far too many libraries out there that all do exactly the same.
Both libraries do the collection handling properly.
My biggest problem is that I need to install something in the GAC to get ms ajax fully working.
I won compare with jquery for example because their way of doing things is just asking for trouble later on. They make it a little to functional in my opinion. Dojo is like an elephant that doesn't always work btw.
The library from yahoo is the one that i've used to extend prototype with controls or I wrote my own.
I will try to create a benchmark page over the weekend because it really interests me to know which one is the most interesting. For me the library doesn't matter it's the end product that has to benefit from it. And I want to get the best tool for the job.
Just to point out, you don't have to install anything to the GAC to use MS Ajax.
You just need to put System.Web.Extentions.dll in the bin folder.
Comment preview