﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>BlogJava-Tin's Blog-随笔分类-RoR</title><link>http://www.blogjava.net/iamtin/category/26582.html</link><description>You are coming a long way, baby~Thinking, feeling, memory...</description><language>zh-cn</language><lastBuildDate>Tue, 16 Oct 2007 01:45:11 GMT</lastBuildDate><pubDate>Tue, 16 Oct 2007 01:45:11 GMT</pubDate><ttl>60</ttl><item><title>Twitter的性能调优的关键点</title><link>http://www.blogjava.net/iamtin/archive/2007/10/16/scaling_twitter_the_key_points.html</link><dc:creator>Tin</dc:creator><author>Tin</author><pubDate>Tue, 16 Oct 2007 00:42:00 GMT</pubDate><guid>http://www.blogjava.net/iamtin/archive/2007/10/16/scaling_twitter_the_key_points.html</guid><wfw:comment>http://www.blogjava.net/iamtin/comments/153144.html</wfw:comment><comments>http://www.blogjava.net/iamtin/archive/2007/10/16/scaling_twitter_the_key_points.html#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.blogjava.net/iamtin/comments/commentRss/153144.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/iamtin/services/trackbacks/153144.html</trackback:ping><description><![CDATA[<p>Twitter的水平扩展的一些关键点，虽然它是个RoR应用，但是这些建议绝对是放之四海而皆准的，非常好的总结。<br />
因为年初Twitter曾经遇到了性能瓶颈，而且几乎束手无策。当初很多人开始怀疑Ruby的性能问题，而后Twitter站起来了 ^__^</p>
<p>有时间的朋友看看这个slide：<a href="http://www.slideshare.net/Blaine/scaling-twitter">http://www.slideshare.net/Blaine/scaling-twitter</a>，没有时间的看看我的摘要。<br />
<br />
开发：<br />
1、一定要测试！一定要早点测试！一定要早点测试！否则你就死定了。不要存任何侥幸心理，从项目的开始就写好测试。<br />
2、对任何部分都要测试。还是测试！<br />
3、性能测试要交给用户来做。那样才有意义。所以要做好log。用好分析工具：Munin（服务器内存占用监控）、Nagios（服务器服务网络状态监控）、AWStats &amp; Google Analytics、错误日志、发现了错误马上进入问题跟踪系统（Trac、Jira&#8230;&#8230;太多了，但是最好有一个）。</p>
<p><br />
架构：<br />
1、使用可以分区的架构。按照架构上的功能清晰的分区。这意味着你可以通过替换一个实现来改进性能，因为性能和复杂度往往是不可兼得的。</p>
<p>对于数据库：<br />
1、尽量不要分布式数据库，包括数据库分区。最好通过提高单台服务器的性能提升这个节点的性能。更重要的是查询优化。通过备份服务器解决单点故障。<br />
2、对where子句中的字段增加index。（这个当然了）<br />
3、扁平化查询，比如一个user有很多朋友，查一个人的朋友如果通过外键会浪费很多性能。可以把ids序列化为1,2,3这样，然后用like查询速度更快。<br />
4、一定要优化你的SQL，不要寄希望于ORM给你解决（不管是DataMapper、ActiveRecord或者UnitOfWork）。</p>
<p>Cache：<br />
1、一定要考虑Cache，最重要的是领域对象的Cache，一定要考虑Memcache，如Memcached。<br />
2、应该有90%的查询可以Cache。<br />
3、但是要注意Cache实效问题（要及时标注实效），这个是个难点也是个重点。<br />
4、可以考虑用Message来标记实效（这样可以保证异步，无阻塞的按照顺序的让数据失效），据称也不是很难。</p>
<p>Messaging：<br />
1、混合应用。不用去看Java的OpenFire了，即使它很好，完全可以考虑erlang的ejabberd了，俄罗斯的产物。<br />
2、排队问题有很多解决方案：ActiveMQ、RabbitMQ、MySQL + Lightweight Locking、Drb（for ruby）</p>
 <img src ="http://www.blogjava.net/iamtin/aggbug/153144.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/iamtin/" target="_blank">Tin</a> 2007-10-16 08:42 <a href="http://www.blogjava.net/iamtin/archive/2007/10/16/scaling_twitter_the_key_points.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>