During recent years, I had the chance to work with many customers and I realized that one of the most recurring problems they usually experience is due to long start-up times: indeed, this is not a BizTalk specific issue, it’s rather a problem affecting any .NET application, regardless if it’s a Windows Service, a Web Application or an IIS hosted WCF service. When a BizTalk host process starts, it performs some warm-up operations like creating AppDomains, loading assemblies, reading configuration data and populating internal caches. As a consequence, the first inbound request incurs an extra time delay before being processed as it needs to wait until the warm up period has been completed. One of the most commonly used workarounds to solve this problem is creating a separate service or schedule the execution of a script that sends a dummy message to start up the process in question. By the way, this technique is a less than ideal workaround. There’s a best way to avoid long start-up periods at least for WCF services hosted by IIS 7.5 and Windows Server AppFabric. So going back to the initial question, is there any way to avoid long warm-up periods when the first message comes through a BizTalk process? The answer is yes, at least in one case. In fact, BizTalk Server 2010 can take advantage of the Start Automatically feature provided by IIS 7.5 and of the Auto-Start functionality supplied by Windows Server AppFabric to avoid long start-up periods for IIS-hosted WCF Receive Locations. As you already probably know, the latter now supports the .NET Framework 4.0. Now let’s assume that a BizTalk application exposes one or multiple WCF Receive Locations in the isolated host. The Application Pool running the WCF Receive Locations needs be configured to use the .NET Framework 4.0 and the Integrated managed pipeline mode. Therefore, if BizTalk Server 2010 is installed on Windows 7 or Windows Server 2008 R2 with Windows Server AppFabric, you can exploit the Auto-Start Feature provided by this latter to automatically start WCF Receive Locations when the Application Pool worker process starts.
The auto-start feature of AppFabric is built on top of the auto-start feature of Internet Information Services (IIS) 7.5, which is included in Windows 7 and Windows Server 2008 R2. In IIS, you can configure an application pool and all or some of its applications to automatically start when the IIS service starts. The AppFabric auto-start feature extends this functionality so that you can configure all or some of the services within an application to automatically start when the application starts.
When you enable the auto-start feature for a WCF service running on Windows AppFabric, this latter is up and running as soon as the application that it belongs to is started and before the service receives the first message from a client application. Therefore, the WCF service processes the first message quickly because it is already initialized. Now, the WCF Receive Location is just a WCF service, therefore it can get advantage of the Auto-Start Feature as any other WCF service running in the Windows Server AppFabric environment.
For more information on this topic, see the following articles:
In order to enable the auto-start for a WCF Receive Location exposed by a BizTalk Server 2010 application running on Windows 7 or Windows Server 2008 R2, you can proceed as follows:
If you are a BizTalk developer, you probably use the DebugView to monitor the trace produced by your application components. Let’s use this invaluable tool to make a simple test. If you recycle the Application Pool running the BizTalk isolated host and then you send a message to an IIS-hosted WCF Receive Location, the WCF Adapter runtime generates the following trace on the standard output:
Now, let’s assume that your application exposes an orchestration via a WCF-BasicHttp, or WCF-WSHttp or WCF-CustomIsolated Receive Location hosted by the BizTalk isolated host. If you restart the Application Pool running the WCF Receive Location, you won’t be able to see the trace above in the DebugView until you submit the first message. This means that the WCF Receive Location is initialized only upon arrival of the first message. Now, proceed as explained in the previous section and enable the Auto-Start on the application hosting the WCF Receive Location, as highlighted below.
At this point, open the DebugView and try to recycle the Application Pool running the WCF Receive Location. This time you will immediately notice the trace produced by the WCF Adapter runtime components, and this is a clear sign that your WCF Receive Location has been initialized as soon as when the worker processed has started. As a consequence, when you submit the first message, you won’t have to wait for the WCF Adapter runtime to warm-up. Indeed part of the host instance initialization takes place when the first message comes in, but the start-up period has noticeable decreased.
The Auto-Start feature is just an example of how BizTalk and Windows Server AppFabric can be used in the context of an application to address and solve real-time problems as long warm-up periods. In the coming posts I’ll explain how BizTalk and AppFabric can be tightly integrated to improve the quality, functionality and flexibility of your application platform.