前言
这篇文章非常有意思，写于2012年11月1日，不过下面所看到的是2013年11月9日基本上重新写了一篇。之前的内容基本上没有怎么保留。开始也在想要不要新开辟一篇来写，后来想想还是修改比较好一些，后续我也会持续的修改一些文章。对于自己而言是对于一些知识的回顾和整理。因为时间过去了往往对一个东西的认识会有所改变，也对一些已经遗忘的知识重新学习。
废话不多说老，开始今天的正题。
常见的概念
这里先介绍和性能有关的一些名词，这是一个基础。因为在实战中所遵循的原则也基本在这些理论之上。只是理论很简单，实战很残酷。这里说一个题外话：很多实战派的看不起学院派，两派一向比较仇视对方。
RT
RT的全称是Response Time，顾名思义就是响应时间的意思，指的是请求发出去到结果返回之前的时间差。
TPS/QPS
这两个词在这里我们就不做区分，可以简单的认为每秒处理的请求数。那么意味着TPS/QPS提高一倍就意味着处理能力增加一倍。如果知道RT，那么TPS = 线程数量 * 1000/RT。从这个公式可以看出来增加线程数可以增加TPS。但是由于整个资源的逐渐饱和，随着线程数量的增加，RT也随之增加。所以线程数量增加到一定的时候，TPS并不会增加，而且会有所下降，为什么？讲到Context Switch的时候就全明白了。
CPU Time
一般来讲一个请求不完全是CPU型的，比如说去DB或者缓存取数据，这段时间对于当前的请求来讲并非在耗费CPU资源，这也是多线程的意义所在，比如说一个应用全是计算，如果运行这个应用的机器是单核的，那么开多线程往往会影响使性能下降，为什么？看下面一个概念。
Context Switch
从字面意思来讲指的是“
上下文切换”，在这里我想表达的意思其实是线程之间的切换。也就是说CPU在处理多线程的时候会频繁的让出CPU资源给其他线程，这样上下文切换的成本就上来了。这里也就解释上面我说的问题，为什么在单核存计算的情况下开多线程会使性能下降。因为多出了线程切换的时间。这个可以好好领悟一下。
最佳线程数
什么是最佳线程数，其实就是一个应用各种资源达到最优协调结果，这是一种理想状态，一般来讲这个值是实际压测出来的。
影响性能的节点
CPU
这个估计没有什么疑问，CPU的执行效率明显的会影响整个请求的时间，所以有时候的请求很慢可能是CPU已经达到100%，这时候就会发现CPU是整个性能的瓶颈。在这里CPU是一个表象，因为使得CPU达到100%的因素很多，比如说处理逻辑太复杂，内存使用不当导致频繁的GC/FGC。当然CPU是一个切入点，一般性能优化的切入点都是观察当前机器整个运行行情况，而不是一股脑的去看代码。
IO
IO包括很多，
网络IO，
内存IO，
磁盘IO。这些IO的时间都会影响整个性能，下面详细讲霁这几个IO。
网络IO
一般情况下如果有远程服务的话那么性能瓶颈就有可能出在网络IO上，另外由于数据通过光纤传输也是需要时间的，比如说从杭州到北京一个来回大概是40ms的时间，对于一些性能要求比较高的应用来说这样的开销有时候同样不可接受，CDN节点一定程度上就是为了解决由于传输导致的性能损耗。这里突然想到一个非常有意思的事就是计算机硬件架构中离CPU越近的节点（比如说L1）性能都非常好。离CPU最远的磁盘性能最差。
内存IO
内存的使用一般是缓存，这一块的优化就比较细致了，对于性能要求极其严格的场景，内存的换入换出也会导致性能的下降。这个可以看一下整个计算机硬件架构。
磁盘IO
这种场景比较常见，数据库其实就是最常见的磁盘IO。一般在数据库IO的性能会严重影响整个请求的性能，这也是当前各种Cache大行其道的原因。
一张图
下面这张图就是大概画了一般我们可以见到的一些场景，从性能分析的角度来讲也是一个入手点。下面每一个节点都有可能是性能的瓶颈所在，一般程序员都知道一个二八原则，往往20%的程序消耗了80%的资源，所以找到一个点进行着力优化往往会有非常好的效果。
总结
上面只是从整个概念下手和影响性能角度入手来阐述性能，性能领域更多的是靠实战和不断的积累夯实，实战的工具特别多，比如说Linux的Top命令来观查CPU的使用状态，jstack可以打出当前的线程堆栈，virsualVM可以查看整个内存、CPU等一系列的东西。上面所讲的也只不过是冰山一角，比如说随便一个概念都需要去查很多东西然后才知道个所以然。开发工程师能做到的是把自己每一行代码写的漂亮。这些同样需要很多功底。当然从架构的角度他可能需要考虑整个应用的性能。上面的东西整个来讲还是偏理论，可以说给一些不知道的同学扫个盲。