在tomcat中使用ThreadPool Excutor服务来加速请求
我有一个 tomcat6 servlet 应用程序。我的一个请求（平均约 10 秒）可以通过使用多线程得到显着改善，因为它是一项仅包含 CPU 的任务，而且我有 >= 8 个核心。我只是想知道这样做是否明智，或者只是表面上的改变：
对于单一用户案例来说，这当然是一种改进。但如果负载增加会发生什么？我的 CPU 能力是有限的，目前在多个 HTTP 连接器线程之间共享。假设我已经对它们进行了最佳配置，我将不得不从 http 连接器线程池中取出一些线程并将其放入某个执行器服务器中，以加快这个单一（但重要）操作的速度。
我的假设是，随着负载的增加，如果我使用额外的线程执行器服务，我的系统性能会更差。
你看到我的问题了吗？有人有一些最佳实践的想法吗？还是我忽略了什么？
I have a tomcat6 servlet application. One of my requests (~10 seconds avg.) can significantly be improved by using multi threading because it is an CPU-only task and I have >= 8 cores. I just wonder if it is clever to do so or just a cosmetic change:
For the single user case it is an improvement, of course. But what happens if the load increases? I have a finite amount of CPU power which is shared among several HTTP connector threads at the moment. Assuming I had configured them optimally, I would have to take some threads our of the http connector thread pool and put it into some executor server in order to speed up this single (but important) operation.
My assumption is, that with increasing load, my system will perform worse if I use an additional threaded executor service.
Do you see my problem? Does anyone have some best-practise ideas? Or something I overlooked?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于性能问题，除了少数例外，最好的答案通常是制定基准测试并尝试一下。
请记住，某些任务无法并行化。也就是说，尝试这样做要么需要同步，从而无法获得任何好处，要么根本不可能，因为每个步骤都需要完成前一个步骤。如果您的任务无法并行化，那么就没有任何好处。
出于同样的原因，并非所有应用程序的活动都必须并行运行。在某种程度上，您的应用程序的各个部分将相互阻塞文件系统或网络的 I/O，甚至可能在数据库内等待请求。所有这些意味着，仅仅因为您的硬件可能只有 8 个核心（例如），并不意味着您应该严格限制自己为 8 或 9 个线程。当然，你也不想疯狂地拥有数百个。
In cases of performance questions, with few exceptions, the best answer is usually to formulate a benchmarking test and just try it.
Keep in mind that some tasks can't be parallelized. That is, attempting to do so either requires synchronization such that no benefit is gained or is simply not possible at all as each step requires the previous to be completed. If your task can not be parallelized then there will be no benefit.
On that same token, not all of your application's activities may necessarily run in parallel. To some extent portions of your application will block each other for I/O either to the file system or to the network, and even possibly to an extent within your database waiting for requests. All of which means that just because your hardware may only have say 8 core (for example) doesn't mean you should strictly limit yourself to 8 or 9 Threads. Of course, you don't want to go crazy and have hundreds either.
据我了解这个问题，您希望创建一些额外的线程，如果您有 1 个并发请求，并且您将工作（大约需要 10 秒）拆分为几个较小的工作单元（可以并行化并稍后加入），这将受益匪浅。
您担心这实际上会降低性能，例如，如果您有 100 个并发请求，因为您没有备用核心来并行化这 100 个作业中的每一个作业。
理论上，当活动线程数等于物理核心数时，开销最小。因此，您需要问自己一个问题 - 最常见的情况是什么（系统有多少用户？）以及如果用户数量达到峰值，您准备支付什么价格。
不管怎样，我完全同意蒂姆的观点，你应该进行基准测试，从理论上判断这一点实际上是不可能的。例如，如果您的 10 秒任务是 100% CPU 密集型 VS 80% CPU 密集型，则结果可能完全不同。 测量，不要猜测。
As I understand the problem, you want to create few extra threads which will benefit if, say, you have 1 concurrent request and you split your work (which takes ~10 seconds) into few smaller work units which can be parallelized and later joined.
And you are worried this can actually degrade the performance if, for example, you have 100 concurrent requests as you don't have spare cores to parallelize each of these 100 jobs.
Theoretically the smallest overhead is when the number of active threads is equal to number of physical cores. So you need to ask yourself a question - what is your most common case (how many users does the system have?) and what price are you ready to pay if number of users peak.
Anyway, I completely agree with Tim that you should benchmark, to judge this theoretically is virtually impossible. For example, your results can be totally different if your 10 second task is 100% CPU-bound VS 80% CPU-bound. Measure, don't guess.