高性能架构策略.pptVIP

性能质量属性的意义 在软件工程发展史的大部分时间,性能一直是促使系统架构发展的重要驱动力.同时它也经常影响所有其他质量属性的实践.随着硬件性价比的下降和开发成本的提高,其他质量属性的地位已经和性能不相上下了. 肥皂盒与电风扇的故事 话说某跨国日化公司，肥皂生产线上面存在包装时可能漏包肥皂的问题。 ??? 于是该公司总裁命令组成了以博士牵头的专家组对这个问题进行攻关.该研发团队使用了世界上最高精尖的技术（如红外探测、激光照射等），在花费了大量美金和半年的时间后终于完成了肥皂盒检测系统，探测到空的肥皂盒以后，机械手会将空盒推出去。这一办法将肥皂盒空填率有效降低至5%以内。问题基本解决之。 ???? 再说某乡镇肥皂企业也遇到类似问题,老板命令初中毕业的流水线工头想办法解决之,经过半天的思考,该工头拿了一台电扇到生产线的末端对着传送带猛吹，那些没有装填肥皂的肥皂盒由于重量轻就都被风吹下去了。 ???? 不同的思维早就不同的结果，但有时反而被知识绊住了脚，现在想想，上了这么多年的学，基本都是脱离了到底为啥上学这个初衷，脱离了实际，不同的年纪会有不同的想法，等5年以后再来看这个小故事，会有怎样的看法。 性能策略 高性能相关指标 响应时间:系统完成一次外部请求处理所需的时间. 吞吐率:给定时间内能够处理多大的请求量. 响应抖动:随着请求的增加,等待时间的变化 丢失率:系统太忙无法响应,导致的未处理的世界的丢失 ……… 强烈推荐书籍 性能设计9大原则 性能目标原则 为性能场景定义具体的,量化的,可测量的性能目标.,避免使用迷糊目标陈述. 探测原则 在建立系统时进行探测使测量和分析工作量负载场景,资源需求,性能目标的一致性成为可能. 中心原则:识别关键工作量负载并使其处理过程最小 本地化原则:创建与计算接近的活动,功能和结果 处理与频率原则:使处理与频率的乘积达到最小 固定点原则 对于响应性,固定应当在尽可能的时间点建立连接,这样该连接具有高效性 共享资源原则 在可能的时候共享资源,如果独占(排他)访问时,使保持时间和调度时间最短 并行处理原则 仅当处理过程增速抵消通信开销和资源增用延迟时,并行才是有意义的 分散负载原则 有可能在不同的时间或不同位置处理冲突的负载时,分散负载 性能模式 快速通道模式:确定关键工作量负载功能并且简化处理过程,仅保留必要部分 重要事情优先:如果不能在可用时间完成全部请求,优先考虑最重要的请求 耦合:让界面与最频繁使用的对象匹配 批处理:把请求组合成批从而使开销只需执行一次而不是对每个请求执行一次 替代路由:对高使用率的对象,分散对到其的请求到不同的对象或位置 弹性时间:分散到高使用率的请求分散到不同时间段 弱化周期性功能:最小化必须按照固定间隔执行的工作量 麦当劳模式:把数据和相关处理分离,然后提前准备(大道相通) 奥运订票网站挂了，如果是你，如何设计？ 10月30日，北京奥运会门票面向境内公众第二阶段预售正式启动。上午9：00点一开始，不到半小时，网站系统便宣告瘫痪。访问者看到，官方票务网站当天上午开始,都只是显示“系统繁忙,请稍后再访问.不便之处敬请原谅.”的提示信息。 当天官方网站发布了如下的致歉消息，“上午9时至10时，官方票务网站的浏览量达到了800万次，每秒钟从网上提交的门票申请超过20万张，票务呼叫中心热线从9时至10时的呼入量超过了380万人次。由于瞬间访问数量过大，技术系统应对不畅，造成很多申购者无法及时提交申请，为此北京奥组委票务中心对广大公众未能及时、便捷地实现奥运门票预订表示歉意。” 而此前，组织者声称已经对第二阶段的售票做了充分准备，“为了应对在30日可能出现的奥运门票订票高峰，北京奥运票务中心容军表示，三种购买渠道连接同一售票数据库，在优先权上没有区分。票务系统已经做了多次压力测试，票务系统每小时将能处理3万张门票的销售，以及承担每小时100万次以上的网上浏览量，应该说可以确保承受启动时期的一个压力。 对此，奥运票务中心有关人员昨天说，奥运票务系统瘫痪，错不在“先到先得”政策，还是当时系统设计有问题，没有考虑到如此高的需求。其实，比现在再高的瞬时流量，只要投入足够的资金和人力，系统设计合理，也可以满足。多名网络技术专家表示，不要说800万次，就是每小时8000万次，从技术上说，也是小菜一碟。 架构师, 请你PK!! 如果是你来设计和架构这个网站，你如何应付这种大规模访问量和数据处理量？ 性能架构策略-1 资源需求 提高计算效率 减少计算开销 管理事件频率 控制取样频率 性能架构策略-2 资源管理 引入并发 维持多副本 增加可用资源 限制执行时间 限制队列大小 性能架构策略-3 资源仲裁 资源调度 先进先出 FIFO 固定优先级 请求重要性 请求较短优先 动态优先级 动态调度