Not long ago we moved a wordpress based website from an ovh account to a windows server we already had running other things. (Nothing against OVH, just no point in having another server when we have excess already). We’ve run a number of wordpress installs on IIS and Windows, and the FastCGI implementation seems to work really well.
We started having occasional outages with the site after about a week or so, the error being “too many database connections open”. I initially thought this was being caused by an API call the site makes to a service, and that the api might be experiencing slowdowns causing the site to sit too long with open db connections and causing this issue. But eventually this was ruled out.
Mysql was showing a lot of “sleeping” connections to the database, so it looked like something was opening a lot of connections but not closing them. This is usually not an issue with Mysql and php because the connections are auto-closed at the end of each request.
BUT- when you run FastCGI on windows and IIS, part of the “fast” portion is that the service doesn’t actually end the whole process after every request- the service keeps running and waiting for the next page request to process. As a result apparently FastCGI will keep open any database connections that are now explicitly closed, until they time out some time later. So if you only have a few connections being made, your server will probably be able to keep creating them and they will expire in time for the server to not run out of resources, but in instances where it cannot keep up, your site will go down and start showing the dreaded “too many database connections” error page.
Note that the wordpress site itself doesn’t have this issue- the problem I only ran into with some custom php code that have been added onto a wordpress site. If this code were to use the correct wordpress database access methods instead of the hard coded ones, it would have operated fine as well.
Lesson- explicitly close your mysql connections in custom php code, or use the wordpress database access classes instead of your own. It might not be a problem usually, but this will cause server crashes in instances where the code is installed on Windows, IIS, and FastCGI.