Question

I have an application that takes a bunch of data and processes it in a series of cycles that are very time consuming. The finished result should be accessible via an HTTP API. I decided to create a core library that does the processing, and an ASP.NET application that starts the processes on new threads. The core library spawns 4 threads which process objects from queues.

However, this turns out to be significantly slower than just running the processing in a simple console application. In my console application, the processing takes about 13-20 seconds per loop, averaging at about 17 seconds, in my ASP.NET application, the processing takes 13-350 (yes three hundred and fifty) seconds, averaging at about 45 seconds. The times for each loop varies wildly in my ASP.NET application.

Is there any obvious performance hit using the ASP.NET framework that I have missed? I have disabled recycling and there are few requests being served while processing, if any. Does this have something to do with threading or garbage collection? I’m suspecting the latter since most loops run fast enough, while some are extremely slow which destroys my total processing time.

Should I move away from ASP.NET and try to implement an HTTP-listener in my Console app instead, or remodel it into a windows service? Any ideas?

Answer 1

An ASP.NET application will obviously always perform slower than Console app.

Reasons:

1. Overhead of HTTP Protocol.

2. Large memory usage by ASP.NET Framework DLL’s

3. Limited threads controlled by ASP.NET itself.

You can build up using a WCF service which will be called by your application.