Is self-hosting an ASP.NET Web API application in a Windows Service reasonable? Has anyone used this in sales?

Question

IIS

There is a web application (not highload) which now works and is hosted in IIS. From IIS, only wake up on first request and restart if dropped (WAS) is used. There are thoughts of switching to selfhosting, but there are fears that world experience rejects such an approach. Who has this experience and is it positive?

Answer 1

I use exactly this approach in the production, the services work as Windows services, at startup the service chooses a free port for itself and raises the self-host webapi, through which any other service can access it. So far, it’s enough in terms of speed, but I plan to switch to my binary protocol immediately over TCP (according to tests, I can get up to 20,000 RPS, I can’t reach this on webapi).

Answer 2

There are thoughts of switching to selfhosting, but there are fears that world experience rejects such an approach

At first, we took a simple path: screwed up IIS, created an ASP.NET application with the ASP.NET Web API framework, and started sawing the business logic. It quickly became clear that this whole design does not hold more than 500-700 requests per second. No matter how we conjured IIS, nor twisted 100500 parameters, the problem was not solved. And it was quite enough that there was no way to get inside IIS, which means that we could not achieve full control over the situation. IIS is the notorious black box in which it is difficult to change something drastically.
Then we tried the Katana project server (an implementation of the OWIN infrastructure from Microsoft). Katana is an open source project, so you could see the insides. In addition, the Web API has OWIN support, which means that you won’t have to change the code much. Katana provides the ability to work with both IIS and their simple server, written based on the .NET HttpListener. That is what we took. The result pleased: now the server was holding about 2000 requests per second, and the ASP.NET application was transformed into a Windows service.
However, the load on the servers increased, new features were sawn. It became clear that this option did not suit us either. Then we took drastic measures: only the HttpListener with a small binding for asynchrony remained from all of Katana, nothing remained of the Web API, that is, the application became completely sharpened for HTTP requests for the bidder. As a result, the server became capable of processing up to 9000 requests per second. The conclusion is simple: all OWIN and Web API binding has a critical impact on high-performance applications. If you want faster, write simpler and non-universal. (This does not mean that there should be kernel shit code inside the application. Everything is modular, completely extensible: DI, patterns and all that)

source - https://habr.com/company/targetix/blog/261745/