I have this site that takes a very long time (~5-10min) to get going after startup. It does some questionable setup stuff on the first request and those things aren’t necessarily thread safe…
I’m thinking this site would have a smoother startup if I could make sure the first request finishes before it takes on subsequent requests. It’s just this one IIS, no load balancer to pull it from and the server doesn’t have enough memory to handle two instances at the same time. I can’t use IIS IP restrictions because it would recycle the app pool.
Anyone know a good trick I haven’t thought of?
Thanks for getting in touch! Typically in ASP.NET applications (I’m assuming you are using), when the first request hits the site, it waits in a queue until the startup code is complete. Further requests also wait in the queue. So the bits that run in ASP.NET startup are thread safe, as are any static constructors. However if you have one-time code that runs after the first request starts processing (ie in a controller, filter, etc, that may be a problem). I recommend putting a lock or mutex around that.
Most changes in IIS will recycle the app pool. The only thing I can think of is to setup a IIS ARR (https://blogs.technet.microsoft.com/exchange/2013/10/16/part-4-iis-arr-as-a-reverse-proxy-and-load-balancing-solution-for-o365-exchange-online-in-a-hybrid-configuration/) and add/remove your server from that. Essentially you are setting up a load balancer (or reverse proxy) with one machine. You do not need another machine or IIS instance to do this.
Hope that helps!
Yes, the troublesome code is run after startup from controllers etc. It’s a very large codebase, so it will take quite some time to understand it and refactor, which is why I was looking for the lazy way out.
Reverse proxying with ARR is a smart idea. I can just stop the proxy site during deployment (there’s even a library step for it!) and do my warmup request directly. Thanks!