Is it reasonable to self-hosting ASP.NET Web API application in a Windows service? Has anyone used this in prod?

There are thought to go to selfhosting, but there are fears that the global experience rejects this approach

a moped is not mine

First we went on a simple way: screw IIS, created ASP.NET application with framework ASP.NET Web API and began to cut the business logic. It quickly became clear that the whole structure does not hold more than 500-700 requests per second. No matter how much we implored IIS or tighten 100500 settings, problem was not solved. And really get that inside IIS is not possible, and this means complete control over the situation we can't achieve. IIS — the proverbial black box, where it is difficult to radically change.

Then we tried the Katana project server (an implementation of the OWIN infrastructure from Microsoft). Katana project is open source, so you could see the insides. In addition, the Web API has support for OWIN, and so much to change your code. Katana provides the opportunity to work both with IIS and with their simple server, written in the basis .NET-ovskogo HttpListener. Is exactly what we took. The result pleased: now the server is holding about 2000 queries per second, and ASP.NET the app transformed into a Windows service.

However, the load on the server increased, pililis new features. It became clear that this option we are also not satisfied. Then we went to drastic measures: all Katanas were only HttpListener with a small harness for async Web API there was nothing left, that is, the application became fully sharpened by HTTP requests to bidder. As a result, the server became capable of handling up to 9,000 requests per second. The conclusion is simple: all OWIN and Web API binding has a critical impact on high-performance applications. Want faster write easier and is not universal. (This is not to say that inside the app should be nuclear bad code. We have everything modular, it is extensible: DI, patterns and all that)