架构师速成7.5-性能优化为什么写的这么晚?

性能优化是程序员的G点,一碰就会高潮!(小朋友不懂的不不要懂了)

但是我为啥这么晚才抛出这个命题,其实有人早就急不可待吧。我这么晚写是有这么晚写的理由的,其实性能优化,在做一个小的网站,根本没有什么卵用。一个流量小的网站,框架做好,架构做好,表结构设计好,根本没有太大的必要去优化,因为机器都闲着没有什么卵用,有时间不如把产品做好,吸引更多的人气。

其实我在到阿里之前,做过几个网站,而且也提了很高的要求,比如 用户一次请求,服务器端必须在100ms内返回结果。也做了一些性能优化,但是在寥寥无几的用户面前,这纯粹是浪费时间。但是到了阿里就不同了,阿里很注重性能优化,注重稳定,注重底层的参数设定。为啥?流量大了,你优化1%都会节省大批的机器,这都money。说个笑话,之前和同事一起优化了一个mr,算下来每天能节省70万,要是这个钱发给我,那就happy了。

过早优化是万恶之源,永远不要过早的去优化,去过度设计。当然不是说基本的代码规范不要了,有最佳实践当然按照最佳实践进行编码。过早优化是指的去做代码结构和一些主要逻辑的优化,这些没有必要过早去实施,真正发现瓶颈再去优化。

而且优化时不要想当然的去优化,一切要以测试为准。我经历过很多次代码优化,有时候很多代码改动,并不能带来性能的提升,反而增加了代码复杂度。印象最深的一次是优化了很多代码,都没有很大的效果,结果调整了一下jvm的参数,性能提升20%,所以一切过早的优化都是扯淡。还没有上线,没有测试的依据就进行优化,80%都是徒劳。

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-08-05 07:09:21

架构师速成7.5-性能优化为什么写的这么晚?的相关文章

蚂蚁金服架构师带你深入性能优化一MySql性能优化实战

概要: Mysql的优化,大体可以分为三部分:索引的优化,sql语句的优化,表的优化.本文主要帮助自己整理思路,也可作为一个学习MySQL优化的提纲. 索引的优化 只要列中含有NULL值,就最好不要在此例设置索引,复合索引如果有NULL值,此列在使用时也不会使用索引 尽量使用短索引,如果可以,应该制定一个前缀长度 对于经常在where子句使用的列,最好设置索引,这样会加快查找速度 对于有多个列where或者order by子句的,应该建立复合索引 对于like语句,以%或者'-'开头的不会使用索

阿里架构师之Java代码性能优化

代码优化 一个很重要的课题.可能有些人觉得没用,一些细小的地方有什么好修改的,改与不改对于代码的运行效率有什么影响呢?这个问题我是这么考虑的,就像大海里面的鲸鱼一样,它吃一条小虾米有用吗?没用,但是,吃的小虾米一多之后,鲸鱼就被喂饱了. 代码优化也是一样,如果项目着眼于尽快无BUG上线,那么此时可以抓大放小,代码的细节可以不精打细磨:但是如果有足够的时间开发.维护代码,这时候就必须考虑每个可以优化的细节了,一个一个细小的优化点累积起来,对于代码的运行效率绝对是有提升的. 代码优化的目标是 减小代

架构师速成-架构体系

经过这段时间的反思和整理,终于对架构有了一个较为明确的理解.架构是产品从无到有以及慢慢壮大过程中所需要的全部技术体系总称,架构过程: 配置.编码.测试.运维.监控分析.安全.运营等一系列技术体系的选型.取舍 技术选型基础上进行规划.设计.实现.迭代.制定相关规范 相关技术及规范运用到产品开发的整个过程中,并在产品迭代过程中对架构进行迭代优化 架构不止包含技术的框架,比如有人用了spring就觉得我已经是架构师了,其实架构并不是这么简单.我们以做一个新浪微博类似产品为例,现实应该是这样的: 产品初

架构师速成8.2-架构师要懂产品

产品和架构两个截然不同的职业,好像风马牛不相及,其实不是这样的.产品的思想需要经过技术的手来成为现实,在成为现实之前,需要技术理解.评估.碰撞.优化.把控.验证等等.当然架构师就承担了这一系列技术的责任,而且在一个产品的实现过程中,技术架构并不是很重要的,前期可以没有架构,简单快速验证,只有在用户多了之后,架构才有真正的用处.在初创公司,很多架构师都等不到用户多了的那一天,来实现自己的架构梦.所以产品这一关架构一定要把好,只有你把好了,后面才有机会让你去架构. 当然架构师的懂产品,是懂产品的生命

架构师速成8.3-架构师必须要了解的规则(转)

作为一个架构师,有些规则是必须要掌握的,这就想软件的公理,如果你学物理不知道牛顿定律,那就不要学了.在软件行业也有类似的东西,我称之为软件定律.例如: ACID,CAP,BASE ACID 传统数据库系统中,事务具有ACID 4个属性 (1)原子性(Atomicity):事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行. (2)一致性(Consistent):在事务开始和完成时,数据都必须保持一致状态.这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性:事务

架构师速成7.6-高中书单资料推荐

速读速记: 如何高效阅读 10倍速影像阅读法 超右脑快速记忆法 项目管理: 敏捷开发的艺术 敏捷软件开发 硝烟中的Scrum 和XP 精益开发实战 走出软件作坊 人件 人月神话 黑客与画家 死亡之旅 企业架构: 企业应用架构模式 devOps: 持续集成:软件质量改进和风险降低之道 性能: 深入理解Java虚拟机 Java性能优化权威指南 版权声明:本文为博主原创文章,未经博主允许不得转载.

架构师速成6.6-知识的收集整理学习

知识如何学习前面已经讲了2节,这节主要讲知识的整理和沉淀. 其实我之前也一直没有好好的思考过这个问题,今天在整理自己的wiz知识库的时候突发灵感,所以有了这一节. 其实知识获取的过程分为搜索->收集->整理->精化->应用->分享,前一部分跟时间管理的收集也很相近吧.知识获取的思路适用于有目的的知识收集和日常的备忘性的知识收集.当然你随机收集一些资料记录下来其实效果并不是很理想,重要的是你要有目的的学习才能最大的发挥你的心智以及潜意识.当你主动要学习一项知识时,你的潜意识会主

架构师速成7.3-devops为什么很重要

evops是一个很高大上的名字,其实说的简单点就是开发和运维本身就是一个团队的,要干就一起把事情干好.谁出了问题,网站都不行.作为一个架构师,必须要devops,而且要知道如何推行devops. 首先要自动化,举个阿里的例子,阿里通过aone系统来实现半自动化部署: 开发人员开发代码先自测通过后,提交代码到git. 在aone中一键部署到日常环境.部署是自动化扫描依赖冲突,系统安全等问题. 测试接到部署成功的通知,进行测试,如果测试通过,则审批通过,可以线上发布. 线上运维人员一键部署到线上,部

架构师速成4.2-幼儿园要学会如何高效学习

<如何高效学习>,这本书的作者是scotthyoung,最知名是的1年内自学完成4年麻省理工学院计算机科学的33门课程,同时也写了一个学习方法的Blog,他使用费曼技巧来加强理解和学习. 费曼技巧有很多种理解,最简单的是: 拿张白纸; 在白纸顶部写上你想理解的某想法或某过程: 用你自己的话解释它,就像你在教给别人这个想法. 最要紧的是,对一个想法分而化之,虽然可能重复解释某些已经弄懂的知识点.但你最终会到达一个临界点,无法再解释清楚.那里正是你需要填补的知识缺口.为了填补这个缺口,你可以查课本