Home/ Questions/Q 463969
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T23:13:41+00:00

We are currently enhancing an ASP.NET app that performs quotes on a number of

  • 0

We are currently enhancing an ASP.NET app that performs quotes on a number of products.

At present the existing quote engine is basically a big stored procedure (2-3 secs per call) followed by a small amount of business logic that runs after the procedure call.

We are looking into multi-threading the call to each product in order to speed up a set of quotes.

Our current approach is to encapsulate each product quote work in a ThreadPool thread. This seems to perform much better, but I’m a little concerned that though it’s performing well with a small number of users, will it scale well in a production environment?

Please note at present we are not using async ADO.NET methods.

Note: Our code that calls the ThreadPool has a throttle that queues requests so we can only use a configurable amount of threads from the ThreadPool at one time. We also don’t need to wait for the quote results on the same page, we allow the user to progress and check for updates (a quote results page uses AJAX to check for results).

Further note: The preferred solution would be to use a message queue as the quote service is a one-way operation. However, the timescales for the project didn’t provide us time to do this.

In the meantime we are going to revise the implementation to use the async methods of ADO.NET (as that is where all the long running aspect of the process is) saving the need to use ThreadPool threads.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Using ThreadPool threads with long
    running ADO.NET queries. Is this
    scalable?

    The short answer is no, it’s not scalable.

    The reason is that ThreadPool threads are also used to process regular ASP.NET requests (the same is true for BeginInvoke). There are a limited number of those threads, and when they’re used up, incoming HTTP requests will block until a thread becomes available.

    Although you can increase the number of threads in the ASP.NET thread pool, there are other issues, such as the fact that the number of threads isn’t fixed; it increases slowly in response to load. You can/should use async Pages, but that still leaves open the question of how you actually run your SP. It would be much better to switch to async ADO.NET methods for that part, if you can. They are also much lighter-weight than using a thread per request.

    In case it helps, I cover this subject in detail in my book (Ultra-Fast ASP.NET).

    • 0