I’ve mentioned before that IIS 8.5 has an issue with spamming healthchecks because it’s web farms aren’t directly associated with application pools. Instead, every running application pool believes it needs to monitor the health of all the web farms, which causes redundant healthcheck calls.
I’m also a proponent of using Healthchecks to test connectivity to databases, external web APIs, and core functionality: Healthchecks Should Not Be Pings.
Because I prefer that healthchecks check that the database is available, and that domain account can log into the database, the healthcheck spam can have a very minimal effect on database performance and connection thresholds. It’s never really been a problem that has been seen, but it’s theoretically something to be concerned about. Soo … here are two techniques that can lower the impact that the healthcheck spam can have on databases:
Cache the Healthcheck Response for a Little While
There are a number of output caching systems built into ASP.NET which can easily provide this functionality:
But! Nothing was every made for ASP.NET WebApi 2. It was really surprising that nothing was ever built in for this. Luckily, there is a great community package the provides the functionality while following the standards that Microsoft was using:
- ASP.NET WebApi 2: Strathweb.CacheOutput.WebApi2
Use Database.Exists (instead of a real call) to help prevent locking
To test if your application is going to be able to communicate with a database successfully, the easiest (and maybe best) way is to use a real call. Just use a function that is a part of the application. This not only tests connectivity, but it also checks if permissions are setup correctly. However, this can drive some concern around table locking if the storm of healthcheck calls aren’t prevented (by the caching mentioned above). Another way to prevent table locking is to use Entity Frameworks Database.Exists method.
0 comments:
Post a Comment