Tomcat线程模型
好奇地发现我的应用程序部署在tomcat上可以满足的并发请求的最大数量。
我知道：
在tomcat配置中，有一些参数可以帮助我，比如：
>
MaxConnections——服务器在任何给定时间接受和处理的最大连接数。当达到这个数字时，服务器将接受但不处理另一个连接。
我想知道的是：
>
以上参数是否足以知道我的应用程序可以处理的最大“并发”请求数？
假设最大连接数为200，那么这意味着如果有200个并发请求，将产生200个线程（每个请求1个）
那么，假设这些都是CPU密集型请求/操作。所以产生200个线程不是会降低性能吗？我认为，如果请求/操作是CPU密集型的，那么JVM产生的最大线程数应该补充内核数。（比如说16）。
共有1个答案
好奇地发现我的应用程序部署在tomcat上可以满足的并发请求的最大数量。
如果不考虑许多参数，就无法实现这一点，例如：
- 硬件马力（多少CPU，什么类型的CPU，多少内存）
换句话说：你的问题不可能有一个通用/通用的答案。如果你真的担心确切的细节，那么做实验是唯一的出路。
在功能强大的一流服务器上运行的“混合型”工作负载应该能够轻松地并行处理200个线程。但当然，如果每个请求都会导致数以百万计的IOPS，或者需要1小时的实时CPU时间，那么10个并行请求可能会让您崩溃。
-
我正在的上的上运行应用程序。对于那些不熟悉的人，每当发生SQS事件时，Amazon都会自动向我的Worker应用程序执行请求。我的应用程序然后处理请求并返回200（除非明显出错）。 我想在处理单个请求时使用并发。例如，假设我需要执行10种不同的昂贵计算。我希望使用让10个线程同时执行这项工作，而不是串行执行。 这是坏习惯吗？如果没有，以这种方式启动新线程是否存在性能危险 线程的分配实际上是如何工作
-
问题内容： 你好，我们已经在java 1.6，tomcat 6，oracle 11g上迁移了Java Web应用程序，但是现在一段时间站点关闭后我们遇到了问题：我们正在使Java堆内存不足错误并且许多线程处于等待状态。tomcat被绞死，我们的网站被压倒 信息：为地址为空且端口为80的连接器创建的最大线程数（200），2013年2月21日，这里是线程日志： 日志 结束 请指导。 谢谢阿鲁 问题答案
-
pika使用的是多线程模型，使用多个工作线程来进行读写操作，由底层blackwidow引擎来保证线程安全，线程分为12种： PikaServer：主线程 DispatchThread：监听1个端口，接收用户连接请求 WorkerThread：存在多个(用户配置)，每个线程里有若干个用户客户端的连接，负责接收用户命令，然后将命令封装成一个Task扔到ThreadPool执行，任务执行完毕之后由该线程
-
问题内容： 有人告诉我，您不应该从在Tomcat（或其他任何容器）下运行的Web应用程序启动自己的线程。 或类似地： 您应该从Tomcat知道的某个线程池中请求一个线程，而不是上述任何一个。这有什么道理吗，还是完全是poppycock？ 问题答案： 可以随意启动自己的线程，但是请记住在应用程序停止时将其停止。Tomcat有自己的thead池，用于处理传入的请求。我认为使用它不是一个好主意，即使您设
-
我有两个问题与Vertx线程模型有关。文件提到： 一个顶点。默认情况下，x实例维护N个事件循环线程（其中N默认为core*2） 对于许多现代应用程序所需的并发级别，阻塞方法无法扩展 Vertx还提供了线程池相关的功能，以处理使用服务器资源的任务，这些资源需要长时间的事件处理（工作线程）。 好的，所以我们知道线程在所需内存（例如堆栈）和上下文切换方面有开销。 Vertx线程没有被阻塞（如果正确使用）
-
Envoy使用单个进程多线程体系架构。一个主线程控制各个零散的协作任务，如一些工作线程执行监听、过滤和转发任务。一旦某个连接被一个监听器接受，这个连接将会一直运行在一个工作线程上。这使得大多数Envoy在很大程度上是单线程的（令人尴尬的并行），而在工作线程之间有少量复杂的逻辑处理。通常Envoy是100％非阻塞模式，对于大多数工作负载，我们建议将工作线程的数量配置等同于机器上硬线程的数量。