最近做
portal
的压力测试，一个字“累”。其中犯了不少错误，白白加了几天班，也有一些体会，就记录下来，希望对大家有所帮助。
首先讲压力测试环境。这个很是关键，我们就是在这个上面吃了苦头。我们用的
loadrunner
，原理也很简单，一台主控机，控制多台客户机，模拟并发用户访问应用。然后需要能实时监控各相关应用服务器，
ldap
服务器等的性能。这里每台客户机最好能使用同样的配置，使用足够带宽的网络，给予同样的负载（模拟同样数量的用户）。同时要注意监控客户机的
cpu
和网络状况，时刻保证
cpu
和网络利用率低于
100%
。我们犯的很大错误就是使用各自的笔记本，而且都使用的是一个
10M hub
牵出的网线，这样导致实际的网络阻塞，既没有给予服务器足够的负载，又导致报告的响应时间比实际更长，从而带来了后续很多的无用测试。
然后讲测试方法。用的较多的还是持续压力测试，就是持续给予服务器一段时间的并发量（一般为
5
到
10
分钟），然后看平均响应时间是否在可以接受的范围内。这个“可接受”要视应用类型和实际的并发用户而定，如何估计并发就要靠经验了。对于
portal
而言，由于要与众多的应用接口，如进行
SSO
，获取数据等，有很大程度也依赖于其它应用的性能，其性能要求不会太高。我们测试首页的性能，在放上全部的
portlet
的情况下，
100
个并发的平均响应时间就在
17s
左右，这肯定是不能接受的（
10s
只能算勉强可以）。接下来就是发现性能瓶颈，并尝试进行优化了。
初步的发现瓶颈的方法也很简单，通过对
portlet
的增减，发现最影响性能的
portlet
，然后不断优化，直至达到可以接受范围。发现瓶颈所在了，就得进一步确定是什么原因：是我们本身程序的问题，还是其它应用接口性能不佳等等。这里光靠猜是不行的，要讲数据讲事实，记录时间日志就是简单有效的办法，我们对各个时间点打印了日志，比如
doview
方法的全部执行时间，
jsp
的载入时间，具体接口的执行时间等。有些接口可能在压力较小的情况下性能不错，而在大压力情况下出现性能隐患，所以一定要在进行压力测试后查看日志。我们就是这样发现了性能隐患，同时更进一步对各方面进行优化，直至达到客户可以接受为止。
由于不是专门的测试人员，很多地方都是实际项目中的体会，也没什么理论基础。有什么不对的地方，大家多交流。