作者文章: Fenng

TOP 第一章 之 如何解决性能问题

贴出Troubleshooting Oracle Performance 一书第一章《性能问题》的翻译稿的部分节录(初稿)。排版有点差。请多提意见。翻译的过程得到了很多朋友的大力协助,最后我会单独一一致谢!

TOP.jpg
(此书中文名字还未敲定)


如何解决性能问题?

简单而言,一个应用的目标是为使用它的业务提供便利。所以,优化一个应用性能的理由就是要最大化这种便利。这并不意味着性能的最大化,而是找到成本与性能之间的最佳平衡点。实际上,优化任务包括的努力总要从你期望获得的好处得到补偿。这意味着从商业的角度看,性能优化不总是有意义的。

业务视角 vs. 系统视角

优化一个应用的性能是为了给一个业务提供好处。所以当你着手接近(approaching)性能问题的时候,必须先理解业务问题和需求。然后才跳入应用的细节。图1-2演示了一个具有业务视角的人(一个用户)和一个具有系统视角的人(一个工程师)之间的典型不同。

TOP_CH01_01.png
图 1-2. 不同的观察者有不同的角度

认识到两种视角之间的因果关系是重要的,虽然结果必须从业务视角来识别,其原因必须从系统视角来确定。所以,如果你不想去诊断不存在或不相干的问题(强迫调优失调症),理解从业务视角看问题就变得更重要 — 即使这需要更多精细的工作。

把问题分类

对付性能问题的第一步是要从业务视角确定它们并为每个问题设定一个优先级和目标。如图1-3所示。

从业务视角来确定问题 > 设定每个问题的优先级 > 设定每个问题的优化目标

业务问题不能通过观察系统统计发现,而必须从业务视角来确定。如果代之以监控服务等级协议,很明显,可以从没有满足期望的操作来确定性能问题。否则,除了询问用户或者负责的人之外没有其他可能性。这种讨论将涉及一系列操作。例如:注册一个新用户,运行一个报告或加载一批可能很慢的数据。

你知道哪些是有问题的操作,就该给他们排个优先级了。考虑类似这样的问题:如果我们只能处理5个问题,应该如何做呢?当然,最好是全部解决它们。但有时候时间或预算是有限的。此外,缺乏必要措施的情况下,不可能解决不同问题的相互冲突。要强调的是在设定优先级时,当前的性能可能是不相干的。例如,如果你处理一整套报告,不一定最慢的那个具有最高的优先级。可能最快的那个也是执行最频繁的那个,因此有可能具有最高优先级并需要首先优化。再说一次,是业务需求在驱动你。

对每项操作,你应当为优化设定一个可量度的目标。诸如”当创建用户按钮按下以后,处理时间最多2秒”。如果性能需求甚至服务等级协议可以得到,可能目标已经知道了。否则,再强调一次,必须考虑业务需求去确定目标。注意,没有目标就不知道何时停止研究一个更好的解决方案。换言之,优化可以是无止境的。记住,努力永远要和获利取得平衡。

解决问题

诊断整个系统比诊断一个单独的组件要复杂得多。因此,任何可能的时候,你应当一次只解决一个问题,简单地从问题列表按照优先级从高到低的顺序解决。

对每个问题,如图1-4所示,必须回答3个问题:

  • 时间花在哪里了?首先,你必须确定时间花在哪里了。例如,如果一个特定操作用时10秒,你必须找到这10秒里绝大部分花在哪个模块或组件。

  • 时间是如何耗费的?一旦你知道时间花在哪里了,你必须找到时间是如何耗费的。例如,你发现应用用了4.2秒在CPU上,0.4秒做I/O操作,5.1秒等待另一个组件发出队列出队消息。
  • 如何减少时间耗费?最后,才是找出怎样使操作更快的时候。要做到这个,重要的是聚焦到处理中最大时间消费的部分。例如,如果I/O操作占整个处理时间的4%,那么即使它很慢也没必要对他进行调整。
时间花在哪里了? > 时间是如何耗费的? > 如何减少时间耗费? 

要注意由于副作用的益处,有时候修复一个特定问题的同时也会修复另一个问题。当然,相反的情况也会发生。采取的措施可能引入新的问题。所以,很有必要认真考虑修复过程中可能引起的所有副作用。显然,所有改变在应用到生产环境前都要经过仔细测试。

EOF

此文作者:, 位于 Database 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

日落西山 – Oracle 收购 Sun

真是一种嘲讽,就在刚才,收到一封广告信,标题是 "Sun为企业发展提供更多动力"

对于 IT 产业来说,这是最好的时代,这是最坏的时代。Sun 要做 Web 2.0 中的这个 Dot 没做成,74 亿美金把自己卖掉了。

zot_sun_s_oracle_b.gif

尽管我不是 Sun 的粉丝,还是感觉不太痛快。这次收购意味着又有若干产品有可能被打入冷宫。而大家比较关心的 MySQL 可谓命运不济,被 Sun 折腾一年多,在开源社区里面一点好没讨到,这回在 Oracle 新的产品线里面如何定位呢? will be an addition to Oracle’s existing suite of database products… 当然,InnoDB 这回和 MySQL 算是破镜重圆了。是否有其它变数,比如被原 MySQL 团队赎身出来? 难!

对于 Oracle 来说,这次自己终于有了硬件(SPARC)和操作系统(Solaris)这两块王牌,其实 Oracle 和 Sun 算是多年的合作伙伴了(超过 25 年),相信整合起来可能问题不大。这次收购比较失败的可能就是 IBM 了,Oracle 这次给了竞争对手 IBM 以更大的压力。难道蓝色巨人出不起这个价格麽? 还是觉得足够鸡肋? Sun 手里的 Java 技术对于 IBM 的小型机是个很好的补充,想不通。再过几年,这可能就是 IBM 犯过的最大错误。

不痛快的除了 IBM ,恐怕还有 RedHat。不过别着急,没准儿哪天 Oracle 也把 RedHat 也一并收了,我相信 RedHat 手里的 JBoss 至少让 Oracle 眼馋不已。有 JBoss 在,其他中间件就不可能赚到更多。

一切皆有可能。其他事情不好确定,但有件事情还是能基本肯定,拉里·埃里森大叔这回又有机会体验一下世界首富的滋味了…

EOF
延伸阅读:

小规模低性能低流量网站设计原则

到处都是什么大规模啊,高流量啊,高性能之类的网站架构设计,这类文章一是满足人们好奇心,但看过之后也就看过了,实际收益可能并不大;另外一个副作用是容易让人心潮澎湃,没学走先学跑,在很多条件仍不具备的情况下,过度设计、过度扩展(高德纳大爷也说过,”过早优化是万恶之源”),所以,这里反弹琵琶,讨论一下小规模低性能低流量的网站该如何搞法。

如果站点起步阶段可能就是一台机器(或是一台虚拟机,比如 JobsDigg.com ),这个时候,去关注什么数据拆分啊,负载均衡啊,都是没影子的事情。很多大站点的经验绝不能照搬,辩证的参考才是硬道理。

拥抱熟知的技术

动手构建站点的时候,不要到处去问别人该用什么,什么熟悉用什么,如果用自己不擅长的技术手段来写网站,等你写完,黄花菜可能都凉了。所以,有现成的软件组件可用,就不要自己重新发明轮子。人家说 Python 牛,但自己只懂 PHP ,那就 PHP 好了,如果熟悉 .net ?,那也不错。用烂技术不是丢人的事情,把好技术用烂才丢人。

架构层次清晰化

起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起,业务一旦扩增开来,如果原有的一堆东西拆不开就是非常痛苦的事情。

Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB

层次清晰化的一个体现是(以 LAMP 架构为例):即使只有一台机器,也应该起个 Memcached 的实例,效果的确非常好(除非内存小)–一般人儿我不告诉他…不要把什么都压到 DB 上,DB 一旦 I/O 压力走到磁盘上,问题要暴露出来是很快的。没错,DB 本身也会利用自己的 Cache,但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。

数据冗余? 有必要

很多人并不是数据库设计专家,如果应用要自己设计表结构什么的,基本都是临时抱佛脚,但三个范式很多人倒是记得牢,这是大多数小型 Web 站点遇到的一个头疼事儿,一个小小的应用搞了几十个表… 忘掉范式这个玩意儿! 记住,尽可能的冗余数据,你在数据层陷入的时间越多,你在产品上投入的就会越少。用户更关心的是产品的设计。

前端优化很重要

因为流量低,访客可能也不多,这时候值得注意的是页面不要太大,多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人),用户看个页面半分钟都打不开,你说咋发展? 先把基本的条件满足,再去研究前端优化

功能增加要谨慎

不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销,反而收效甚微。记住,小站点,最有价值的是业务模式,而不是你的技术有多牛。技术是为业务服务的,不要炫技。

有些网站不停的添加功能,恰恰是把这些新功能变成了压死自己的稻草。

从开始考虑性能

这一点是可选的,但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展,很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是,对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。

好架构不是设计出来的

这是最后要补充的一点。好的架构和最初的设计有关系,但最重要的是发展中的演化:

发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)

有些站点到了某个阶段停足不前,可能卡在执行力这个地方,来自用户的反馈意见上来了之后,没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是”业务不允许”的托词,试想如果不改进业务都没了,那业务还允许么? 其实就是一层心理障碍。

这篇文章有浓重的山寨风格,所以,你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话,可参考其中对你有益的点,不赞同的地方可以直接忽视掉,就没必要费力留言进行争论了。

EOF

  • 好的业务模式(产品) + 很好的技术 = 大赚钱
  • 好的业务模式(产品) + 能用的技术 = 也赚钱
  • 差的业务模式(产品) + 好的技术 = 赚吆喝(现在的SNS就差不多这样了)
  • 差的业务模式(产品) + 差的技术 = 自己浪费资源
此文作者:, 位于 Arch 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

再谈 eBay 的扩展性最佳实践

很多人都觉得 eBay 在 QCon (北京) 上的技术讲座不错,但对我来说,其实冲击力没那么大了。eBay 一两年前就是这个 PPT 。不过还是比 Amazon 的 Jeff Barr 强了很多,以后要是开个什么会,你把 Jeff Barr 请来还讲那个销售文档,估计自己都不好意思。

不过,eBay 这次的PPT 总算还是有点更新的。

1)数据分片(Partition Everything)

说是分区(Partition),这里不能简单等同于 Oracle 的分区,理解成分片(Sharding)就好啦。可以参考一下我以前写的科普小文:开源数据库 Sharding 技术 (Share Nothing)。这里要强调一下的是,分片是在数据量的确有规模的时候才适合进行,如果单节点足以应付,那么还是不要冒进。

从分片的模式上,eBay 主要根据功能切分(Functional Segmentation)和水平分割(负载均衡考虑),作为推论,所有会话都是无状态性的。

2)异步处理(Asynchrony Everywhere)

其实对于任何网站来说,过度追求”同步”化设计还是比较糟糕的做法。以用户能观察到的数据为视角进行设计,中间可以最大限度用异步来完成。

eBay 的举例的模式有两个,一个是事件队列(Event Queue),另一个是信息分发(Message Multicast)。前者基本上是个生产者–消费者的模型。后者主要用在搜索的架构上。

eBay_message_multicast.png

注意到图中的消息总线,这才是 eBay 整个架构中的动脉,估计轻易不会批露技术细节

3)自动化(Automate Everything)

这里的自动化举了两个例子,一个是针对运维方面的,另外举了关于机器学习的东西,这是演讲者 Randy Shoup 的强项所在。

eBay 的自动化,在一年前的另一篇文章里可以窥测一点东西。只是这篇文章当初没有被更多人重视,参见:eclipse at eBay。可以看到 eBay 能在自动化方面做得这么好(起码敢出来讲)不是一朝一夕之功。

4)故障检测与回溯(Remember Everything Fails)

更好的失败检测机制: 监控每天超过 2TB 的日志,根据日志中的相关事件得出判断或者预警。这个看起来简单,但实现起来还是需要一点技巧和策略的,重要的是,需要不断根据结果的反馈去改进。

完美回滚: 任何服务都通过服务配置中的标记来识别,无痛回滚。(个人感觉这个非常有难度,尤其是升级的时候)

优雅降级(Graceful Degradation):能够相对容易的对应用标记”Marks down(下线)”

5)拥抱不一致性(Embrace Inconsistency)

举了 CAP 原则,程立将其形象描述为帽子戏法,非常准确。说起一致性,自从 Amazon CTO Werner Vogels的 Eventually Consistent 一出,基本上不需要再废话了,这就是事务处理的九阴真经,大家回家慢慢参详好了。

eBay 也有自己的绝对准则: 绝对没有分布式事务(两阶段提交), 通过状态机与操作顺序最小化不一致性,通过异步事件(消息总线?)达到最终一致性。

EOF

另外小道消息:Amazon CTO Werner Vogels 可能会参加六月份在杭州举办的侠客行大会。

以前的老帖子:eBay 的Scalability最佳实践