I have to ask the question....

Is IG Netadvantage for ASP.NET really suitable for a Shared Hosting Environment or any internet based deployment?

I was using 2007 vol 2, but I had to pull everything apart from the Charts.  Page sizes which were all less than 40K started exceeding 200k mainly ig code files such as webresource.axd.

Now usually most of my page size is taken up with images, but this much code per page has been and always will be totally unacceptable. Whole operating systems have been written with less code.

I can accept a 30% to 50% size overhead when using something like NetAdvantage, but 300% to 500% you must be joking!

Zack:

WebResource.axd is simply an HttpHandler that ASP.NET uses to reach into our assemblies to grab embedded resources like JavaScript files or images.  This feature of ASP.NET, added in 2.0, is what allows you to not have to deploy all of the JavaScript files to your server since they are all already embedded in the assembly.

When ASP.NET renders a page with our controls on it, our control tells ASP.NET what script and image resources it needs, and that they are embedded in our assemblies.  As a result, ASP.NET renders the resources URLs using the WebResource.axd handler.  As part of the WebResource.axd URL, ASP.NET appends a bunch of querystring stuff that the handler uses to determine not only specifically which resource in our assembly to grab, but also a timedate stamp that correlates to the assembly version.  So in reality the webpage has something like this in it:

/WebResource.axd?d=RkTKYb30579LZf3nYSUNBcrHOzJQoIwTkY2nCufoJKGUmhQ97WEfKBXm26XVqWSOfyG3GCv5SkfuAVa3sQmCOf34xkWmH2YWaFqDL8veU7Oi9AkXR95FSAD8WG9U26H7aD-pU2Y28FlWmtdhrnqB6A2&t=633277870140000000

In this querystring the value of "d" is the specific resource that should be returned (in this case I grabbed a URL that should return a JS file).  The value is an encoded string that contains the assembly name, fully-qualified namespace and name of the embedded resource.  This should always be a constant value as long as those pieces of data stay the same in the assembly.

Also notice the "t" value in the querystring.  This is a timestamp that, if I recall correctly, is tied to the timestamp of the assembly that contains the resource.

So when the browser sees a URL like this it makes the request for it just like it would for any other resource (eg "/images/foo.gif" ).  The request is handled by the HttpHandler and some embedded resource from the assembly returned to the browser.  The resource returned might be a script file, it might be an image, but regardless, just like every other HTTP request that the browser makes, it will cache the results of that request and the next time a request for that same URL is made, it will try to use the cached version first.  In this case, unless you update the assembly with a new version, the timestamp should remain the same, or change the assembly name, namespace or resource name, the URL will never change and therefore the browser will use the cached version of the resource.

Hope that helps.

Devin

Tony,

I'm confused, as usual You said the webresource.axd file could hold various things (image, JavaScript file, etc) so how can we expect this to be cached? Seems to me if the contents vary as you state there's no way to cache it, unless multiple copies of the file are cached.

Tony,

Thank you for your reply.

I do appreciate your answer and the merits of NetAdvantage.  If I were developing apps for a company intranet then the additional benefits of a rich user environment would be extremely valuable.

Also, if all of my users on the web had high speed broadband ( and this is improving all the time) then I would also be able to handle the increased traffic.

Yet, there are still those out there with dialup, and yes maybe they should be put out of their misery and denied internet access completely.

For the first two groups I may be able to handle 200Kb/page for some pages, but again it is not just line speed that concerns us here, there can be considerable bandwdth costs incurred for high traffic sites.

I am sure that the developers are working hard to get the best balance between rich user experiences and optimum footprint. Yet as the technology improves so do our resource requirements.

Who was it that said 640K should be enough memory for anyone?

The webresource.axd is an extension for ASP.NET and is used to serve up embedded resources.  This could be anything from an Image to a Javascript file to an XSLT file.  In general, these files will be cached by the client upon viewing the page the first time, which means on ensuing requests the file client does not not need to download the resource over again. 

With the files cached, a pefromance focus should be on the initial page load (for first time viewers).  As was suggested earlier, turning on gzip compression is a great way to reduce page size.  Because javascript is a plain text interpreted language, the files normally have a great deal of white space which can benefit from compression.  However, compression must be done at the webserver level, and cannot be done by Infragistics or the components themselves. 

I'm sure you probably already know this, but one last item to watch out for is ViewState.  In most cases, you don't need viewstate turned on - and the NetAdvantage for ASP.NET controls can function fine without viewstate.  If you can go without it, turning off viewstate is a great way to total page size.

As with everything in programming, there are tradeoffs.  Elevating a WebApplication to the next level by providing a rich user experience comes with a cost, namely the size of the libraries on which it builds; whether you're using ASP.NET AJAX libraries, or NetAdvantage For ASP.NET, or Silverlight.  What we aim to do moving forward is limit the "price" you pay to the features your using.  By trimming down the script to only that required to support the set of features you enabled in a given component, we hope to bring the baseline download even further down.  We also plan on doing some whitespace removal as well as some simple 'compression' of the script files which will make them less readable but much friendlier across the wire. 

Thank you for taking the time to list your concerns, and I hope you'll continue to give us feedback on the new list of controls and the direction we are taking.  I'm really interested in hearing how these controls fare in your environment.

Thanks,

-Tony