|
本帖最后由 lang_net 于 2014-12-4 13:56 编辑 接上篇运维三天入门，就发这个版了，版主挪到别的版也可以。 性能优化的方向
性能优化之道往往在技术之外。
一．性能优化的误区 网上看到很多性能优化的文章，大多有一定技术难度，也深受运维同学喜爱，因为颇显水平，但也让很多初学者误认为性能优化主要是调整内核参数，不然都不好意思在同行面前说。 二．内核往往不是问题 为什么说内核往往不是问题，首先写内核的程序员普遍水平较高，第二是内核经过了严格的测试，三是内核经过了广泛的生产系统考验，这样的工业级产品，出现问题的概率是比较低的，而大部分的应用开发人员水平相对普通（不代表绝对，只是统计意义上的），内核的问题那么多人都没发现，偏偏被你发现了？另外操作系统的设计目的是为了更好的管理各种资源，努力发挥硬件性能，而不是无谓消耗。 纵观整个计算机的发展史，性能提升最明显的地方有二，一个是硬件性能的不断提升，什么奔三，奔四，core duo，ddr2，ddr3；再一个就是算法的进步，比方说什么进程调度，内存管理，io策略。很多历史上的性能问题在目前的软硬件条件下，早已不是问题。但这种性能提升好像都是物理和数学方面，太深奥了，改内核并不容易！ 当然我说了这么多并不表示内核一定没有问题，不值得研究改进，而是我们干事情不能犯方向性的错误。遇到问题时，应该学会正确有效的思考，要不然可能徒耗精力，不见成果。
三．大出着眼 实际上，90%的性能问题至少不是内核的问题，而是应用的问题。所以，遇到性能问题的时候，我们的第一想法应该是从应用的角度去解决。具体是应该怎么做，我觉得可以2个方面考虑：
1. 技术层面 所有性能优化的技术手段都可以总结为2个方面，一个是增加吞吐，一个是减少响应时间。Raid卡cache，磁盘cache ，内存，Memcache，redis，nginxcache，cdn，浏览器本地cache，看看这些技术是不是都是为了这2个目标，如果遇到性能问题，先看看应用是不是很好的利用了cache，下图也许有些参考意义。
我们再拿物流做个比喻，当车子运货时，是不是绕远路了（跨网访问），取货地点是不是太远（就近访问），一批货物要运多次（数据量太大），物流站上货速度快不快（逻辑处理时间），能不能多个人，多辆车同时上货（分布式处理）….,其实，有时候，距离越近，逻辑越简单，响应时间就越短。看看大公司里搞得什么gslb啊，cap网络啊，负载均衡，优化程序逻辑，不也就是这个目的嘛。 就目前的情况来看，这些技术手段其实基本是现成的，善于利用就能解决很多性能问题。 2. 产品层面 有时候产品方面的调整可以起到比技术更好的效果，最典型的例子就是论坛里的帖子总数了，这个数字通常没人关注，说明更新频率不是很重要，如果从每s更新一次改成每10分种更新一次，想想数据库压力可以减少多少。再比方说视频网站，晚高峰流量成为瓶颈，都要看高清的，就卡的没法看了，那是不是可以降低码率，让用户看标清的，相比不能看，用户体验还是好多了吧。这种事情我们经常遇到，这类性能问题，不仅是技术问题，还是沟通问题，你得让那些不懂技术的产品明白。 四：深入学习 对于目前90%的互联网应用，性能瓶颈往往都在内核之外，没必要一开始就想着调内核，尤其对于初学者，越调越危险。 即使系统变得很大，从非技术层面调整性能的取得的效果往往依然惊人。一些大公司应对海量问题的方法中，大都在技术之外。 当然很多人还是愿意研究内核对性能的影响，这是条苦行僧之路，也是通往高手之路，不仅需要学习的兴趣，更应该想办法找到这样的环境去学习，最后配张图，送给新上路的同学。
|
|
|
