如果是以上所说的小用户时：程序上的问题。程序上存在数据库的问题，那就必须采用更加专业的工具来抓取出现问题的程序，
主要是程序中执行效率很低的sql语句，weblogic可以采用introscope定位，期间可以注意观察一下jvm的垃圾回收情况看是否正常，我在
实践中并发500用户和600用户时曾出现过jvm锯齿型的变化，上升下降都很快，这应该是不太正常的。
近
几天在性能测试过程中，发现loadrunner Controller经常报 Server “**” has shut down the
connection prematurely 。概率很高，现象很奇怪。网上有很多说法，各有不同，但貌似都不正确，只能靠自己追踪。
根据经验仔细分析，发现可能跟下列因素有关：
（1）loadrunner客户端服务器网卡资源不足；
（2）tcp/ip连接超时时间设置太长，造成无连接可用；
（3）应用服务端有问题。
一、用事实做详细的对比：
分析：从对比结果来看，shut down的比例跟loadrunner客户端确实有关系，但无论客户端怎样改变，还是该现象出现，而且比例始终超过万分之1。
loadrunner服务器数量 | TcpTimedWaitDelay键值 | 并发用户数 | 平均TPS | shut down比例 |
1台 | 30s | 13 | 76.195 | 万分之18.4 |
1台 | 10s | 7 | 66.49 | 万分之10.8 |
2台 | 10s | 7 | 85.994 | 万分之1.39 |
2台 | 10s | 2 | 33.544 | 万分之1.23 |
至此，可以排除loadrunner客户端的原因。
二、转向服务端，在dpm服务器上，发现apache占用很大的资源，而且有报错：
（1）在压力情况下，apache（httpd进程）占用的物理内存，平均每秒增涨4M，非常恐怖；
（2）Apache日志中有三类报错信息：
a、 [Tue Jun 30 18:54:37 2009] [error] [client 192.168.**.**] unable to
init Zlib: deflateInit2 returned -4: URL
/distributor/product/my_product_list.htm
b、 [Tue Jun 30 18:54:38 2009] [notice] child pid 28699 exit signal Segmentation fault (11)
c、Memory allocation failed.
分析：经过观察，推论出httpd进程占用物理内存狂增，导致服务器没有剩余资源分配给它，造成memory allocation failed。
三、修改和屏蔽一些apache配置项，例如减少SendBufferSize所占空间、屏蔽CustomLog日志。都无济于事。
问题到底出在哪？ 欲知后事如何，敬请关注该主题的下一篇blog。
上一篇Blog讲到，性能测试过程中发现server shut down现象，经过追踪，定位到是apache子进程狂吃内存。
根据经验，判断问题可能出在apche加载某个/某些模块上。于是，使用“拆分问题，隔离分析”的分析方法。先隔离出apache加载的所有模块。再采取注释、重启、验证的方式，逐步缩小隔离范围。最终定位出瓶颈点。
系
apache在加载一个Taobao**_module时，每秒消耗4M内存，导致apache占用的物理内存不断增涨，当涨至操作系统能分配给
apache的最大内存时，apache子进程死掉。在老的子进程死亡和新的子进程创建的时间间隔，有请求过来，系统自然没有响应，从
loadrunner那端看，就是server shut down。
真相得以大明。接下来就是对这个模块进行优化了。
一个 1.84/千 ，背后竟然隐含如此巨大的性能问题。如果不深究，问题很快就被忽视了，系统上线之后，不被上帝眷顾的用户很有可能就打不开网页了。整个瓶颈查找的过程，我想可以让我们想到以下几点：
1. 性能测试工程师需要具备敏锐的观察力，再小的概率，只要出错，必定深究；
2. 性能测试工程师需要有清晰的思路，先查什么，后查什么，要设计得很明确；
3. 除了注重jboss和java程序，apache也应当重点关注，特别是出现error的时候；
4. “拆分问题，隔离分析”的方法确实很实用；
5. 尽信书不如无书，遇到具体问题要具体分析。
