Monday, Aug 2nd, 2010 by Tim |
4 Comments
Filed under:
架构 | Tags:
latency,
profiler,
profiling
上个月发的谈团队每周技术交流引起不少同行感兴趣，如果那篇文章能起到促进业界公司内部技术交流那就是最大的贡献了。
上周五我们继续内部技术讨论，对某Java Web应用进行了latency分析。Latency主要是分析一个URL高并发请求下消耗时间的分布，比如ab(ApacheBench)输出结果最后一段
Percentage of the requests served within a certain time (ms)
50% 5
66% 6
75% 6
80% 6
90% 7
95% 8
98% 10
99% 18
100% 92 (longest request)
表示99%的调用是在18ms返回的，从结果来看latency比较低，反映相应URL的性能是比较理想。
这次技术讨论首先是情况介绍，测试工程师介绍了主要URL从本地IDC到全国的latency的分布图。另外DBA也从数据库的角度介绍了DB层面常见的latency来源。这样会后我们可以对最明显的问题进行优化和改进。
除去通用的问题之后当然是讨论方法，程序员关注的重心大部分还是从应用层面怎么降低latency。
压力测试
很多Web开发的朋友也经常讨论Web应用如何有效的进行压力测试，目前也没有万能的方法。可以使用的工具有loadrunner, 或者Erlang语言开发的tsung等，很多公司也有自己的内部工具。HTTP/Memcache/MySQL等协议压力测试其实相对简单，通常用自己脚本或者高级语言开发的工具比起通用工具来说效果会更佳。
profiling
对接口进行Profiling是发现瓶颈最直观的方法，Google据说就有很完善的内部profiler工具(当然Google内部什么工具都有)。我们讨论了目前不同开发人员使用的profiling方法的优缺点。
- 直接使用专业工具，比如JProfiler, 还有Java自带的JVisualVM等。
- AOP(Aspect-oriented programming)的方式，优点是对程序没有污染，在外部配置需要profiling的方法。
- 工具类的方法，需要在service方法前后加入小量关键点，优点是纯Java的实现，可以运行时动态打开或关闭profiler。比如通过给进程发signals的方法(见Signals and Java)动态让程序输出当前运行情况，起到了能够动态profiling服务器但在正常情况下又不影响服务器性能的作用。
从讨论情况来看大部分开发人员还是倾向于方法3，我们也希望团队能逐步建立类似Google内部profiler之类自己的工具。
Monday, Mar 8th, 2010 by Tim |
1 Comments
Filed under:
架构 | Tags:
facebook,
网游服务器
在2009年Facebook Developer Garage Shanghai活动上，Five Minutes程延辉 介绍开心农场架构，让大家了解了SNS game的一些挑战和设计模式。
由于农场游戏风靡全球，最近highscalability.com网站采访了美版开心农场FarmVille的Luke Rajlich，他介绍了FarmVille的部分架构资料(1)。
所有模块都是一个可降级的服务
For any web application, high latency kills your app and highly variable latency eventually kills your app.
由于大型的网络应用需要依赖各种底层及内部服务，但是服务调用的高延迟是各种应用的最大问题，在竞争激烈的SNS app领域更是如此。解决此问题的方法是将所有的模块设计成一种可降级的服务，包括Memcache, Database, REST API等。将所有可能会发生大延迟的服务进行隔离。这可以通过控制调用超时时间来控制，另外还可以通过应用中的一些开关来关闭某些某些功能避免服务降级造成的影响。
上面这点我也有一些教训，曾碰到过由于依赖的一些模块阻塞造成服务不稳定的现象。
1. 某Socket Server使用了ThreadPool来处理所有核心业务。
2. 不少业务需要访问内网的一个远程的User Service(RPC)来获取用户信息。
3. User Service需要访问数据库。
4. 数据库有时候会变慢，一些大查询需要10秒以上才能完成。
结果4造成3很多调用很久才能执行完，3造成2的RPC调用阻塞，2造成1的ThreadPool堵塞，ThreadPool不断有新任务加入，但是老的任务迟迟不能完成。因此对于最终用户的表现是很多请求没有响应。部分用户认为是网络原因会手工重复提交请求，这样会造成状况并进一步恶化。上面的问题根本是没有意识到远程服务可能会超时或失败，把远程服务RPC调用当成一个本地调用来执行。
解决思路一：RPC增加Timeout
解决思路二：将RPC改成异步调用。
另一分布式大牛James Hamilton谈到(2)上面这种做法就是他论文Designing and Deploying Internet-Scale Services中的graceful degradation mode(优雅降级)。
FarmVille其他数据
- FarmVille基于LAMP架构，运行在EC2上。
- 读写比例是3:1。
- 使用开源工具来做运维监控，如nagios报警，munin监控，puppet配置。另外还开发了很多内部的程序来监控Facebook DB, Memcache等。
- 到Facebook接口的流量峰值达到3Gb/s，同时内部的cache还承担了1.5Gb/s。
- 另外可动态调整到Facebook与Cache之间的流量，Facebook接口变慢时，可以利用cache数据直接返回，终极目的是不管发生了那个环节的故障，能够让用户继续游戏。
小结
尽管FarmVille公布了上面一些技术资料，凭借上面这些资料无法全部了解FarmVille的架构。但是所有模块都是一个可降级服务的概念值得设计大规模应用的同行参考。
Resource
- How FarmVille Scales to Harvest 75 Million Players a Month
- Scaling FarmVille
