基于tomcat的网站性能调优

  前些日子系统上线，是互联网网站，后台使用tomcat，上线前进行了性能压力测试，期间发现不少问题，通过大家的努力，解决了问题。
   我们团队以前没有这方面的经验，尤其客户提供的硬件条件非常的好，以为能够达到期望结果，后来性能测试证明是错误的。这也是开始信息化系统开发到web网站开发系统设计师常常犯的错误。
   架构： 我们的网站是apache+tomcat+DB的来实现的。其中DB使用Oracle10G，使用Oracle的全文搜索处理查询，HP小型机。
   运行环境：RED hat 企业版4.0 JDK5.0 tomcat 5

    测第一轮压力测试下来，系统只能支持300个并发，响应时间900毫秒以上。系统内存、cpu占用率很低，数据库的内存、cpu消耗很低。这肯定不是用户期望的结果，公司系统设计期望的结果。如是开始找原因。
     首先从apache接入参数（如使用work工作模式、调整最大连接数、keepalive等）、应用层tomcat的系统参数（请求处理线程数等）、数据库参数调整，发现没有任何作用，系统仍然顽固的在300个并发左右,响应时间没有多少变化。问题应该不在系统参数上。因此需要从其他角度着手。
     从现象来看，系统一定在哪个地方hang住了。如是找到sar等linux/unix系统命令查看系统资源消耗情况。发现数据库系统的IO消耗非常大，导致时间延迟非常大。DBA过来，将相关表装载并驻留内存中。系统有所改善，提高10%左右，但是并发不去。系统IO开销还是很大。DBA反馈信息是系统的查询量太大，Oracle的全文搜索也支持不了这么大请求。应用层必须要优化。
    因此建议上memcached，将搜索的结果和计算处理结果缓存起来，降低DB的压力。
   
    memcached版本上线后，系统响应时间和支持的并发书非常显著的提高，搜索达到几毫秒左右时间就可以完成，并发达到2000以上，但是继续增加请求个数，出现超时或者连接不上服务器的情况。但是应用服务器和接入服务器的开销增加，但是消耗没有到极限。但是凭借经验，我们的接入服务器和应用服务器能够支持比这个更大的处理能力。因此我们必须要找到另外的优化方案。
   
    进入linux控制台，使用ps  -ef |grep http | wc -l 一看吓一跳，apache进程有上千个，达到了apache中我们配置的参数的最大数。我们增大这个参数，apache进程就增加而增加，调整tomcat中请求处理线程数，并发能力没有明显改观。说明apache和tomcat已经达到自己处理能力的极限，要增加cpu和内存消耗通常一个办法就是再部署一套tomcat来消耗系统资源。但是这不是我们的首选，我们还有可以选择的手段。
    如是我们打开JConsole，进入tomcat的JVM，看看里面在发生什么现象。一看还是吓一跳。tomcat中有上千个请求处理线程都在跑。维护这么多线程，JVM进程是一个很吃力的事情，JVM自己管理的消耗很大，没有多余的精力处理应用。再看看有没有内存使用不当的问题导致杜塞，发现内存垃圾收集器处理正常。还有就是有没有串行处理代码，损害了java请求并行处理能力的问题存在，没有。那么问题出在哪里？
    找哇找哇找。在tomcat文档中找到apache apr的东东，可以提高系统的IO能力。从提升系统性能。APR提供了异步IO、共享内存、sendfile等linux操作系统中资源来优化tomcat这种java应用程序的IO能力。tomcat5.0使用普通IO能力，没有使用到操作系统的异步IO能力。如实决定使用apr进行优化。
    经过一些折腾后，系统启动起来，压力加上去了。发现并发数没有明显改善，响应能力也没有非常明显的改善。但是CPU和内存消耗下降明显。进入linux控制台，发现apache的进程数显著下降，下降到100个以下。tomcat的线程数也下降到200以下。但是可以支持的请求个数增加了，以前发生的超时问题没有了。说明我们找对路子了。

   经过后来继续加压，直到加压主机自身资源消耗殆尽。系统的并发能力提高了10%到20%左右，但是支持的链接数翻了几番。apache进程数没有显著增加，tomcat的进程数没有显著增加。可见APR异步IO的能力能够大大提高系统整体性能，降低系统消耗。