我正在维护一个几乎没有作为SOAP Web服务公开的服务的应用程序。由于应用程序承受的负载比正常情况多，我在后期遇到了一些扩展问题。
我想知道我对少数几种池配置的理解是否正确：1.我们具有以下线程池配置，
<thread-pools>
<thread-pool name="admin-thread-pool" max-thread-pool-size="50" max-queue-size="1024"></thread-pool>
<thread-pool name="http-thread-pool" max-thread-pool-size="250"></thread-pool>
<thread-pool name="http-thread-pool-internal" max-thread-pool-size="50"></thread-pool>
<thread-pool name="thread-pool-1" max-thread-pool-size="200"></thread-pool>
</thread-pools>
和
<transports>
<transport name="tcp" acceptor-threads="8"></transport>
</transports>
和2. EJB池配置如下，
<ejb-container steady-pool-size="0" max-pool-size="50" pool-resize-quantity="10">
所以现在的问题。
如果http线程池收到需要同步执行的任务，并且池中没有足够的EJB bean实例（最大配置为50个），因为所有EJB实例都在处理其他http请求，将会发生什么情况？注意：我们正在执行JNDI查找，而不使用@EJB批注。
增加等于http-threadpool值的EJB实例数（最大值）是否有意义？
在进行了一些概要分析之后，发现对EJB实例进行查找的代码需要很长时间才能返回。这是否意味着没有可用的EJB实例，并且该请求必须等到其他正在运行的线程释放实例为止？
如果http线程池收到需要同步执行的任务，并且池中没有足够的EJB bean实例（最大配置为50个），因为所有EJB实例都在处理其他http请求，将会发生什么情况？
EJB池不是JEE规范的一部分，因此，池行为取决于供应商。根据Glassfish文档（可能会因版本而异），如果池大小小于steady-pool-size，则在新请求到达时，Container将创建X个新ejb实例，其中X由pool-resize-quantity值确定。因此，您不应该用完池中的ejb。该max-pool-size不是一个固定的限制。
增加等于http-threadpool值的EJB实例数（最大值）是否有意义？
可能是正确的，但是请注意，如果在高负载期间需要更多ejb，则Container将自动增加池大小。我会将其更改为steady-pool-size大于0的值。
在进行了一些概要分析之后，发现对EJB实例进行查找的代码需要很长时间才能返回。这是否意味着没有可用的EJB实例，并且该请求必须等到其他正在运行的线程释放实例为止？
万一（可能是配置错误的池）服务器用完了可用的ejb，它具有更大的意义，即它会创建一个新实例，而不是序列化客户端请求。这是规范（ejb 3.1）所说的：
4.7无状态会话Bean ...如果需要一个无状态会话Bean实例来处理客户端工作负载的增加，则该容器将创建一个...
除非您的bean必须在初始化时执行特定的业务逻辑（例如@PostConstruct注释方法中的逻辑），否则创建一个新的ejb实例应该不会太昂贵。
请记住，在高负载下，还有其他比池配置更重要的相关问题需要监控，例如cpu和内存服务器使用率。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句