While difficult to quantify, I'm experiencing a difference in behavior depending on whether the long-running initialization code is placed in the ASP.NET Application_Start or Application_BeginRequest global event handlers. With the startup code in Application_BeginRequest, the cold-start splash page, or previously cached page in a recycle case, is returned only for requests that are made very quickly after the recycle/restart. After the first second or two, the next request will 'hang' for a longer period presumably waiting for the startup code to finish. Performing the same test with the startup code registered in Application_Start yields the behavior I would expect in that the splash/cached page is returned immediately for a longer period of time until a new version is returned without any noticeable 'hang'.
Is the Application Initialization module intended to wait for the "fake" request to transition through the full ASP.NET request lifecycle before notifying WAS that the new worker process is ready? This is the impression I got from Wade's blog post:
"In the case of a replacement process, though, Application Initialization will prevent the new process from reporting itself ready for new requests, until all of the preload requests (and any warumup requests, which I will discuss later) have completed. This means that no client will ever have to wait for a process recycle to complete - because the old process will continue to take requests until the new one has completed all application initialization."
Are there ways to observe or debug the operation of the app init module so that I can try to correlate when the module signals WAS that the worker process is ready to the execution of our startup code?
Thanks,
Aaron
↧