Breaking News

Monday, May 30, 2011

ASP.NET: Async calls vs threading

This answers following questions:

  • How to improve performance?
  • Should I ever use Threading in ASP.NET?

How to improve performance of an ASP.NET MVC page that calls a database which takes a specific amount of time, and the results are then rendered on to an html page? This means, for instance, if 4 method calls takes 4 seconds, then target is, to improve the performance to 2 seconds for 4 database calls.

   1: string strReturnValue1 = CallDB("SomeStoredProcedureThatTakes1CompleteSecondToProcess1");
   2: string strReturnValue2 = CallDB("SomeStoredProcedureThatTakes1CompleteSecondToProcess2");
   3: string strReturnValue1 = CallDB("SomeStoredProcedureThatTakes1CompleteSecondToProcess1");

Takes exactly 3 seconds.

Move it inside a web service, and then call:

   1: yourWebServiceObject.CallDB +=  new CallDBCompletedEventHandler(CallDBCompleted); 

Define a handler:

   1: void CallDBCompletedEventHandler(object sender, CallDBCompletedEventArgs e)
   2: {
   3:     SomeLabel.Text += string.Format("Return value: [{0}]<br/>", e.Result);
   4: }

Lets call it async'ly:

   1: yourWebServiceObject.CallDBAsync("SomeStoredProcedureThatTakes1CompleteSecondToProcess2");
   2: yourWebServiceObject.CallDBAsync("SomeStoredProcedureThatTakes1CompleteSecondToProcess2");
   3: yourWebServiceObject.CallDBAsync("SomeStoredProcedureThatTakes1CompleteSecondToProcess2");

Takes ~1 second.

How so?

The I/O thread(completion ports or IOCPs) use the ThreadPool, but they use IOCP, which do not interfere with ASP.NET requests. Therefore, you can safely use the asynchronous call to a web service, and update the page accordingly; for instance using UpdatePanel.


These web service asynchronous calls, uses IOCP behind the scenes, freeing ASP from essentially all of the burdens.

I could have done it using the thread pool as well?!

Usually, unless we want to parallelize a CPU-intensive operation in order to get it done faster, it is generally *not recommended* to use a worker thread; this eventually will starve the ThreadPool in an ASP.NET process by queuing too many work items.

Don't forget that you also use Reactive Framework in your ASP.NET app to do the job async'ly.

For instance,

   1: var o = Observable.Start(() => { CallDB 
   3: ("SomeStoredProcedureThatTakes1CompleteSecondToProcess2"); Popup.Message("Done."); Popup.Show (); });
   4: o.First();   // subscribe and wait for completion of background operation

Takes ~1 second.

This and this a very interesting article targeted to performance as well as scalability gains in a web app.


Read more ...

Friday, May 20, 2011

Is ‘jQuery vs Silverlight’-comparison even possible?

Some "time" back, I was given a choice to decide between jQuery and Silverlight.

I did not delve into the discussion of what Silverlight is and what jQuery is. I just presented the solution, using jQuery for lightweight UI's, Silverlight if its intranet based.

First, please understand that Silverlight is not Macromedia Flash. It is far more superior, and elegant; -- and -- it has the "capabilities" of Flash.
[Image shamefully stolen from Silverlight/Javascript interop library :0) ]
Silverlight and jQuery "may be" intended for similar things, rich user interface, but Silverlight has a complete framework that utilizes the power of .NET and provide rich feature set.
Actually comparing jQuery and Silverlight feels like comparing a red-apple with one-hundred-acre'd-fruit-farm.

Ok, that may be indigestible example, but that's how it really is.

Silverlight comes with a framework, while jQuery is just a JavaScript library. JavaScript -- that is used to play around with DOM elements; meaning? Find and manipulate the html elements. It is just ~30KB in size.

So, how can you compare the two?
The only way you *can* look into the two is from the UI perspective, both can be used to develop Rich Internet Application(RIA); for instance, the data grid provided by Silverlight, and the data grid provided by jQuery. Obviously in that case, jQuery is lightweight. But then again, you might need to "extend" the jQuery data grid to your custom needs. Its JavaScript, so you've got your length and breadth to play around.
Also, you can use jQuery inside Silverlight app, but you cannot otherwise.

The only problem is that, Silverlight requires to be downloaded, similar to Macromedia Flash plugin, but once you download it, you're good to go. Plus, with MEF(Microsoft Extensibility Framework) it feels cool to "componentize" a Silverlight app and load modules on-the-fly and on-demand.

So, must if you choose between the two, go for jQuery if you are considering a web based line of business - lightweight and simple;

And if its a web application, which means, intranet based application for some corporate customer, you can always play with the Silverlight and its features. It can help providing native windows application on the web.

The questions that may help you reach a decision: 

0. What feature set customer is looking for? What domain does it belong to? For instance, for a media company you might choose Silverlight UI for a web based app, rather than a jQuery.

1. Is your customer ok with Silverlight requirement on every pc of the network? This means, application will not work if the user has not installed Silverlight.

2. If your customer wants an extra-ordinary user experience; which includes rich interactive media, games, simulation, etc.

3. jQuery may be easier to get along if you already know Javascript, but Silverlight would require a learning curve, atleast of 4 weeks to "really" get along.

Here is an interesting answer posted; and if you’re a jQuery fan this will soothe your veins.

Enjoy, the silver light (0;
Read more ...
Designed By Published.. Blogger Templates