前言：
很久没写文章了，因为最近和朋友讨论问题时说到了性能优化这个话题，特将我之前解决一个linux下服务器性能问题的思路和方式共享一下。
背景：
基本需求如下：在Linux下，有一台数据处理服务器，需要从网络上的很多节点获取信息，并按照管理员的要求进行分析和过滤，然后保存结果等待二次处理（从业务逻辑上，可以认为是网监部门从各位的QQ聊天中分析关键字，发现特别之处进行关注或请喝茶 -- 相信这样各位好理解，虽然这个项目和网监部门或QQ没有半毛钱关系）。
当时的业务要求是为了满足客户3~5年内的需求。需要留下足够的数据处理余量，其关键点就是数据量。4K 个客户端(使用了很多客户端模拟器进行模拟)，峰值时每个客户端每五分钟平均生成5M的数据，这些数据会上传到服务器，服务器必须在五分钟内处理完毕，否则会越积越多。因此每秒需要处理的数据量为： 4000 x 5 / 300 = 66.7M Bytes = 533M bit。 想一想在 1000Mbit 带宽的网络环境下，平均每秒钟需要在网络上传递 533Mbit 的有效数据（还没有计算网络封包的附加数据、其他通信的数据）到一台服务器上，并进行分析、过滤、存储、压缩等处理，是一个什么概念(而且由于之前SE们计算出现错误，是按日平均水平计算的数据量，但后来又分析说需要按照峰值计算数据量
)。如果单机不能解决，就需要上分布式，从而增加成本和复杂度。何况当时的分布式实现还不是很完善，仓促上的话，问题更多。
初步测试：
初步测试，在少于500个客户端时处理很正常，但当增加到1000个客户端时，出现收不到客户端上传文件的机率大大增加，虽然有补采机制来满足业务逻辑的需求，但性能上严重不达标。当时领导们也很重视，找了很多相关的SE们帮助分析，提了很多尝试解决问题的方法，比如：
1.使用 gprof 测试性能瓶颈，不行的话就用 oprofile;
2.因为程序中有很多步骤，分析每一个步骤理论上需要花多少时间，然后测试。发现不满足的步骤，则进行优化。当每一个步骤都优化后，就到了程序能处理的上限。
3.其他很多方法。。。
虽然这些方法都是性能分析时的常见方法，但这些方法过于理想化，在这种大数据量才发生问题的情况下，几乎没有可操作性（各位想想gprof、boundsCheck等性能分析工具的原理应该就知道我的意思了）。
这个时候唯一合理的方式就是分析日志了，但日志的量又太大(最大数据量运行起来后，30秒左右生成一个30M的日志文件)，也很难分析出具体的关键字来直接搜索。
问题解决：
本人在分析日志时，有一天突发奇想。这些日志信息都有很多基本的信息，比如 线程ID，打印日志的时间，内容等。如果解析出同一线程里两条日志的时间间隔，并认为这就是这两条记录之间的代码的执行时间，不就能很快定位具体的性能瓶颈了？
本人立刻将我以前写的专门分析FTL日志的LogViewer工具进行了改造。运行程序后，打开日志，按照时间间隔反向排序，在数十万条日志记录里，立刻发现几条耗时180秒的日志。经过分析，立刻定位是要求模拟器上传文件，但模拟器没有相应的超时信息。立刻联系模拟器开发人员，让其定位相关日志，最后确认是模拟器的实现问题。将其更改后，服务器中出现无法接受到文件的情况大大降低。从日志定位到分析出最终的结果，花费时间不超过一个小时（而且大半部分在模拟器那边），It's so easy and so fast, Isn't it?
最后，通过这个方法，用很少的时间定位并更改了项目中的几个问题，并采用了一些特殊的优化技巧（因为这些技巧涉及到一些特别的信息，我就不介绍了）。最后测试，在4K客户端的情况下，五分钟的数据在三分钟左右就能全部处理完毕，轻松达到了性能要求。
补充：
A. 大家看完这个文章，可能会说“太简单了，谁不会啊”。我也觉得是，就像把鸡蛋立起来一样，关键就是要有创造性的思维，否则我可能还陷在 oprofile 等工具里呢
。
B. 性能属于非功能性需求，一般的开发人员会陷入两个误区：
1.在设计和开发时根本不管性能问题，在最后才测试，发现问题后才更改；
2.整个项目的开发过程中，始终深陷性能泥沼，花了太多的精力、时间在不会发生的“性能问题”上。
个人认为， 性能问题主要分两个方面，
1.性能设计 -- 主要在设计和编码中，是理论联系实际的过程。分析出性能瓶颈，测试 -> 优化 -> 测试。这时需要遵循一些所谓的性能设计原则（比如中心化、有效减负、并行处理、分散负载等）和性能设计模式（比如快速通道、空间换时间、时间换空间、异步IO等）。具体内容大家可以自己找资料，我就懒得抄书了
2.性能优化 -- 主要是在测试阶段，是实际联系理论的过程。测试中发现一些以前没有考虑到的问题，关键是准确地定位问题点，分析并优化。此时需要针对不同的问题，合理采用不同的方式、方法、工具，才能达到事半功倍的效果。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
以下为补充信息：
最近和做大数据的同事讨论到数据处理效率的问题，介绍其20多台机器的集群，一天处理的数据量为1T多。也大概算了一下这个系统的数据处理能力，结果发现数据处理量超高，简直吓自己一跳
日处理数据量：66.7M Bytes/秒 * 3600 秒 * 24 小时 = 5.76T <== 单机日处理数据量为 5.7T，相当于同事系统中 100 台机器的处理量。不过这种简单的类比方式比较粗糙，各种不同的系统中对业务数据的处理逻辑不同，复杂度也不同，只能作为大致的参考。比如我们这个系统是一个实时的 过滤、统计系统，对接收到的数据处理完毕后可以立刻删除，而且统计出来的结果和原始数据相比，数据量也小了很多。不然的话，如果要将每天 5.7T 的数据通过 hdfs 等保存起来，单个的千兆网口就是远远达不到要求的，而且设计上也会完全不同。