科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道使用技巧:Java EE性能问题解决手册6

使用技巧:Java EE性能问题解决手册6

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

 这篇文章,是PRO JAVA EE 5 Performance Management and Optimization 的一个章节,作者Steven Haines分享了他在调优企业级JAVA应用时所遇到的常见问题。

来源:IT专家网 2008年5月7日

关键字: 手册 3977 Java EE java

  • 评论
  • 分享微博
  • 分享邮件
每个服务器都有一个SOCKET负责监听。程序把接受到的请求放到待执行队列中,然后将这个请求从队列移动到线程中被程序处理。

  图8显示了服务器的处理程序。

  Figure 8. 服务器处理请求的次序结构

  线程池太小

  每当我碰到有人抱怨装载速度的性能随着装载的数量的增加变的越来越糟糕的时候,我会首先检查线程池。特别是,我在看到下面这些信息的时候:

    •   1.线程池的使用
    •   2.很多请求等待处理(在队列中等待处理)

  当一个线程池被待处理的请求装满的时候,响应的时间就变的极其糟糕,因为这些在队列中等待处理的请求会消耗很多的额外时间。这个时候,CPU的利用率会非常低,因为程序服务器没有时间去指挥CPU工作。这个时候,我会按一定幅度增加调节池的大小,并在未处理请求的数量减少前一直监视程序的吞吐量,你需要一个合理甚至更好的负载量者,一个精确的负载量测试工具可以准确的帮你测试出结果。当你观测吞吐量的时候,如果你发现吞吐量降低了,你就应该把池的大小下调一个幅度,一直到找到让它保持最大吞吐量的大小为止。

图9显示了连接池太小的情况

  Figure 9. 所有的线程都被占用了,请求就只能在队列中等待

  每当我阅读性能调整手册的时候,最让我头疼的就是他们从来不告诉你特殊情况下线程池应该是多大。由于这些值非常依赖程序的行为,他们只告诉你大普通情况下正确的大小,但是他们给了你一个范围内的值,这对用户很有利的。例如考虑下面2种情况::

  •   1. 一个程序从内存中读出一个字符串,把它传给JSP页面,让JSP页面去显示
  •   2. 另一个程序从数据库中读出1000个数值,为这些不规则的数值求平均。第一个程序对请求的回应会很块,大概仅需要不足0.25秒的时间,且不怎么占据CPU。第二个程序可能需要3秒去回应,同时会占据CPU。因此,为第一个程序配置的池大小是100就有点太小了,因为程序能够同时处理200个;但为第二个程序配置的池是100,就有点太大了,因为CPU可能就能应付50个线程。

  但是,很多程序并没有在这种情况下动态的去调整的功能。多数情况下是做相同的事,但是应该为他们划分范围。因此,我建议你为一个CPU分配50到75个左右的线程。对一些程序来说,这个数量可能太少,对另一个些来说可能太多,我刚开始为每个CPU分配50到75个线程,然后根据吞吐量和CPU的性能,并做适当的调整。

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章