性能啊！性能！
之所以想写写性能调优，也是有感于我们的项目，我们採用一些手段使得系统性能上升了一个台阶，总是须要把这点经验沉淀一下。随着工作的深入，关于系统性能的事肯定还有非常多，也算是通过这个系列文章做做笔记。优化可能包含应用级别的优化，也可能包含代码级别的优化。
忘记是从哪里看到了这句话，但总算切中要害。
但在找性能瓶颈之前，我们总要先对系统性能有一个概念。
怎样在不购买新硬件的条件下完毕很多其它的工作?何时才真正须要加入硬件(很多其它的内存，更快的磁盘、 CPU以及网络接口)?有时仅仅需消除一些简单的瓶颈就可以解决很多性能问题——可是要实现它，你必须充分了解自己的计算机和网络，从而找到真正的瓶颈所在。在预算短缺的今天，理解怎样优化系统性能比以往不论什么时候都重要。一味地投资并非可以让人们接受的办法——而且也不一定生效
-------《系统性能优化》
再看两篇文章吧
看了上面的陈述，相信你已经有所感触，说得直白一点，系统性能就是在尽可能降低投资的情况下，解决以下两个事：
- Throughput ，吞吐量。也就是每秒钟能够处理的请求数，任务数。
- Response time， 响应时间。也就是系统在处理一个请求或一个任务时的响应时间。
我们要做优化，就是为了让吞吐量更大，让响应时间更短，在二者之间达到平衡，满足我们的业务要求。
所以，我们要发现性能瓶颈，事实上就是找到影响吞吐量和响应时间的地方。
怎么找？
使用工具！
这里提到了
十个免费的Web压力測试工具
工具还有非常多，上面10个，我没有亲自用过，只是，我倒是用过一个測试java web项目性能的工具：javamelody
JavaMelody可以在QA和实际运行生产环境监測Java或Java EE应用程序server。并以图表的形式显示：Java内存和Java CPU使用情况，用户Session数量，JDBC连接数，和http请求、sql请求、jsp页面与业务接口方法（EJB3、Spring、Guice）的运行数量，平均运行时间，错误百分比等。图表可以按天，周，月，年或自己定义时间段查看。
截张图给大家看看
这仅仅是一部分图标，它提供的信息要远比这丰富。
工具和方法论说多了无益，下篇文章给大家来点猛料。
发现瓶颈，怎么办？别急着去找程序的麻烦，先去操作系统，操作系统的报告。看看操作系统的CPU利用率，看看内存使用率，看看操作系统的IO，还有网络的IO，网络链接数，等等。通过了解操作系统的性能，我们才知道性能的问题，比方：带宽不够，内存不够，TCP缓冲区不够，等等，非常多时候，不须要调整程序的，仅仅须要调整一下硬件或操作系统的配置就能够了。说这些是为了提醒你，不要急着去改动你的代码。
假设到了非要动代码的地步，瓶颈这东西也能够依据2：8原则来说，20%的代码耗了你80%的性能，找到那20%的代码，你就能够优化那80%的性能。所以，紧紧锁定那不到20%的代码。
兴许文章，我会列举一些项目中性能调优的经验，供大家參考，也欢迎补充。