Any of you who have been writing WCF front-ends for BizTalk services will know about one of ASP.NET’s failings: first request latency. A service (or application) hosted in IIS doesn’t start-up and JIT itself fully until the first request is received.
And if low-latency is important to you, this isn’t acceptable, as the first request can incur delays ranging anywhere from 2 secs to 60 secs!
There are many common ways to decrease the impact of this:
Changing the application pool worker process idle time-out and recycling interval
Setting specific time when the application pool can recycle
Writing a separate service that "pings" the service to start it up
Using MOM’s ability to "ping" services to start a service
None of the above options is bullet-proof – all they can do is reduce the chances of a request hitting this problem.
But now we have IIS 7.5 and the Web Application auto-start functionality – which allows applications to automatically start and be compiled when their application pool is started/recycled: all before the first request is received.
And AppFabric builds on this: AppFabric extends this functionality to individual WCF services hosted in an application.
So we can now configure a WCF service to auto-start when the app pool is started/recycled – meaning that the first request to the service will have the same latency as any of the other subsequent requests.
The downside is that this only works with IIS 7.5 – meaning Windows 7 or Windows Server 2008 R2.
More info can be found here:
Info on configuring auto-start can be found here: