June 2005 Entries

Tech Ed India 2005 Rocks Hyderabad !!!

Tech Ed India 2005 rocks Hyderabad !!! This year Tech Ed, for the first time was also scheduled in Hyderabad and the venue was the most artistic auditorium, the Shilpakala Vedika, Shilparamam.

Two days of mind boggling sessions with Technical Breakouts, Chalk Talks, Deep Dive sessions as well as Architect sessions enthralled the audience by throwing light on the upcoming tools and technologies.

Two things were the highlight of this year,

The Visual Studio Team System - for Developers, Testers, Managers
Service Oriented Architecture - for Architects

The above two topics were analysed in depth and am sure most of the people should have gained some knowledge if not complete knowledge on the emerging technologies.

The session was overwhelmed by sudden rain (in Hyderabad ??!!) which lasted for almost a day. But nothing could stop the enthusiasm of the participants and there were also contents and prizes to be won.

The 2nd day concluded with Rock Star Kauntest which comprised of audience as well as MS FTEs dancing and playing pranks and surprisingly, there were lots of gifts to the audience also.

The 3rd day was a Hands on Lab in the Microsoft Campus, Gachibowli which is really a treat to view and the Labs were filled with crowd for all the technologies despite the heavy downpour that continued from day 2.

The Overall Feedback was Tech Ed Rocks Hyderabad !!!

The Microsoft Tech Ed 2005 Bloggers Contest


Tech Ed India 2005 had a grand opening and is already over in one of five cities, Bangalore. To view the dates for other cities, please check Microsoft Tech Ed 2005 India Registration

Tech Ed provides a very good opportunity to learn about the upcoming Technologies as well as to meet/interact with the Experts / Peers.

This time, there is more !!!

The Tech Ed Bloggers Contest is an opportunity for you to share your thoughts / opinion about Tech Ed. To know more please visit
Microsoft Tech Ed India 205

To participate in the contest you need to submit your Blog Posts to the Microsoft Community. Anyone interested in contributing their thoughts about Microsoft Tech Ed 2005 or associated technologies can add their blog to Tech Ed Bloggers.

Top 5 Entries from each city will win an award !!!

For participation and more information, please visit
Microsoft Tech Ed 2005 Bloggers Contest

Cheers and Happy Contesting !!!

ASP.NET 2.0 : New Caching Techniques - Part II

In the previous article, we saw the SQL Cache Notification and the benefits it provides for invalidating the Cache.

There are other methods which are very useful for enabling / validating cache. We will examine some of them as follows:-

Disk Output Cache
Though Output Cache serves the purpose of avoiding repeated requests to the Server, it cannot withstand Application restarts. Also, Cache is memory intensive and when memory reaches the isolation level, the Cache expires.

With disk output cache, ASP.NET 2.0 can save cached responses to disk in addition to keeping them in memory. When the cached response is removed from the output cache due to memory pressure, it still remains on disk allowing a much larger set of pages to be cached. In addition, disk cached pages survive application restarts, enabling the cache to remain warm for when the application comes back up and begins serving requests. The syntax for Disk Cache enabling in output directive is as follows:-

<%@ OutputCache Duration="3600" VaryByParam="none" DiskCacheable="true" %>

In addition, the disk cache is turned on in configuration and a per-application disk usage limit must be specified. It is important to always set application quota for disk cache as it can easily fill up the disk otherwise.

<?xml version="1.0"?>
<diskCache enabled="true" maxSizePerApp="2" />

In the above settings, the per-application disk usage limit is set to 2 megabytes, as specified in the maxSizePerApp attribute

Disk caching is turned on by default for all pages. To turn disk caching off, specify DiskCacheable=false in the <%@ OutputCache %>directive on the page.

Post Cache Substitution
In .NET 1.X versions if you want a dynamic section inside an Output Cached Page you have to either use Fragment Caching and split the page into Usercontrols and have the dynamic section as an Usercontrol without Caching. This is not always easy since you have break up the whole page into controls for achieving a simple functionality. You felt that right?

Now, you dont have to do that!!!

You have the Post Cache Substitution where you can delegate a call back to the Method which you specify using the Response.WriteSubstitution Method to make the particular section dynamic.

Lets say we have the following method which returns the Current date & time on a page.

static string GetCurrentDate(HttpContext context)
return DateTime.Now.ToString();

Then, in the ASPX Page's Output Directive, we will specify the Output Cache as follows:-

<%@ OutputCache Duration="60" VaryByParam = "none" %>

Now this ensures that the page will be cached for 60 sections.

Next, we will have the following Code in the Page:-

Time: <%= DateTime.Now.ToString() %>

Exact Time: <% Response.WriteSubstitution(new HttpResponseSubstitutionCallback(GetCurrentDate)); %>

The above two statements intially will display the same Time when you run the page for the first time.

However, when you make subsequent refreshes, you will see that, next to Time: you will find the original time and no chance until 60 seconds.

However, next to Exact Time: you will find that the exact time is displayed which implies that the section is not being Cached, though the other sections of the page are cached.

As you can see from the above code, the Response.WriteSubstitution callback executes on every request, and the result gets inserted into the cached response chain that is served from output cache.

This is a very useful mechanism, particularly if you have portions of your section to be maintained very dynamic.

You can achieve a similar functionality by using the substitution control, as explained in my
Earlier Article.

These are some of the new methods available in Whidbey to leverage the benefits of Dynamic Caching of your web pages.

Cheers and Happy Caching !!!

ASP.NET 2.0 : New Caching Techniques


Well, as explained in my previous post, Caching has been improved a lot in Whidbey thanks to the SQL Cache Notification and other new mechanisms which provide way to create robust applications leveraging the power of Caching to improve performance.

SQL Cache Notification
When you enable Output Cache or Fragment Cache for your page, the data gets cached for the specified duration, regardless of whether the data has changed in the database.

The New SQL cache invalidation enables you to make the cache entry dependent on the database, so the cache entry will only be cleared when data in the database is changed.

This way is very useful since you can create the dependency to your Database Table and then set the Cache such that, when the Data is updated, you can ensure that the Cache will get invalidated and subsequent requests gets the New Data. This is particularly useful in scenarios where you show time-sensitive reports such as a Railway Reservation Status or Stock Market Status.

To enable SQL Cache Notification, there are 2 methods.

1. Polling-based Invalidation
This method can be useful when we are targetting SQL Server 2000 / SQL Server 7.0 Database versions since in SQL Server 2005, we have the Notification-based Cache Validation which is even simpler.

The Polling-based Invalidation works by polling to check if a table has been updated since the page was cached.

To enable this, Polling must be enabled for the Database. To do that, the following command needs to be run from the Visual Studio Command Prommpt:-

aspnet_regsql.exe -S ".\SQLExpress" -E -d "pubs" -ed

Where "pubs" is the name of the Database to be enabled for Polling.

This command needs to be executed once for each Database for which we would like to enable Polling.

Next, Polling must be enabled for the Table that we would like to keep checking.

To do that, the following command needs to be run from the Visual Studio Command Prompt:-

aspnet_regsql.exe -S ".\SQLExpress" -E -d "pubs" -et -t "authors"

Where "pubs" is the Database name and "authors" is the name of the Database Table.

Finally, we need to register the notification in the Web.config file of the application as follows:-

<sqlCacheDependency enabled="true" pollTime="1000" >
<add name="PubsDB" connectionStringName="Pubs" />

The pollTime specifies the interval the application takes between consequent polling to the database.

Then, a SQL Dependency can be set at the Page level as follows:-

<%@ OutputCache Duration="999999" SqlDependency="Pubs:Authors" VaryByParam="none" %>

Or, directly for a DataSource, as follows:-

<asp:SqlDataSource EnableCaching="true" CacheDuration="Infinite" SqlCacheDependency="PubsDB:Authors" ... />

Thus, the SQL Dependency has been created for the Authors table in the Pubs Database and once the Data is changed in Authors Table, the Cache gets invalidated.

2. Sql Server 2005 Notification-based Cache Invalidation
SQL Server 2005 offers a simpler way to enable SQL Cache Dependency without requiring to enable Polling for Database/Table and registering in the Web.Config file.

A notification based dependency is configured on the OutputCache directive using the string CommandNotification. This value indicates to ASP.NET that a notification based dependency should be created for the page or datasource control.

To Enable Notification-based Cache for a page, the following is an example:-

<%@ OutputCache Duration="999999" SqlDependency="CommandNotification" VaryByParam="none" %>

To Enable for a DataSource,

<asp:SqlDataSource EnableCaching="true" SqlCacheDependency="CommandNotification" CacheDuration="Infinite" ... />

Whenever a command is issued to Sql Server 2005, ASP.NET and ADO.NET will automatically create a cache dependency that listens to change notifications sent from the Sql Server. As data is changed in Sql Server, these notifications will cause the cached queries to be invalidated on the web server. The next time a page or datasource control associated with the dependency is requested, the page or datasource control will be executed again as opposed to serving cached information.

There are other techniques such as the New Fragment Caching API, Disk Output Caching which we will explore in the future articles.

Cheers and Happy Caching !!!

ASP.NET 2.0 : Nothing but Caching - All about the new Caching features in ASP.NET 2.0

Its long time since I wrote about Whidbey and particularly after the release of Beta 2, the focus of Developers has been much towards Whidbey. So I thought of writing about one of my favourite topics - Caching.

Caching has been a concept for study for a long time and I have heard about people who are doing their Doctorate Research in the field of Caching.

Much to the ease of developers, enabling Caching for your ASPX Page was as simple as specifying it in the Page Directive in .NET 1.x versions. To know the amount of work involved in enabling Caching prior to .NET, during the ASP days, check
This Article

But, to the surprise of all the Developers, Microsoft released the .NET 1.X versions with the System.Web.Caching.Cache class as a Sealed Class. The possible reason for that is, (according to information from a popular speaker) they had the vision to improve it a lot for the subsequent version which is Whidbey. They didn't want people to inherit the class and write their own customizations just to avoid issues, when they migrate from 1.X versions to Whidbey.

Having said that, Caching has been improved a lot in Whidbey. In .NET 1.x versions, you just had 3 options

1. Output Cache - Where you specify the cache in the Page Directive with properties such as VarybyParam, Duration etc.,

2. Fragment Cache - Where you specify the cache in the Usercontrols (again you do an Output Cache) but for the individual controls just to have static as well as dynamic sections of your web page.

3. Using the Cache API, you can do it from the code by manually adding and removing items from the Cache. You have to use this method if you want to set dependencies of your Database Table changes.

However, in Whidbey, you have a whole set of new features. Just to list them down:

SQL Cache Notification
2. Using the Disk Output Cache
3. Post-cache Substitution
4. SQL Cache Invalidation
5. Cache Configuration

and much more.....

In the forthcoming articles, we will examine each of the New features extensively.

Cheers and Happy Caching !!!

Microsoft Architecture Webcast Series - Making the Connection


The Microsoft Architecture Webcast Series is an initiave to connect people with experts to learn more about the future of Service Oriented Architecture (SOA) and other technology vision topics.

The Webcasts are a series Live Webcasts spread across different topics such as

Connecting Your Business with Service Orientation (Level 300)
Creating a Shared Technology Vision (Level 300)
The Value of Reusable Frameworks (Level 300)
Examining Enterprise Service Patterns (Level 300)

What's more?

Attend these webcasts, evaluate and you can select a free Book (available only within US) and also a chance to win a Portable Media Center.

You need to attend the Webcasts and evaluate them for qualifying for the prizes.

More information and registration is available at

Happy Days with Webcasts !!!

Tips for ASP.NET Application Performance Enhancement


Hi All,

Though I have written about this some time back, Performance and Scalability stand next to Security in the case of Applications and is the most sought after topic wherever people raise queries.

I have compiled a set of Tips and Tricks to improve the performance of ASP.NET Applications in particular, where I have drilled down and explored a lot and have faced crunch situations from which I keep learning.

These tips can be followd during deploying ur app on the production server

A Foreword is that, these are general tips and are not exhaustive and its always better to share any new thoughts whenever we arrive at them, which will benefit the rest of the community.

Now, lets drill down into the Tips :)

In the Application Web.Config File

1. Set debug=false under compilation as follows:-

<compilation defaultLanguage="c#" debug="false">

When you create the application, by default this attribute is set to "true" which is very useful while developing. However, when you are deploying your application, always set it to "false"

Setting it to "true" requires the pdb information to be inserted into the file and this results in a comparatively larger file and hence processing will be slow.

Therefore, always set debug="false" before deployment.

2. Turn off Tracing unless until required.

Tracing is one of the wonderful features which enable us to track the application's trace and the sequences. However, again it is useful only for developers and you can set this to "false" unless you require to monitor the trace logging. You can turn off tracing as follows:-

<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true"/>

3. Turn off Session State, if not required.

ASP.NET Manages session state automatically. However, in case you dont require Sessions, disabling it will help in improving the performance.

You may not require seesion state when ur pages r static or whn u dont need to store infor captured in the page.

You can turn off session state as follows:-

<sessionstate timeout="20" cookieless="false" mode="Off" stateconnectionstring="tcpip=" sqlconnectionstring="data source=;Trusted_Connection=no">

While developing using Visual Studio.NET

1. Select the Release mode before making the final Build for your application. This option is available in the Top Frame just under the Window Menu option. By default, the Mode is Debug

There are several things happening when you Build/Re-Build applications in the Debug Mode. First of all, it creates an additional PDB File under your BIN directory. This holds all the Debug information.

Secondly, the Timeout is very high since you require higher time out frequency while debugging such that your process hangs on until you get to the exact break point where error is there.

So, selecting Release Mode will greatly improve the performance of the application when u deploy.

General Methods to improve the Performance

1. Disable ViewState as and when not required.
ViewState is a wonderful technique which preserves the state of your form and controls. However, its a overhead since all the information needs to be stored in the viewstate and particularly if you are building applications which target Dial Up Internet Connection Users, ViewState can make your application very slow. In case you dont require viewstate, disable it.

You can disable it at different levels ex., for Page, Control etc., by setting

2. Avoid Frequent round trips to the Database.
Calls made to Database can be quite expensive in terms of response time as well as resources and it can be avoided by using Batch Processing.

Make calls to Database as mininal as possible and make them last even lesser time. Use of DataAdapter wherever applicable is very useful since, it automatically opens and closes Connection whenever required and doesnt require user to explicitly open the connection.

A number of connections opened and not closed adequately can directly influence in performance slow down.

3. Avoid Throwing Exceptions.
Exceptions are a greate way to handle errors that occur in your application logic. However, throwing exceptions is a costly resource and must be avoided. Use specific exceptions and use as minimal as possible to avoid resource overhead.

For example, catching a SQLException is better when you expect only those kind of exceptions instead of a generic Exception.

4. Use Caching to improve the performance of your application.
OutputCaching enables your page to be cached for specific duration and can be made invalid based on various paramters that can be specified. The Cache exists for the duration you specify and until that time, the requests do not go to the server and are served from the Cache.

Do not assign cached items a short expiration. Items that expire quickly cause unnecessary turnover in the cache and frequently cause more work for cleanup code and the garbage collector.

In case you have static as well as dynamic sections of your page, try to use Partial Caching (Fragment Caching) by breaking up your page into user controls and specify Caching for only those Controls which are more-or-less static.

For more details regarding caching look into
ASP.NET Caching Features

5. Use appropriate Authentication Mechanism.
The Authentication Mechanism you choose determines the cost associated with it and hence select the appropriate mechanism. An informal but useful order is as follows:-

Authentication Modes

1. None
2. Windows
3. Forms
4. Passport

6. Validate all Input received from the Users.
User Input is Evil and it must be thoroughly validated before processing to avoid overhead and possible injections to your applications. Use Client Side Validations as much as possible. However, do a check at the Server side too to avoid the infamous Javascript disabled scenarios.

7. Use Finally Method to kill resources.
In your Try..Catch.. Block, always use the Finally method to close Open connections, Open DataReaders, Files and other resources such that they get executed independent of whether the code worked in Try or went to Catch.

The Finally method gets executed independent of the outcome of the Block.

8. The String and Stringbuilder Magic.
Perhaps the most ignored type in .NET is the stringbuilder. I am sure many of us are not even aware of Stringbuilder and its advantage over string (atleast I didnt know for 1 year :))

String is Evil when you want to append and concatenate text to your string. In other words, if you are initially creating a string say s = "Hello". Then you are appending to it as s = s + " World"; You are actually creating two instances of string in memory. Both the original as well as the new string will be stored in the memory. For that matter, all the activities you do to the string are stored in the memory as separate references and it must be avoided as much as possible.

Use StringBuilder which is very useful in these kind of scenarios. For the example above, using a StringBuilder as s.Append(" World"); which only stores the value in the original string and no additional reference is created.

9. Avoid Recursive Functions / Nested Loops
These are general things to adopt in any programming language, which consumes lot of memory. Always avoid Nested Loops, Recursive functions, to improve performance.

Having said that, proper functions and call backs do increase the performance instead of having a huge chunk of lines of code in single method.

The above are just pointers to improve the performance of your application and are just illustrative. There are many more ways in which you can improve the performance of your applications. I havent dealt with IIS and SQL Server side tips to improve performance which I would explain in my forthcoming articles.

The above are my view and a collective response from various resources and you are welcome to share your views / corrections if any.

Cheers and Happy Programming !!!