之所以想写写性能调优，也是有感于我们的项目，我们采用一些手段使得系统性能上升了一个台阶，总是需要把这点经验沉淀一下。随着工作的深入，关于系统性能的事肯定还有很多，也算是通过这个系列文章做做笔记。优化可能包括应用级别的优化，也可能包括代码级别的优化。
看了上面的陈述，相信你已经有所感触，说得直白一点，系统性能就是在尽可能减少投资的情况下，解决下面两个事：
- Throughput ，吞吐量。也就是每秒钟可以处理的请求数，任务数。
- Response time， 响应时间。也就是系统在处理一个请求或一个任务时的响应时间。
我们要做优化，就是为了让吞吐量更大，让响应时间更短，在二者之间达到平衡，满足我们的业务要求。
所以，我们要发现性能瓶颈，其实就是找到影响吞吐量和响应时间的地方。
怎么找？
使用工具！
这里提到了
十个免费的Web压力测试工具
工具还有很多，上面10个，我没有亲自用过，不过，我倒是用过一个测试java web项目性能的工具：javamelody
JavaMelody能够在QA和实际运行生产环境监测Java或Java EE应用程序服务器。并以图表的形式显示：Java内存和Java CPU使用情况，用户Session数量，JDBC连接数，和http请求、sql请求、jsp页面与业务接口方法（EJB3、Spring、Guice）的执行数量，平均执行时间，错误百分比等。图表可以按天，周，月，年或自定义时间段查看。
这只是一部分图标，它提供的信息要远比这丰富。
工具和方法论说多了无益，下篇文章给大家来点猛料。
发现瓶颈，怎么办？别急着去找程序的麻烦，先去操作系统，操作系统的报告。看看操作系统的CPU利用率，看看内存使用率，看看操作系统的IO，还有网络的IO，网络链接数，等等。通过了解操作系统的性能，我们才知道性能的问题，比如：带宽不够，内存不够，TCP缓冲区不够，等等，很多时候，不需要调整程序的，只需要调整一下硬件或操作系统的配置就可以了。说这些是为了提醒你，不要急着去修改你的代码。
如果到了非要动代码的地步，瓶颈这东西也可以根据2：8原则来说，20%的代码耗了你80%的性能，找到那20%的代码，你就可以优化那80%的性能。所以，紧紧锁定那不到20%的代码。
后续文章，我会列举一些项目中性能调优的经验，供大家参考，也欢迎补充。
