使用线程池线程与长时间运行的ADO.NET查询。这是可扩展性？ [英] Using ThreadPool threads with long running ADO.NET queries. Is this scalable?

问题描述

我们目前正在加强一个ASP.NET应用程序，其对一些产品的报价。

在present现有报价的发动机基本上是一个大的存储过程（每次通话2-3秒），随后是该过程调用运行后，少量的业务逻辑。

我们正在研究多线程调用每一个产品，以加快一组引号。

我们目前的做法是每个封装产品报价工作的一个线程池线程。这似乎性能要好得多，但我有点担心，虽然它与一小部分用户中表现良好，将它在生产环境中很好地扩展？

请注意，在present我们不使用异步ADO.NET方法。

请注意：我们的code调用线程池有一个节气门队列请求，因此我们只能在同一时间使用的线程可配置量的线程池。我们也不需要等待在同一页上的报价结果，我们允许用户进步和检查更新（报价结果页面使用AJAX来检查的结果）。

另外注意的是：preferred的解决办法是使用消息队列作为报价服务是单向操作。然而，时间尺度的项目并没有提供我们的时间做到这一点。

在此期间，我们将要修改的实施使用ADO.NET的异步方法（因为这是那里的所有进程的长期运行方面是）保存需要使用线程池线程。

解决方案

  

使用线程池线程长   运行ADO.NET查询。这是   可扩展的？

简短的答案是否定的，它不能扩展。

的原因是，线程池线程还用于处理常规ASP.NET请求（BeginInvoke的也是如此）。还有那些线程的数量有限，并且当他们已经​​习惯上，收到的HTTP请求将阻塞，直到一个线程变得可用。

虽然可以增加在ASP.NET线程池中的线程的数目，还有其他一些问题，如事实线程的数目不是固定的;它在响应负载增加缓慢。你可以/应该使用异步页，但仍然留下了一个如何实际运行的SP的问题。这将是好得多，如果可以的话，切换到异步ADO.NET方法的一部分。他们也轻得多重量比使用每个请求的线程。

在情况下，它可以帮助，我详细讲述这个主题在我的书（超快速ASP.NET ）

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.

解决方案

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).

这篇关于使用线程池线程与长时间运行的ADO.NET查询。这是可扩展性？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！