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

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
EMR Serverless StarRocks,5000CU*H 48000GB*H
网络型负载均衡 NLB,每月750个小时 15LCU
简介:
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年了,前不久又学了一句话,那是“只要是没有人为因素的纯技术问题,是一定一定有解决办法的!”


 本文转自 dog250 51CTO博客,原文链接:http://blog.51cto.com/dog250/1271011

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
3月前
|
开发者
软件设计与架构复杂度问题之注释在软件设计中的角色如何解决
软件设计与架构复杂度问题之注释在软件设计中的角色如何解决
|
3月前
|
设计模式 算法 开发者
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
|
4月前
|
设计模式 算法 开发者
软件复用问题之区分「不重复」和「复用」,如何解决
「不重复」和「复用」之间有何区别软件复用问题之区分「不重复」和「复用」,如何解决
|
6月前
|
存储 安全 Java
12条通用编程原则✨全面提升Java编码规范性、可读性及性能表现
12条通用编程原则✨全面提升Java编码规范性、可读性及性能表现
|
6月前
|
设计模式 IDE Java
谈谈过度设计:因噎废食的陷阱
本文探讨了设计模式在软件开发中的应用和争议,指出设计模式虽有助于应对软件复杂性,但在互联网快速迭代的背景下,可能会导致过度设计,增加理解和修改成本。文章分析了设计模式的缺陷,如开闭原则可能导致不易修改,最小知识原则可能导致理解困难。同时,文章强调了设计模式的重要性,指出它们可以提高代码的可理解性和模块的可维护性,并提出了通过函数式设计模式进行优化的示例。作者认为,设计模式需要随着业务演进而不断演进,同时提倡使用可调试的模块和模式演进来促进系统的成长性。文章最后提醒读者,要根据实际情况选择是否使用设计模式,避免因噎废食。
|
6月前
|
搜索推荐 测试技术
性能场景之业务模型中二八原则的误区
【2月更文挑战第18天】性能场景之业务模型中二八原则的误区
157 6
性能场景之业务模型中二八原则的误区
|
设计模式 测试技术 程序员
代码的简单设计五原则
代码的简单设计五原则
33084 1
|
SQL 缓存 安全
如何避免写重复代码:善用抽象和组合
通过抽象和组合,我们可以编写出更加简洁、易于理解和稳定的代码;类似于金字塔的建筑过程,我们总是可以在一层抽象之上再叠加一层,从而达到自己的目标。但是在日常的开发工作中,我们如何进行实践呢?本文将以笔者在Akka项目中的一段社区贡献作为引子分享笔者的一点心得。
160 0
如何避免写重复代码:善用抽象和组合
|
SQL 程序员 测试技术
本着什么原则,才能写出优秀的代码? (一)
本着什么原则,才能写出优秀的代码? (一)
160 0
本着什么原则,才能写出优秀的代码? (一)
|
设计模式 前端开发 关系型数据库
本着什么原则,才能写出优秀的代码? (二)
本着什么原则,才能写出优秀的代码? (二)
206 0
本着什么原则,才能写出优秀的代码? (二)