Sunday, July 01, 2007

I had a performance problem in my current working on web application; In one of my flows in this application, I had needed to call the database and to update some large amount of data over there, but this action had taken lots of time and the outcome was that users had to wait a long time until this action will be done, admit it, it is frustrating...

My first kind of solution to this problem was to create a new thred from the IIS's thread pool and to assign this action under it - quite good resolution not? BUT, I reminded that asp.net 2.0 (also 1.X) already implements it in a better and friendly way, using Asynchronous Pages.

But first, some Background...
As we all know (or not), when ASP.NET receives a request from the user, it ask for a thread from a thread pool and assigns that request to the thread. In order to this action, the synchronous page holds this thread for the duration of the request, and preventing it from being used by other requests. That leads us to my problem: when I am calling to the database and doing the long long action (an UPDATE query), the thread assigned to the request is stuck doing nothing until the call returns. (This happens because the thread pool has a finite number of threads available).

The Resolution is (of course) Asynchronous Pages.

Asynchronous pages offers a neat solution to such kind of problems. Once an asynchronous operation begins in response to a signal from ASP.NET, the page returns the used thread to the thread pool. When this operation completes, this mechanism asks for another thread from the thread pool and finishes processing the request. This mechanism helps us to manage more efficiently the threads manipulation from the thread pool, because threads that were stucked earlier, now can be used for other porpuses.

Lets see some code:

Firstable, you need to set the Async property on the top on the asp.net page in order to use this thing:

<%@Page Language="C#" Async="true" ... %>

This property set to true, says the page to implement the IHttpAsyncHandler. Regarding this, you need to register the Begin method and End method of to the Page.AddOnPreRenderCompleteAsync.

// Register async methods
AddOnPreRenderCompleteAsync(
   new BeginEventHandler(BeginAsyncOperation),
   new EndEventHandler(EndAsyncOperation)
);

By these actions, the starts its normal life cycle, until the end of the OnPreRender event invocation. At this point the ASP.NET calls the Begin method that we registered earlier and the operation begins (calling the database etc...), meanwhile, the thread that has been assigned to the request goeas back to the thread pool. At the end of the Begin method, an IAsyncResult is being sent automatically to the ASP.NET and let it determine in the operation had completed, a new thread is being called from the thread pool and there is call to the End method (that we registered earlier, remmember?).

Note: We do not need to implement the IAsyncResult interface, the Framework implements it for us.

The Begin and End Methods:

IAsyncResult BeginAsyncOperation (object sender, EventArgs e, AsyncCallback cb, object state)
{
   // Do your things...
   // Call the DB and run the long long query...
}

void EndAsyncOperation(IAsyncResult ar)
{
   // Do your things...
   // Get a response from the DB that the operation is DONE...
}

Nide ahhhu? So use it wisely...

Posted by: Eran Nachum (c)
Post Date: 7/1/2007 11:26:35 AM (Jerusalem Standard Time, UTC+02:00)
Disclaimer | | Trackback   #
 Thursday, June 21, 2007

I had a debate (friendly one of course...) with a co-worker of mine, called Maayan. We discussed about what is the best place to save quite large of data that need to be used frequently in my web application, should we store it in the Application object or the prefered way - store it in the Cache object?

Before we'll go to the conclution, lets get some details about these 2 terms and the vast term called Caching in applications.

2nd before - I am not going to invent the wheel on this post, just to sharpen some points that I think that are missing or came up for most of us...

Caching is the most effective technique you can use to improve the performance of your ASP.NET web application. Designing your application with caching in mind, improves both the performance and the scalability of that application. Caching is about storing data in memory the first time it is requested and then re-using it for the following requests for a specified period of time.

ASP.NET provides very convenient API in order to use this term for the best and easy way, reffered also to Application data object and Output Cache of course.

You can cache the application data using the System.Web.Caching.Cache class. One instance of this class is created per application domain, and it remains valid as long as the application domain remains active. This object is global which means its data is avaiable anywhere at the application scope.

Now, to the big question: What is more recomended for storing the data, Cache object or Application object?

Well, the main difference between them is that he cache object has some more powerful features that allows you to control the cached data. Which this object, each of the data item has its priority state and expiration time. This object has 2 important issues handling: When your system's memory becomes short, the chache object knows to remove data items with low priorety and free its memory, by that the cahce ensures that unnecessary items does not consume valuable server resources.

One more good adventage (in ASP.NET of course) is to cache the pages' data. ASP.NET allows you to cache web pages or portions of them, calling this an output caching. By caching frequently requested pages or portions of them, you can substantially increases your web server throughput and get a fast page response. You can cache pages on devices like: the web browser making the request, the web server responding to the request, and any other cache capable devices such as proxy servers. To read some more information about it go here).

Conclution: I think that for more complex data manipulation caching, the recommended way is to use the cache object and API, but if you want to use and cache some 'dummy' data (or just data that not has to be modified and managed during the application), use the application object (or session object - per user's session) to chach your data.

Posted by: Eran Nachum (c)
Post Date: 6/21/2007 5:12:40 PM (Jerusalem Standard Time, UTC+02:00)
Disclaimer | | Trackback   #
 Monday, June 18, 2007

I sat yesterday in front of my big screen LCD TV at home, and I must tell you that I've enjoyed every step on the game between Real Madrid and Mallorca.

1456 days - this is the time that had pass from the last Real's championship until yesterday evening. After a great comeback from the men in white, (3:1 on Mallorca), this club earned his 30th championship. Until the 79th minute of the game, Barca (the previous champion) was virtually saved its title, but of course Capello's team did the unbelivable, the substitue - Rayas ripped the net twice and lead the men in white to its championship.

I am glad and think that it's a good refreshment (Barca had become a little bit boring...), after all the Spanish league is the best, don't you think?

 (A.P)

Posted by: Eran Nachum (c)
Post Date: 6/18/2007 10:25:38 AM (Jerusalem Standard Time, UTC+02:00)
Disclaimer | | Trackback   #
 Wednesday, June 13, 2007

I know that I am a big fan of Microsoft products and technologhy, but I read today the Safari (from Apple) is ready to download.

Despite this version is still a beta, you can download it to your PC and start playing with it.

I downloaded it just to get the feel impression of it and also to has an idea how my web applications are being showed there... (good for cross browsers suitabilities). And it's nice...

Download is here.

Posted by: Eran Nachum (c)
Post Date: 6/13/2007 8:39:59 AM (Jerusalem Standard Time, UTC+02:00)
Disclaimer | | Trackback   #
 Sunday, June 10, 2007

These days I am working on a very big web application...

In one of my aspx pages I had needed to save lots of data in the ViewState object in order to persist data between postbacks, but when I looked at the rendered HTML, I saw a large hidden field for carring the ViewState.

ASP.NET 2.0 came up with a new feature that helps to reduce the amount of the hidden filed's ViewState data that called: PageStatePersister.

When we add an override the PageStatePersister property and use the built-in SessionPageStatePersister, the behavior of the page remains the same, but the storage used for the bulk of the state data is shifted from the hidden field to session state.

Implamantation instance:

protected override PageStatePersister PageStatePersister
{
   get { return new SessionPageStatePersister(this); }
}

In several cases you'll only want to override this property in your page and to shift the ViewState data into the Sesson object, but if you'll want to use it (wisely of course) on your entire web application? You should implement this property in a particular custom base page and to inherit it to all of your application pages.

The only disadventage that I could think about here is the data existent, session can lose its data and information if its timeout has ended, but ViewState can hold the data forever on the page, because it's hard coded.

Posted by: Eran Nachum (c)
Post Date: 6/10/2007 3:08:17 PM (Jerusalem Standard Time, UTC+02:00)
Disclaimer | | Trackback   #
 Sunday, June 03, 2007

I had installed the AJAX extesions framework on my computer in order to assimilate it in my web application that I am working on right now. I added some AJAX controls such as <asp:ClientScript>, <asp:UpdatePanel> and more, and damn... I find that the markup intellisense no longer works for these controls, or for any controls nested within them.

This happens because my ClientScript control is defined in the master page, and when I tried to drag (create) some other AJAX control in the other aspx pages that inherits the master page, the intellisense was lost.

I found a great solution/trick in ScottGu's Blog, that says that in order to see that intellisense in the rest of aspx pages, we need to leave the master page designer open (isn't it little bit ackward?)

For some more information and tricks (in ScottGu's Blog) you can click here.

AJAX | Bugs
Posted by: Eran Nachum (c)
Post Date: 6/3/2007 3:01:56 PM (Jerusalem Standard Time, UTC+02:00)
Disclaimer | | Trackback   #

Hey, I just can't wait this movie will be coming on screens already, so I have decided to remind you that in 4th of July will be the premier.

Is this logo reminds you somthing...?

So, here is a link to to countdown to Transformers movie with trailers, photos and more (from Yahoo! site)...

See you at the theaters...

Posted by: Eran Nachum (c)
Post Date: 6/3/2007 2:25:30 PM (Jerusalem Standard Time, UTC+02:00)
Disclaimer | | Trackback   #
 Thursday, May 31, 2007

I am working now on a large web application, that need to be used by more than one websites (at least 5 of them, websites and web services), therefore I have needed to do some isolating here with my main core projects.

Some background...
I have a common assembly (web application) that holds only the user controls, server controls and custom controls, which need to serve the all other web applications that are using them. This assembly has a reference to the other web application in order to have some information about some properties, session variables and global members, by this information, it knows to gereate some actions on runtime (or even in design). BUT, in the other hand, this web application need to use the controls that the first assembly has published, here we have a problem, we got a circular references, which is now allowed in .NET framework, also it isn't allowed anywhere I think...

So, how we gonna solve this problem?

The solution is quite simple and is known as Seperate Interface Pattern. (Click here to get some more info).

The main steps to implement it are:
Let define a project that called ProjectA and holds the user controls (etc...) implementations along with InterfaceB. ProjectA would maintain a reference to InterfaceB, which will hold any properties such as members, methods, events etc...

Now, lets define ProjectB which will implement InterfaceA. Now, ProjectB would reference ProjectA and (BUT) ProjectA would not reference ProjectB of course.

The result, ProjectA can access to ProjectB's specific exposed members and ProjectB can use the controls of ProjectA.

.NET 2005 | Bugs | Code | Patterns
Posted by: Eran Nachum (c)
Post Date: 5/31/2007 2:26:25 PM (Jerusalem Standard Time, UTC+02:00)
Disclaimer | | Trackback   #
 Wednesday, May 30, 2007

I read a nice post at Web Worked Daily that holds the same title my post holds...

This post (click here to read it) talks about some very common mistakes that a web worker could do, I aggree that the post is focusing on freelancer web workers, but there are some very usefull topics that can contribute you something even if you are a salaried employee and you want to create yourself at the 'end of the day' a successful online career.

The post speaks also to team leaders that need to plan the project schedule, set missions to her team members (the actual developers), stick on deadlines and to deliver (at last) a fine working project to the development end point. In addition, this post also relates to project managers by that it shows some examples how to manage the specific project properly, how to devide missions in the right way and more...

AND, in the bottom line, it displays its 5 common mistakes...
Enjoy

Posted by: Eran Nachum (c)
Post Date: 5/30/2007 9:25:31 AM (Jerusalem Standard Time, UTC+02:00)
Disclaimer | | Trackback   #