Blog Home  Sign In RSS 2.0 Atom 1.0 CDF  

  def Softwaremaker() :
         return "William Tay", "<Challenging Conventions />"

  knownType_Serialize, about = Softwaremaker()
 

 Saturday, October 13, 2007

I know I havent been posting deep technical stuff that I used to do. Contrary to what people think my current role entails, keeping abreast of the technology landscape is what I am supposed to do and what I enjoy and so when colleagues joked with me when was the last time I booted up Visual Studio, for example, I enjoyed seeing their shocked faces when I told them: "oh - just last night. why you asked ?" .

I dont dwell deep like I used to but I still code up decent projects which I implement within my own developmental testing environment (yes, I have one running latest versions of Active Directory, SharePoint, Exchange and all the other goodies), driving the houshold crazy when I think of new and different ways to document expenses, publish a Book or CD library, home automation projects using all sorts of different technologies (yes, that includes Ruby-on-Rails) or in my new Windows Mobile 6 Device. Of course, I admit I dont post topics deep like I used to. It is not so much the content but more so, the limiting factor of time.

Recently, I was involved in some internal technical discussions with regards to the issue of scale comparisions between Windows Communication Foundation (WCF, previously - Indigo) and ASMX. Below are some discussions:

If you have a web service that is going to be IO bound, you would definitely want it to be scalable and almost every resource in the world tells you to implement ASP.NET asynchronous pattern (BeginSomething/EndSomething, etc) on it so to go easy on the thread pool. ASP.NET uses an IAsyncHttpHandler to handle the request, which means the worker threads are not blocked while the IO-bound operation executes somewhere else. Sounds good so far.

If you make a WCF version of it with webHttpBinding (which actually means you can invoked it AJAX-style) following the same async pattern for the methods, you may find that each invocation of the WCF service eats up two threads – one for its ASP.NET HttpModule.ProcessRequest and the other for the actual IO. Ouch! You may think that this means your WCF implementation may end up eating all threads reserved for ASP.NET, which would indeed scale down the server

Is this true OR are we missing the complete picture ?

While the scenarios explained above are reasonable observations, it doesnt paint the complete picture. WCF does perform better scalability than ASMX.

  • Threading:
    For ASMX, when a request comes in, it would be queued up immediately for async ASMX. So the thread is released for that request and a new thread will pick up the work item later.

For WCF, when a request comes in, we queue it up in WCF and let an IO thread handle the request. At the same time, the request thread-pool thread is held to wait for the request to complete.

Yes, WCF uses more threads than async ASMX. But there is a reason for this. Using asynchronous ASMX is dangerous and not really a good practice (and I have hinted at this many times in the many Web Service/ASMX presentations I have done over the past few years). While it does well at what it is supposed to do, it does trick the developer into a "false sense of security". Essentially, if you dont know how the ASP.NET blackbox works, you may find yourself thrown against the car wall when you take a hidden, unsuspecting corner at high speeds. It does not provide enough throttling for client loads. Basically the server takes all items and queue them up for later processing. The server does not have a good throttling mechanism to control the number of work items. To everyone else, it seems that the server is quite friendly to all clients. However, if the number of clients is unbounded, this is really bad. First of all, the server working set would grow unlimited due to unlimited requests queued up. Secondly, many client requests would become obsolete when it’s picked up by the server from the queue. The latter accounts for a a good set of problematic scenarios I have come across in my past consulting gigs with regards to high-load and high-transactional ASMX asynchronous implementations before I joined the borg.

Think of it as a side of the brain (that tells you that you are about to be full) not functioning properly when you sit down at a buffet table. You eat and eat and eat without knowning when to stop and then your ingestion/digestion system starts kicking in, you actually hit the wall. Hard. Literally.

  • Server Throughput
    When you measure scalability, the most important measurement is the server throughput. That is, how many requests the server can handle per time unit? For async ASMX, it would be pretty fast at the initial phase. However, like the ingestion/digestion analogy I was referring to above - Once the server is in a steady phase (as when CPU is fully loaded), the throughput will go down because the server capacity has reached. You can compare the data between async ASMX and sync ASMX over the long run to see what I mean.

Also you would see higher memory usage of the async approach.

  • ASP.NET Throttling
    That said, ASP.NET does have a throttling mechanism that is used for sync ASMX, which is the threadpool thread limit. The number of threads used to handle requests are bounded (http://support.microsoft.com/kb/821268). WCF uses this fact to throttle incoming requests. You can always change the configuration settings to increase number of threads to be used to allow more work items to be queued up.

The max number of threads follows the following formula:
MaxWorkerThreads x #CPU – MinFreeThreads
This is 12 by default on a single-proc machine.

  • Two-level Throttling for WCF
    WCF leverages the ASP.NET threadpool throttling to throttle client requests. At the same time, WCF has its own item queue throttling. The former is throttled by the setting mentioned in the immediate above point, while the latter is controlled by WCF throttling settings (maxConcurrentCalls etc). ASP.NET can automatically adjust threads based on CPU loads so that you would always get full load of the server.

In this way, you may experience client failures because the requests are rejected at ASP.NET layer beforehand. So you can increase the ASP.NET throttling to get better experience. But eventually you would still be bounded by the physical server capacity, no matter whether you use async ASMX, sync ASMX, or WCF as mentioned above.

There is improvement work done in .NET 3.0 SP1 and of course, .NET 3.5 (beta 2 here), with the use of prioritized item queues. Do expect even-better WCF performance even in some of the common scenarios. Fine tuning minWorkerThreads will even give us even better results.

Thanks to Wenlong for helping out with the guidance and explanation. The complete scenario and the design principles for it will be published in greater detail in a MSDN whitepaper later. Do watch out for it.

Friday, October 12, 2007 10:40:28 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, January 18, 2006

    Two of my favourite features out of many in Visual Studio 2005.

    1) Finally - A Correction of what was wrong for some time - There is a Add Service Reference now. This is essentially what svcutil.exe does for you. Awesome. Now we know we are speaking services and messages ... No more calls please.

    2) A simple IDE enhancement but yet one that can generate lots of productivity. VS.NET will launch any project (of a solution) that my cursor is residing on. No more booting up of Class Libraries or Service Components by mistake anymore, (esp. in-front of an audience)

    Wednesday, January 18, 2006 3:08:43 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Thursday, July 28, 2005

    The WinFX Runtime Components Beta 1 is available here, and the WinFX SDK is available here.  Also, check out the new Windows Vista Developer Center at http://msdn.microsoft.com/windowsvista.

    With this release comes with the official names for many of the technologies that they've been talking with our developers about for several years. In particular, Windows Longhorn is now Windows Vista, Avalon is now the Windows Presentation Foundation, and Indigo is the Windows Communication Foundation.

     “Former” code name

    Official name

    Longhorn

    Vista

    Avalon

    Windows Presentation Foundation

    Indigo

    Windows Communication Foundation

    Metro

    XML Paper Specification (XPS)

    Least-privileged User Access

    User Account Protection

    WAP

    WinFX Runtime Components

    Thursday, July 28, 2005 3:23:37 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, July 27, 2005

    Please take a look at the new MSDN site serving as the single content point for current ASP.NET customers to easily make the move to ASP.NET 2.0.

    Upgrade Center: http://msdn.microsoft.com/asp.net/migration/upgrade/default.aspx

    Also, check out the new whitepaper that details the lessons learned, best practices, and valuable techniques that will help developers upgrade their apps.

    New Upgrade Paper: http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/upgradingaspnet.asp

    For general migration (ASP, competitive, etc.) content, you can always refer to the migration center at: http://msdn.microsoft.com/asp.net/migration/

    Tuesday, July 26, 2005 11:58:21 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, July 26, 2005

    The much anticipated download of a fully installed & configured Visual Studio 2005 Team System Beta 2 VPC is now available for download to MSDN Universal Subscribers. This is the same VPC that was distributed at TechEd USA and TechEd EMEA and represents a clean install of Windows Server 2003 w/ Visual Studio 2005 Team System Beta 2.

    VPC Contents:

    • Microsoft Windows Server 2003 Standard Edition
    • Microsoft Visual Studio 2005 Team Suite Beta 2 (expires May 1, 2006)
    • Microsoft Visual Studio 2005 Team Foundation Server Beta 2
    • Microsoft .NET Framework 2.0 Redistributable Package Beta 2
    • Microsoft SQL Server 2005 Community Technology Preview
    • Microsoft Office 2003 Standard Edition
    • Microsoft Live Communication Server 2003

    This VPC does not contain any sample projects or sample data.

    Minimum System Requirements:

    • PC with 2.0 gigahertz or faster processor
    • 1.5 GB RAM minimum
    • 10 GB available hard disk space
    • Super VGA (800 x 600) or higher video
    • DVD-ROM drive
    • Microsoft Virtual PC 2004 SP1 software

    If you have some trouble locating this developer-Godsend --- I have done some snopping already and it is here:

    Developer Tools > Visual Studio 2005 > Visual Studio 2005 Beta 2 > English > Visual Studio 2005 Team System Beta 2 VPC

     

    Tuesday, July 26, 2005 12:35:16 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, June 11, 2005

    I have recently flashed some performance graphs between Java 1.5 and the .NET counterparts version 1.1 and 2.0 Beta2. This is where I got the statistics from.

    You will see the outright disparity in performance gains when .NET 2.0 Beta2 is put through the same tests with its poorer 1.1 brother and its distant cousin Java 1.5.

    ...And we are still talking about .NET 2.0 BETA 2 ... Let us see what happens when we get to November 7 2005

     

    Saturday, June 11, 2005 4:05:18 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, January 28, 2005

    This has been floating around for some time BUT MSFT Corp has released an official statement here

    Since XQuery is expected to reach W3C recommendation only in 2006, it won't be shipped in the upcoming .NET Framework 2.0

    I guess people like me will have to live with XSLT and XPATH for now.

    Friday, January 28, 2005 12:02:47 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, November 30, 2004

    While doing some deep plumbing work, I discovered that Lutz Roeder's ultimate awesome Reflector() tool is already throwing up some wonderful Whidbey VB.NET keywords. AND I dont even have .NET 2.0 installed on that machine yet. Cool

    One of the keywords used is TryCast. TryCast is a new VB.NET Keyword in VS2005 which essentially combines 2 type checks into 1. For example

    Instead of


    If TypeOf o Is XMLElement Then 'One TypeCheck
    XMLElementObj = DirectCast(o, XMLElement)...' Another Type Check

    Do this


    Dim XMLElementObj As XMLElement = TryCast(o, XMLElement)

    Of course, performance is the differentiating issue here. TryCast, as its name suggests, will try the cast and, if it succeeds, return the value cast to that type, else, it returns nothing.

    Think of it as VB.NET's answer to C# “As” keyword. Here is also a good blog about it.

    Tuesday, November 30, 2004 12:06:03 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Monday, November 22, 2004
    Making sense of the new Event-Based Asynchronous Programming Model in ASMX .NET v2.0
    Monday, November 22, 2004 12:39:15 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • Http.sys is a kernel-mode networking component of Windows and is baked into the base OS of Windows Server 2003 and now, Windows XP SP2. See here for more information.

    According to Don Box here, the thinking is that it's better to have one hardened implementation in the base OS than 4-5 one-off implementations in different products/technologies. Old-timers may recall that early builds of the .NET Framework installed HTTP.SYS in order to get .NET Remoting to work with HTTP (I think it was called the COM+ web server). The fact that we had to ship a one-off HTTP server implementation in .NET Remoting was an unfortunate byproduct of HTTP.SYS not having a ship vehicle that was close to .NET V1. Hopefully making HTTP.SYS part of the base OS will keep others from going down the same path.

    VS2005 now comes with a Managed Framework for Http.sys (HttpListener). Even though it was possible to host ASPX and ASMX in any managed process (WinForms, ConsoleApps, WindowsServices...) since .NET v1.0, the HttpListener class that comes with VS2005 makes it a lot easier.

    ASP.NET Cassini Web Server is an example of a Windows Application hosting ASP.NET and is used throughout ASP.NET v2.0. It can run on your desktop without the use of IIS.

    I will show some very simplistic examples of the how-tos in hosting HTTP Processes in a Console Application using a Console Application in .NET 2.0. In this case, I have built a simple IIS-less Web Server that can churn out Web Pages, SOAP and even SOAP that is WS-* Compliant using Web Services Enhancements (WSE) 2.0 !!!

    You can find information related to the above from my previous blog post here. Do take note that the codes show there are for test and demo purposes only. There needs to be major re-work and re-factoring before it can even be considered usable.

    On another node, Aaron Skonnard has just published an article here that gives a detailed explanation on the above. Do check it out.

    Monday, November 22, 2004 12:22:05 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, October 29, 2004
    Friday, October 29, 2004 3:11:22 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions