当Web Server发生503错误后，Twitter配置了一个前端鲸鱼的显示页面。Twitter对鲸鱼页面有监控体系，当每秒超过100个鲸鱼就会引起报警。

为什么在单位时间内会有大量的”fail whale”呢？Twitter成立了一个小组来专门分析此原因。

1. 分析背景资料

“分析性能问题不是一门科学，而是一门艺术”。

鲸鱼页面实际上是对HTTP 503错误的前端展示，503错误通常是调用后台请求超时产生，为了避免用户长时间等待，Twitter的前端(Tim: 也可能是HTTP反向代理)给请求加了超时，避免用户无限制的等待。超时通常是由于单位时间内访问的用户数过大，也有可能是后台某个服务突然变慢造成。
由于Twitter网站每个时刻都有海量的数据流过，因此要简单的定位并解决此问题并不容易。

2. Web page请求分解

Twitter的页面请求后端分成2个阶段，在Twitter内部称为IO phase及CPU phase。IO phase指通过网络服务获取用户的关注关系及相关的Tweets。第2阶段为CPU phase，指将数据聚合、排序及按用户请求的条件输出。IO及CPU各自在1天内消耗的时间如下。

从图上看到，latency增大时IO是主要瓶颈。IO对应于Network service，因此可以判断是某个网络服务性能降级造成。

3. 深度分析

理想情况是网络服务在应答相同参数的请求消耗时间应该基本相同。但实际情况并非如此，我们大胆假设某一网络服务性能下降厉害，于是我们就从统计分析中去寻找这个服务，我们看到Memcached的统计图表如下

4. Memcached 竟然是鲸鱼故障的直接原因

可提高的空间及解决思路

1. 从上图看，Memcached在 latency高峰的性能比低谷相差一倍，因此最简单的判断是增加硬件即可提高50%的性能。
2. 另外一种思路就是优化Memcached程序，判断程序热点和瓶颈并进行优化。

分析

1. 通过 Google perf-tools project 工具来分析, http://code.google.com/p/google-perftools/ http://github.com/tmm1/perftools.rb
2. 通过自己些的一段分析代码来监控 http://github.com/eaceaser/ruby-call-graph
3. 通过上面工具的call graph来分析热点和瓶颈

最后分析数据Memcached请求分布比例如下

get         0.003s
get_multi   0.008s
add         0.003s
delete      0.003s
set         0.003s
incr        0.003s
prepend     0.002s

get         71.44%
get_multi    8.98%
set          8.69%
delete       5.26%
incr         3.71%
add          1.62%
prepend      0.30%

结论：从上面数据来看，调用热点和瓶颈主要集中在Get操作

因此回头取看Twitter页面执行流程代码，找出优化方法见注释。

get(["User:auth:missionhipster",              # 将昵称转换成uid
get(["User:15460619",                         # 获取user object(用于检查密码)
get(["limit:count:login_attempts:...",        # 防止密码字典攻击
set(["limit:count:login_attempts:...",        # 大部分情况不需要, bug
set(["limit:timestamp:login_attempts:...",    # 大部分情况不需要, bug
get(["limit:timestamp:login_attempts:...",
get(["limit:count:login_attempts:...",        # 重复调用，可记住
get(["limit:count:login_attempts:...",        # 重复调用
get(["user:basicauth:...",                    # 防止解密的优化
get(["limit:count:api:...",                   # 请求数限制
set(["limit:count:api:...",                   # 设置请求数，大部分情况不需要，为什么？
set(["limit:timestamp:api:...",               # 大部分情况不需要, bug
get(["limit:timestamp:api:...",
get(["limit:count:api:...",                   # 重复调用
get(["home_timeline:15460619",                # home_timeline业务调用
get(["favorites_timeline:15460619",           # favorites_timeline业务调用
get_multi([["Status:fragment:json:74736693",  # multi_get所有tweets内容

上面这段代码将17个请求优化成10个，部分重复调用通过本地cache避免，另外一些没必要的调用直接删除。通过一个简单的优化性能就提高了42%。

结论

1. 在前文2010年的技术架构建议中提过Cache已经是Web 2.0系统核心元素。从Twitter的故障案例来看Memcached竟然成为了瓶颈并导致了Twitter服务的不稳定。由于在social应用中cache核心化的设计，“RAM is the new disk”，在cache广泛使用后也变得调用成本增加，需要考虑进行系统的规划减少不必要的调用。避免开发人员在代码中随意使用cache
2. 如何定位瓶颈，可以借鉴Google perf-tools项目及上面其他分析工具的思路。
3. Twitter页面执行流程值得参考
4. 整个故障流程分析图如下

• Twitter架构图(cache篇)
• 用Twitter的cursor方式进行Web数据分页
• MemcacheDB, Tokyo Tyrant, Redis performance test
• Twitter API最近的一些飞跃
• Twitter系统运维经验

Twitter没有自己的硬件，都是由NTTA来提供，同时NTTA负责硬件相关的网络、带宽、负载均衡等业务，Twitter operations team只关注核心的业务，包括Performance，Availability，Capacity Planning容量规划，配置管理等，这个可能跟国内一般的互联网公司有所区别。

1. 运维经验

* Metrics

Twitter的监控后台几乎都是图表(critical metrics)，类似驾驶室的转速表，时速表，让操作者可以迅速的了解系统当前的运作状态。联想到我们做的类似监控后台，数据很多，但往往还需要浏览者做二次分析判断，像这样满屏都是图表的方法做得还不够，可以学习下这方面经验。 据John介绍可以从图表上看到系统的瓶颈-系统最弱的环节(web, mq, cache, db?)
根据图表可以科学的制定系统容量规划，而不是事后救火。

* 配置管理

每个系统都需要一个自动配置管理系统，越早越好，这条一整理发到Twitter上去之后引起很多回应。

* Darkmode

配置界面可以enable/disable 高计算消耗或高I/O的功能，也相当于优雅降级，系统压力过大时取消一些非核心但消耗资源大的功能。

* 进程管理

Twitter做了一个”Seppaku” patch, 就是将Daemon在完成了n个requests之后主动kill掉，以保持健康的low memory状态，这种做法据了解国内也有不少公司是这样做。

* 硬件

Twitter将CPU由AMD换成Xeon之后，获得30%性能提升，将CPU由双核/4核换成8核之后，减少了40%的CPU, 不过John也说，这种升级不适合自己购买硬件的公司。

2. 代码协同经验

* Review制度

Twitter有上百个模块，如果没有一个好的制度，容易引起代码修改冲突，并把问题带给最终用户。所以Twitter有一强制的source code review制度, 如果提交的代码的svn comment没有”reviewed by xxx”, 则pre-commit脚本会让提交失败, review过的代码提交后会通过自动配置管理系统应用到上百台服务器上。 有@xiaomics同学在Twitter上马上就问，时间成本能否接受？如果有紧急功能怎么办？个人认为紧急修改时有两人在场，一人修改一人review也不是什么难事。

* 部署管理

从部署图表可以看到每个发布版本的CPU及latency变化，如果某个新版本latency图表有明显的向上跳跃，则说明该发布版本存在问题。另外在监控首页列出各个模块最后deploy版本的时间，可以清楚的看到代码库的现状。

* 团队沟通

Campfire来协同工作，campfire有点像群，但是更适合协同工作。对于Campfire就不做更多介绍，可参考Campfire官方说明。

3. cache

• Memcache key hash, 使用FNV hash 代替 MD5 hash，因为FNV更快。
• 开发了Cache Money plugin(Ruby), 给应用程序提供read-through, write-through cache, 就像一个db访问的钩子，当读写数据库的时候会自动更新cache, 避免了繁琐的cache更新代码。
• “Evictions make the cache unreliable for important configuration data”，Twitter使用memcache的一条经验是，不同类型的数据需放在不同的mc,避免eviction，跟作者前文Memcached数据被踢(evictions>0)现象分析中的一些经验一致。
• Memcached SEGVs, Memcached崩溃(cold cache problem)据称会给这种高度依赖Cache的Web 2.0系统带来灾难，不知道Twitter具体怎么解决。
• 在Web层Twitter使用了Varnish作为反向代理，并对其评价较高。

• Twitter架构图(cache篇)
• Twitter“鲸鱼”故障技术剖析
• Memcache mutex设计模式
• Google说，一个Datacenter就是一台计算机
• Twitter停用Cassandra原因分析

现场情况

很多参会的同学都做了精彩的总结，很客观，所以我也没必要进一步补充了。本次计划人数是50人，结果超出了一点，所以会场有点挤。(还有不少同学后到的，实际人数比照片上要多)

不足

根据大家的反馈来看，主要有以下几点

1. 交流机会不足

本次也是依照传统的活动方式，演讲加提问，然后剩下时间小范围自由交流然后散会。由于会议室较小人又偏多，所以技术沙龙变成了技术演讲会。这个也是我们技术沙龙需要继续思考的一个问题，是限制参加人数以便形成多方讨论？还是召集更多的技术人来进行单向技术分享会？（当然不管哪种方式，并不妨碍我们用视频直播，视频及演讲稿分享等方式传达给更多群体）

2. 不够专业及深入

由于我选的Key value store题目过大，所以大部分内容只能蜻蜓点水。最大的价值可能就是给对这些方面感兴趣的同学提供一个参考的学习方向。

演讲稿说明

大家感兴趣的可能是Benchmark那部分，其实那个只是花了几个小时的功夫，因为手头的测试试验环境相对比较全面，所以测试起来也没费什么周折。其实我自己最看重、最希望传达的是演讲稿的后半部分，希望大家在设计自己的网络应用的时候，能够借鉴一些先进的分布式思想，指导自己少走一些弯路。部分观点其实我也没有实践经验，但是根据自己目前手头的一些应用的现状，觉得应用这些思想到系统中可以极大的提高系统的可扩展性及可维护性。Dynamo等Paper像一座桥梁，可以拉近我们与国外分布式设计思想的距离，让我们在这些已经被认可的方法的基础上去发现新的问题，迎接更有意义的挑战。

由于这次要组织活动，所以基本没同来参会的各位向往已久的同学深入交流，这个是最大的遗憾。

下一期的技术沙龙是zhuzhaoyuan的nginx源码剖析方面话题，预计在9月中上旬召开，地点在网易。

附：搜集到一些同学的作业

• 广州技术沙龙 (qiongyue)
• 广州技术沙龙归来 (leechael)
• 广州第一次技术沙龙总结 (lidaobing)
• 广州线下技术交流沙龙 (hoorace)
• 广州第一次技术沙龙感受 (arbow)

• 广州技术沙龙安排
• 第一期广州技术沙龙预告
• 广州技术沙龙设想
• Web 2.0技术沙龙设想
• 谈团队每周技术交流

Topic 2: 分布式 Key Value Store 漫谈 (Tim Yang)

视频(上)

视频(下)

• 第一期广州技术沙龙预告
• 广州技术沙龙安排
• 广州技术沙龙设想
• 分布式key/value store演讲草稿(一)
• 第一期广州技术沙龙活动总结

1. 选好业务和技术，单枪匹马做游戏 (赖勇浩)

2. 分布式key/value store漫谈(Tim Yang 杨卫华)

全部演讲稿将在会后公开。

时间：2009/08/08 14:00进场，14:30开始

地点：广州市天河路208号粤海天河城大厦39F 新浪公司

活动指南：

已经报名的同学请检查确认邮件(周二8/3之前会全部发出)。凭名片(报名的姓名)或身份证件在粤海天河城大厦大堂领取门禁卡，然后到39F前台签到。

交通：地铁1号线，3号线体育西路C出口，公交线路体育中心站。

地图：地图一：谷歌地图, 地图二：三维地图

(8/8 Update: 由于资料都在公司，演讲稿会在周一8/10发布。录制的视频也会在整理上传之后，下周稍晚时间发布)

• 广州技术沙龙安排
• QCon Beijing qconbeijing全部演讲资料下载
• 第一期广州技术沙龙活动总结
• Facebook的feed格式设计
• 广州技术沙龙设想

为什么大部分Web应用都应转向分布式的Key/Value store

Dynamo

• Consistent Hashing
• N,R,W
• Virtual Node
• Vector Clock

与传统key/value store的区别，软件还是需要服务

分布式应用可以从Dynamo等分布式实现可以借鉴的经验

• 第一期广州技术沙龙演讲稿及视频
• 多IDC的数据分布设计(二)
• 2010年的技术架构建议
• 第一期广州技术沙龙预告
• 广州技术沙龙安排

时间：8月8日14点30分开始
地点：新浪华南分公司会议室(可容纳20-50人) 广州市天河路208号粤海天河城39F (初定)
本次活动无需费用。

演讲的主题
1.分布式key/value存储dynamo等分析(偏原理, Tim Yang)
2.分布式xmpp系统(偏实践, Tim Yang).
3.SNS开放平台openid/social/fb connect等(偏知识)
4.Erlang,支持单台>5万并发用户的web前端服务器实践

另外候选的主题还有
网游服务器开发技术分享《选好业务和技术，单枪匹马做游戏》(赖勇浩)
nginx 源码剖析(Joshua Zhu，下一期讲)

因时间有限，本次活动最终只会讲一个主题，需参加者请提前邮件 iso1600 # gmail.com 报名，以便统计人数，并在邮件注明1.姓名 2.感兴趣的话题 3.您的Blog地址(Blogger优先考虑)。4. 邮件标题请写[报名广州技术沙龙]，由于人数已满，报名已经截止。确认邮件会在周二(8/4)之前发出，没收到确认邮件的可以邮件询问。

请关注 http://timyang.net/tech/guangzhou-salon-090808/ 以了解最新动态。

• 第一期广州技术沙龙预告
• 广州技术沙龙设想
• 第一期广州技术沙龙演讲稿及视频
• 谈团队每周技术交流
• 第一期广州技术沙龙活动总结

目前碰到的问题：

• 暂无强势的本地论坛及讨论组来讨论技术活动，即使很多本地网友有聚会意愿，也没有很有效的渠道去传达到这些用户
• 没有偏技术及IT主题的线下咖啡馆固定场地，这个相对障碍较小。
• 本人对组织技术类的聚会也缺乏经验，如果有经验的人愿意参与来组织当然更佳。

场地以广州为主，深圳也不排除。

希望有意向的朋友献计献策。可发邮件给iso1600(at)gmail(dot)com，或DM给xmpp@twitter，也可直接在本文留言。

Update: 赖勇浩同学在Twitter上提议8月8日举行一次聚会(需翻墙查看)，我深表赞同，对主题有建议的可留言或请按上面方式与我联系。

Update 2: 人数暂定50人以下，同时增加游戏服务器的Topic, 包括MMORPG, WebGame, SocialGame等。有意向的同学可以发邮件预报名参与或演讲。

欢迎转发本文到各技术论坛、讨论组及QQ群等。

• 第一期广州技术沙龙活动总结
• Web 2.0技术沙龙设想
• 广州技术沙龙安排
• 谈团队每周技术交流
• 5%的神话(关于开发效率与职业方向)