关于优化需要永远牢记的原则

1.尽量不要去搞什么性能优化，因为十有八九你会失望的

首先，不要指望调节系统参数就能带来性能的大幅提升，这永远都不可能，因为如果能大幅提升，那组参数早就成默认参数或者写进文档了，即使不一定这样，起码有对技术比较痴迷的家伙会把类似的经验分享出来，轮到你来做这件事的几率很低很低。正如你能想到电梯的创意，可那玩意儿都已经存在100年了。

其次，如果一个参数的微调能引起性能数量级级别的变化，那就是内核的bug了，你需要的是提交修复补丁而不是引以为成果！

再次，仅仅通过优化的方式希望得到性能大幅提升，那你是过分依赖软件了，这种可能性正如你大幅度被加薪的可能性一样大。虽然不乏通过跳槽使薪资翻倍的可能，但其中也不乏欺世盗名之徒，他们依赖的是面试技巧，学历，资历等，而不是“自身性能的翻倍”。调节薪水一次肯定不会调太多，你需要在一个薪水档次慢慢沉淀一下自己，明白了这一点，就不要急于做优化了，1.6G主频的cpu在没有换成2.4G主频cpu之前，不要指望通过软件的方式大幅提高性能，即使到了2.4G主频的cpu，也不要指望性能能提高2.4/1.6倍，这个道理正如你一天能写160行代码，你的薪资为1.6k，然后半年后你一天能写的代码数量达到了240行，难道你的薪资就一定能自动到达2.4k吗？我看难。

因此，性能优化和你自身的优化一样，你需要稳扎稳打，而绝对不能指望一夜之间脱胎换骨，搅和起来N多的因素需要考虑，软件只是一种将硬件组织起来的东西，如果你的硬件有“硬伤”，那还是先治疗硬伤为好。所以说，程序员们不要一味的整天“代码，代码，代码，我用了效率最高的算法，为何不能更快一些”，深入下去，从整体上考虑会更好一些

2.所谓的优化只是统计意义上的优化而已。

因此能不优化尽量不要优化

3.不要过分依赖负载均衡，有时候负载均衡并不适合你的场合

Intel的千兆网卡支持多个队列，可以将负载均衡到所有cpu上，每个cpu处理一个队列，然而测试后你会发现，大多数情况下，将绑在一个cpu上性能或许会更好些。实际上学过基础理论的都知道负载均衡是个好东西，然而对于Intel的千兆卡，它大多数还是用于虚拟化的，而不是普通的主机环境。我们需要考虑的是cpu拓扑，中断绑定，cpu缓存拓扑等综合因素的影响，而不是过分依赖一个很时髦的名词。

4.看代码是看不出什么东西的

现在很多的guo书，blog上都在大量剖析代码，Linux源码分析，Apache源码分析，XX源码分析...可是看代码究竟能提高自己吗？能是肯定的，但是很难！

我觉得在软件技术领域-当然不单单只软件开发，有所谓7个层次：

a.数量使用和配置软件

b.剖析优秀软件代码或者了解其实现原理

c.调试优秀软件

d.部署复杂软件，使之成为一个可用的复杂系统且能迅速故障定位

e.整体系统性能调优，能找到瓶颈，且能准确选型

f.对各种软件技术触类旁通

g.hacker

处于a级别的太多了，你我ta都是，处于b级别的也不少，科班出身的几乎都有这爱好，并且有大批的人停留在此级别，c级别的呢，windows程序员比较多，他们喜欢搞反汇编之类的，而且还喜欢炫耀ringX的知识...处于d阶段，你就很厉害了，毕竟软件是来使用的，可能d级别的人根本就不懂c语言，也没看过什么代码，然而我觉得它们一下子能搞定复杂系统的部署和定位故障，这本身就是一种超级武器，e阶段的人总的来讲和d阶段是并列的，只是方向不同，e阶段的家伙一般是忠于单点的，而d阶段的家伙一般忠于整体。f阶段的就不必说了，这种人本身肯定对技术很痴迷，并且能胜任几乎一切工作，g阶段的家伙们很随意，他们是真正的自由人，他们想做的事情总是干得很漂亮，他们不想干的事情，...

以上分类并不是一个顺序的分类，可能a级别的人一辈子也不会到达b，然而却可以到达g，这只是学习方向不同，也是自身品位不同。

5.优化自身的原则

为了提高逻辑思维能力和条理性，需要学习数学和逻辑学，我高中时有一个物理老师，他讲的所有内容中，我觉得有一点很有用，那就是“你必须要有大段大段整理数学式子的能力”；

作为一名软件研发人员，3年前在长春的一家公司，那里的一个很牛的人说了一句话，我现在都记得，他说“你要有大量整理字符串的能力”，整理字符串的过程中体现的是你的组织能力和，折射出的是你的算法思想。

如今，从业5年了，前不久又学了一句话，那是“只要是没有人为因素的纯技术问题，是一定一定有解决办法的！”