1

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?

DukeOf1Cat
  • 1,087
  • 15
  • 34
  • A console app runs 32bit, your web app in 64bit. If you use a lot of resources the web app needs a lot more memory then your console app. Try to run your web app in 32bit. BTW, without some code we can only guess the problem... – Peter Aug 29 '11 at 15:29
  • @peer: If I run a console app, it runs in 64bit, and if I start a web app (in Visual Studio internal web server) it runs in 32bit... Anyhow, you have a point that it may affect performance, but compiling the console app for a specific target is a lot easier than changing IIS to 32bit. – Guffa Aug 29 '11 at 15:39

1 Answers1

3

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.

Madhur Ahuja
  • 22,211
  • 14
  • 71
  • 124
  • 2
    1 shouldn't be a problem since the calculations do not use HTTP at all, I only use HTTP to access the results after calculations are done. 2 might be true, same with the 32 vs 64-bit comment above, but if my computer does not run out of memory it shouldn't start swapping to the degree that it affects performance by hundreds of per cents? 3 I thought was not a problem if I use Thread t = new Thread() as opposed to using the Thread pool? – DukeOf1Cat Aug 31 '11 at 07:10