When you are running your ASP.NET applications inside an application pool with only 1 worker process, everything works as expected. But things usually do not go so smoothly when you run the same application inside a web garden.

What is a web garden

Simply put, a web garden is a single web server running multiple IIS processes. The good thing about this is, there are multiple process which can service your http/https calls. So if a client is holding up one process, the other processes can still continue. Also if a particular process were to hang and restart itself, your website will still continue to serve clients as the other processes are running.

all processes have their own copy of application state, in-process session state, caches, and static data

Let us examine each one of these and see what we can do to workaround it

Application state

Problem Statement

As each process has their own application state, whatever you change in one process will not be updated in another process. As this exists purely for backward compatibility with classic ASP applicationstate, Microsoft does not recommend using this alot, especially for read/write operations.

Workaround

Use Cache instead of ApplicationState if you can.Cached Items

Problem Statement

Be it HttpRunTime.Cache or Enterprise Library Cache, the cache will not reflect latest updates inside a web garden. This is because only the worker process which updated the Cache Item will see the updated values, the other worker processes will not be notified that a change has happened and will continue using the value stored in their in memory cache.

Using web gardens, you will find that the session values gets rotated around. Again this is due to the fact that different worker process is handling your request, and each worker process has its own session state management.

Workaround

Simply change the inproc to either State Server or SQL Server to store the session state outside of the worker process. Performance will degrade when using either of these 2 options, but at least you can be assured of the persistancy of the data

ASP.NET makes custom controls extremely easy to write, but if you are not careful, hard to manage.

There are 2 ways to create a custom control

Writing your own HTML code

Using the controls property

Writing your own HTML code

Using your own properties, you can easily write HTML code to generate the
output

e.g consider a simple scenario where you take in a text and color input and
render the control.

You can simply create a class and extend it from the WebControl base class to
have the functions available to your custom control.
Thereafter, just create the properties you require and use them inside the
Render function.
Do note that you can render different output when in design mode and actual
rendering, all you need is to check the DesignMode property.If however you need input boxes, do take note that you need to handle the
postback event and put the value back into the inputs manually.

publicclassSimpleControl :WebControl

{

public
SimpleControl()

{

}

[BindableAttribute(true),Category(“UI”),DefaultValue(“”)]

publicstring Text

{

get

{

object obj =this.ViewState[“Text”];

if (obj == null) return“”;

elsereturn obj.ToString();

}

set { this.ViewState[“Text”]
= value; }

}

[BindableAttribute(true),Category(“UI”),DefaultValue(“”)]

publicstring Color

{

get

{

object obj =this.ViewState[“Color”];

if (obj == null) return“”;

elsereturn obj.ToString();

}

set { this.ViewState[“Color”]
= value; }

}

protectedoverridevoid Render(HtmlTextWriter
writer)

{

writer.Write(“<font color='”
+ Color + “‘>” +
Text + “</font>”);

//base.Render(writer);

}

}

Using the controls property

The good thing about using the controls property is that you do not need to
care about ViewState (it is handled by the individual control), Postback
inputs handling (handled again by the individual control).

The bad thing is

Have to write your own custom event handlers

Everything needs to be control based, you cannot emit your own html.

publicclassLabelExtendedControl
: Label

{

public
SimpleControl()

{

}

[BindableAttribute(true),Category(“UI”),DefaultValue(“”)]

publicstring xText

{

get

{

object obj =this.ViewState[“Text”];

if (obj == null) return“”;

elsereturn obj.ToString();

}

set { this.ViewState[“Text”]
= value; }

}

[BindableAttribute(true),Category(“UI”),DefaultValue(“”)]

publicstring xColor

{

get

{

object obj =this.ViewState[“Color”];

if (obj == null) return“”;

elsereturn obj.ToString();

}

set { this.ViewState[“Color”]
= value; }

}

protectedoverridevoid Render(HtmlTextWriter
writer)

{

this.Text = xText;

this.ForeColor =
System.Drawing.Color.FromKnownColor(xColor);

base.Render(writer);

}

}

Custom Events

To create your own custom events, you need
to write 3 main items

A readonly object containg the event

A function which will call the Event

The actual event handler itself

privatereadonlyobject EventCreate = newobject();

protectedvirtualvoid OnCreate(EventArgs
e)

{

EventHandler
onCreateHandler = (EventHandler)Events[EventCreate];

if
(onCreateHandler != null)
onCreateHandler(this,
e);

}

[Category(“Action”),Description(“Raised
when a CommandEvent occurs within an item.”)]

ASP.NET offers several forms of caching. They are output caching, HttpRuntime.Cache and finally Enterprise Library Cache. Each of these aims to meet the requirements of different scenarios.

This article shall explore the scenarios which each of these best fit.

Output caching

There are 2 variants of output caching, you can either cache the whole page or portions of the page (these portions must be in the form of user controls)

This is commonly used when the steps to reproduce the page is huge (e.g large database calls, long file read times, huge processing requirements), but the output does not change frequently, e.g a FAQ page listing all the FAQs and employing javascript for inline fuzzy search (employing different scripts for different browsers)

When you use output caching, the output is cached for a specific duration e.g 120 seconds and can be set to vary based on different parameters e.g querystring, browser. In the previous scenario of the FAQ page, you can use the VaryByCustom=”browser” parameter to cache and vary the output based on different browsers.

HttpRuntime.Cache is used to store serializable objects in a cache for future use. This cache is more powerful compared to output caching, but using it requires more work. This is frequently used to cache the return data in business layers.

If you do not wish to bother about the technicalities behind this cache, you can easily add to it via the following code

HttpRuntime.Cache[“key”] = value

This will add the item to the cache with default values for all parameters. Alternatively you can look at the complete declaration for adding an item to the cache

Dependencies: This indicates that this cache item is dependent on another object (usually a file), so when the dependency is changed, the cache object is automatically removed from the cache.

Absolute Expiration: This indicates that the cache item will expire after a fixed amount of time. Once the object expires, it is removed from the cache

Sliding Expiration: This tells the cache to extend the cache item a fixed amount of time each time the cache item is accessed. Once this amount of time is reached and the cached item is not accessed, it will expire

Priority: This tells the cache the priority of the cache item. This comes into effect when the cache is full and items needs to be removed. Items with a lower priorities are removed first.

CacheItemRemovedCallback: This is a delegate function which is run when the item is removed from the cache, the key, value and reason for removal is sent to this function so that you can do the appropriate processing.