我遇到的最大瓶颈是处理请求所需的时间。
处理请求的速度越快,可以处理的连接就越多。
由于每个应用程序都不同,这是一个很难回答的问题。
为了解决我支持的应用程序的问题,我创建了一个生成许多线程的单元测试,并在 eclipse 中观察 VisualVM 中的内存使用情况。
您可以看到您的内存消耗如何随着正在使用的线程数而变化。
您应该能够获得线程转储并查看线程正在使用多少内存。
您可以推断出一个平均值,以了解 N 个用户可能需要多少 RAM。
瓶颈将是一个移动的目标,因为您将优化一个区域直到您可以扩大规模,然后另一个区域将成为您的瓶颈。
如果 servlet 的响应时间是瓶颈,您可以使用一些排队数学来确定可以根据平均响应时间优化排队的请求数。
http://www4.ncsu.edu/~hp/SSME_QueueingTheory.pdf
希望这会有所帮助。
已更新以解决您的其他问题:
我的 Tomcat 服务器可以同时处理 6000 个 HTTP 连接吗?为什么不(文件句柄?每个请求的 CPU 时间?)?
这是可能的,但可能不是。此外,如果您打算做大量工作,您可能应该在应用程序服务器前面添加一个 Web 层。
假设您有 6000 个用户都在使用您的应用程序。用户发送的每个请求仅在服务器上存在片刻 [希望如此],并且您的峰值线程数可能永远不会超过 20。
我建议设置一些监控以了解您的应用程序在实际用例中的执行情况。查看http://Hawt.io,它使用 Jolokia 通过 http 获取 JMX 指标。
如果您对分析很认真,我建议您使用 Graphite 之类的东西来汇总您的 JMX 指标。 https://github.com/graphite-project/graphite-web
我已经为 Jolokia 编写了一个收集器,用于将指标发送到 Carbon/Graphite,并且可以在我的管理层批准的情况下将其开源。如果您有兴趣,请告诉我。
我可以将线程池大小设为 5000(空闲线程会消耗 CPU/RAM)吗?
空闲线程不必担心,尽管将线程池设置得太高可能会让应用服务器接收到过多的请求。如果发生这种情况,您最终可能会用无法处理的连接淹没您的数据库,或者您的内存分配可能不足以处理如此多的请求。这可能会导致整体应用程序性能下降。
设置得太低,您的应用服务器可能会再次开始排队请求,从而导致性能下降。
在高峰期或高容量时间通常会有一些排队,但您不希望应用程序服务器超载。查看排队理论以了解更多信息。
此外,这也是在应用程序服务器前面有一个 Web 服务器可以为您提供帮助的地方。如果您让 Apache 为您的静态内容提供服务,那么在大多数情况下,只有动态请求会到达应用程序服务器。
调优对您的个人应用程序非常具体。我建议保留默认值并优化您的代码,直到您可以收集足够的数据来知道应该转动哪个旋钮。
我可以将 oracle 连接池大小设置为 500 个连接(空闲连接是否会消耗 CPU/RAM)?
与应用程序线程池大小相同的情况。尽管您的数据库池大小应该比应用程序线程数小得多。
500 对于大多数 Web 应用程序来说太高了,除非您的容量非常大,在这种情况下,您可能需要像 Oracle RAC 这样的数据库集群环境。
如果池设置得太高并且您开始使用大量连接,则您的数据库硬件将无法跟上,最终您将在数据库服务器上遇到性能问题。
查询返回所需的时间可能会增加,进而导致您的应用程序响应时间增加。 “原木堵塞”效应。
使用分析或指标来确定正常使用下活动数据库连接的平均数量,并将其用作确定允许的最大值的基线。
每个连接产生的垃圾量有影响吗?例如,如果 Tomcat 为每个 HTTP 连接创建并留下 20KB 的对象。那么到处理 2500 个请求时,将使用 100MB 堆,这可能会触发 300 毫秒的 GC 暂停。
数字会有所不同,但可以。还记得Full GC比较受关注。增量 GC 不会暂停您的应用程序。查看“并发标记和清除”和“垃圾优先”。
我们可以这样说吗:如果 Tomcat 使用 0.2 秒的 CPU 时间来处理单个 HTTP 请求,那么它将能够在一秒钟内处理大约 500 个 http 连接。因此,6000 个连接需要 5 秒。
这并不是那么容易,因为每个请求都进来了,还有一些正在处理和完成。查看排队理论以更好地理解这一点。
http://www4.ncsu.edu/~hp/SSME_QueueingTheory.pdf