一种正规的性能调优方法──基于等待的调优 - 编程入门网

池必须足够大使得访问的请求无需不必要的等待一个线程。

池不能大到耗尽服务器。过多的线程会迫使服务器花费大量时间用于在不同的 线程上下文中切换，真正处理请求的时间反而更少了。这种情况通常表现为CPU使 用率很高，但是处理请求的吞吐量却降低了。

池的大小不能透支与之交互的后台资源。例如，如果数据库对于单个服务器只 支持50个请求，那么服务器不应该向数据库发送超过50个数量的请求。

服务器线程池的最佳尺寸的标准是：对受限制的依赖资源产生足够的负载—最 大化它们的使用率而不让其透支。下面的“后退调优”一节有更多调整受限制资 源池大小的内容。

基于技术的等待点

基于层次的等待点考虑的是在不同服务器之间传递请求，而基于技术的等待点 关注的则是在单个服务器中如何通过有效地内部工作来传递请求。基于层次的调 优，类似于IBM的队列调优，只是调整应用的有效第一步，如果忽略了调优应用服 务器的内部工作，则会对应用性能产生巨大的影响。这就类似于调整JDBC连接池 以发送最佳数量的负载给数据库，但是忽略了检查执行的SQL语句——如果查询需 要连接十个表单，每个表单有一百万个记录，则最佳负载可能是两个连接，但是 如果我们优化了查询，则数据库可能支持二百个连接。深入研究应用服务器和应 用使用的潜在技术，可能存在以下通用的基于技术的等待点：

池对象（比如无状态session bean或者其他应用放入池的业务对象）

缓存设施

持久化存储或外部依赖池

通讯基础设施

垃圾收集

大多数情况下，无状态session bean池的大小被应用服务器优化，不会是一个 明显的等待点，除非池大小被手工错误的配置了。但是也存在一些池对象必须手 动配置大小——这些可能成为有效的等待点。当一个应用需要一个池化的资源， 它必须从池里获取一个资源实例，使用它，然后释放给池。如果池太小，所有的 对象实例都在被使用，则请求不得不等待一个实例可用。显而易见，等待一个池 化的资源会增加响应时间，如果越来越多的请求被堵塞在等待池化资源，会导致 明显的性能下降。另一方面，如果池很大，它可能消耗过多内存，对总体JVM的性 能产生差的影响。池的最佳大小需要权衡，只能在对池的利用情况做彻底的分析 才能决定。

池化对象是无状态的，这意味着应用从池中得到哪个实例都无所谓——任何实 例都行。另一方面，缓存的对象都是有状态的，也就是说当应用从缓存中请求一 个对象时，它的目标是一个特定对象。举一个很粗糙的类比说明一下区别：考虑 人们生活当中两种常见的活动：超市购物和接孩子放学。在超市中，任何收银员 都可以接待每一位顾客，无论顾客选择哪位收银员都可以顺利结账。因此收银员 可以池化。但是在接孩子放学时，每一个父母只想要他们自己的孩子，别的孩子 是不行的。因此孩子可以被缓存。

如前面所述，缓存提出了一个新的调优挑战。简单说，缓存的目的是在本地内 存中存储对象，使应用可以随时读取它们，而不是在需要的时候才获取他们。一 个合适大小的缓存可以对通过远程调用加载对象的行为提供明显的性能改善。但 是，一个不合适大小的缓存，可能产生明显的性能阻碍。因为缓存维护有状态的 对象，所以重要的一点是在缓存中存储最频繁访问的对象，同时保留额外的空间 来处理非频繁访问对象。试想如果缓存太小，请求会怎样：

请求检查缓存中是否存在某对象，结果失败。

请求需要查询外部资源获取对象数据。

因为缓存通常维护最频繁访问的数据，所以这个新对象需要添加到缓存中（它 正在被访问）。

但是如果缓存满了，必须利用“最少最近访问”算法选择一个对象移除。

如果缓存对象的状态与

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!