这几天做了点性能测试，感觉对公司的平台更多了些了解，说实话，真是不怎么样，而且感觉公司的开发也不是很open，很多技术性的问题感觉不能得到很好的讨论，或许因为我是个姑娘？或许因为我只是做测试而不是开发？

目前平台的表现是10个用户并发，直接导致应用服务器cpu占用99%，数据库服务器倒是压力不大，感觉压力并没有分到数据库上，而且在绘制的性能图上，有个奇怪的表现，内存从起初的剩余1个多G，在一个小时的压力下迅速下降到只有33M，但之前我也确实压过平台，看了平台的垃圾回收曲线，感觉不应该存在内存泄露问题，那唯一的可能性就是大量的对象在内存中没有被释放。那如果我的假设正确的话，就有两种可能，一个真的是没释放，线程一直保持着，没关闭，另一种是垃圾回收不够及时。

按照这两个思路，那就有两种方案，垃圾回收的触发点跟jvm分配的虚拟内存有关，我查看了机器的jvm内存分配情况，初始值给的2G,最大值给了4G，正常8G的机器，应该是-xms2g，-xmx2g这样比较标准，我曾经在测试tomcat的时候有过尝试，在8G机器上把这两个值设置成4g后，gc时间影响不大，但fullgc时间大大加长，超过1秒，正常合理的fullgc时间应该在1秒以下。所以是否能把最大值往下调成2g比较合适？现在市面上比较流行的参数设置也是-xms =-xmx。应该打印下gc时间来看看垃圾回收状态

另一种可能性，如果打印出来的gc时间发现真的一切正常，但就是每次回收不下来，这个情况我遇到过，上次的压力测试就是这样的表现，那我认为应该查查哪些对象在一直在内存中占用不释放

此外解决了内存异常下降的问题以后，我们再来看看cpu占用问题，10个用户而且只是模拟登陆系统，按理服务器压力不至于这么高的占用，而且一个登陆应该后端java端处理并不复杂，不至于如此。对这个也有两种设想，一种前端请求过多，服务器忙于服务前端请求，这个使用了firefox下面的yslow查了一眼，确实证实了我的猜想，提示过多的http请求。

另一种可能大量被创建的线程空闲，但又得不到释放，因为正如之前所说，一个简单的登陆后端处理并不复杂，除非在请求过来的时候，服务端因为某些原因创建了大量线程，虽然并不处理工作，但程序却一直不释放他们，这样就有可能导致后面陆续进来的请求堆积申请线程，但又没有线程可用，导致一部分线程频繁工作，另一部分却是空闲但得不到使用。为了证实这点，我使用netstat -ant查看了一下我们的连接，发现从本地的一个ie连接，在服务端却相应的建立的6个established，不可思议，基本上一个网站访问过去，只有一个连接而已，为什么我们在ie中访问，却会一下建立6个连接？这是为什么？！

另外查看发现应用服务器和数据库服务器的established连接数保持在140个左右，而且始终没有回落的迹象，查看了程序的数据库连接池，发现初始化就用了140个，我们只是做简单的一个登陆操作，10个用户，正常需求下数据库连接池，初始值应该是四五十已经很多了，max的值可能设置成140，但我们的程序为什么要初始化这么多，10个用户大致就用了10个连接，另外130个连接都在空闲状态，但又得不到释放？！为什么要这么配置？！有个开发能给我个理由么？、

以上也仅仅是我的思考，可能对系统的整个运行我研究的也不深入，有事google和baidu，貌似对于这类问题也很少交流，所以随便写写，欢迎指正。

最后，还是想说一句，谁他妈写的程序，真够操蛋的！