BlogJava-Tin's Blog-随笔分类-扩展与调优

Re:架构考量-选择的难度

Tin — Wed, 28 Nov 2007 14:39:00 GMT

在中文网织年会上和啄木鸟老大HD讨论了一下好看簿的架构问题，而后老黄写了一个blog entry：
架构考量-选择的难度
里面谈到了架构一个高支撑能力的Web 2.0应用需要考虑的架构选型问题，对我很有帮助。我也回复一下他的建议：

非常不好意思，今天检查google reader才发现HD老大记录了这个谈话。而我都没有在blog里面记录这个事情。不过和HD老大的谈话回来我还是仔细消化了一下。关于交换机的事情我已经反思了，后来在切换服务器的时候的确发现了百兆和千兆的区别，rsync在百兆网络下的确造成了我们的切换宕计时间变长。当时我们停止服务15分钟，如果是千兆网络估计5分钟以内就可以了，所以如HD所说，我们也许应该选择HW的千兆。
关于文件服务的问题，我想目前的关键还是需要看看是否有热点数据。不过对于网站来说，由于首页和离首页深度比较近的页面被访问的可能性要明显的高，所以如果使用squid做反向代理肯定可以减轻静态文件服务的压力。但是问题也在这里，一定要流量对静态文件有压力的时候再加Squid。
其实本次切换的主要问题是将动态服务与静态服务分开。因为没有选择纯磁盘阵列用光纤或者iSCSI的方式挂在到动态服务器（因为原先的2950充当了文件服务器），所以为了不浪费计算资源我们将动态服务器（8G内存，Raid1和15k rpm硬盘）和静态服务器（8G内存，Raid5和750G X 6的7200 rpm硬盘）分开处理，这样动态服务器跑Django，静态服务器跑Lighttpd。他们之间只需要一个读写的通讯，因为是内部通讯，所以用http是没有意义的。用NFS可能是最直接的方法。用SAN或者iSCSI的方式其实也是可行的，前者是成本问题，而后者是浪费计算资源的问题，所以我们自然的按HD的意思上了NFSv4。
然后又引出MogileFS的问题。其实这是个大文件存储的真谛问题。如果数据量达到一定程度，单个节点不可以承受的时候，那么我们只能选择数据分片，可以时髦的叫做shard，如google做的map reduce的GFS。或者干脆就自己写个简单的数据索引，然后路由分区一下，这个概念就是MogileFS。MogileFS就是利用多个有自己的计算资源的静态服务器来分区存储并管理它们的一个准分布式文件系统（因为MogileFS不支持随机访问，只是整存整取，所以说是准文件系统），它已经能解决我们Web 2.0应用的问题了，Flickr也是这么干的……选用它或者自己做是个看起来和做起来都挺简单的问题，只是它比什么都不需要改变的NFS还是稍微麻烦一点。所以这个作为未来的一种被选方案。其实呼应一下HD在方案分析里面说的应付流量压力的目标，MogileFS只是用来解决存储压力的一个方式。
关于FS，我最近也作了Research，发现这还真是一个坑呀，非常大的坑。XFS、JFS、nb的ZFS都是好方案，但是大文件系统还要考虑分区表格式，MBR已经成了限制，用GPT吧你还不好引导（因为如果你都是大硬盘的话，单弄一个小的上MBR引导，其它再分GPT，势必要浪费一块硬盘，非常不划算），然后LVM解决引导问题吧用起来还不踏实（毕竟它的条带化不是硬件的Raid那样可靠），然后你又需要去对比那几个FS，反正头大。最后还是硬着头皮上了XFS。
我觉得架构考量就像HD所说的，你有无数选择，这些选择造成了噪音，然后在你四处碰壁的时候，你可能选择了第一个可以用的方案去实施。而实际上你会很快发现更好的方案……架构的重构代价是可怕的……所以有了更好的方案可能也不会实施，或者要很久以后再实施。所以，这个经验是需要年头的，也许，也许，很多的方案都让被实施者称为了学徒练手的冬瓜，脑袋上的伤口只有冬瓜自己知道。虽然我作为学徒……看着也疼。我发誓，下次我一定做到更好！

相关的好看簿故事，我把好看簿服务器升级的过程用照片故事的形式记录下来了，欢迎大家参观：
http://www.haokanbu.com/story/2991/

还有关于中国网志2007的记录
http://www.haokanbu.com/story/3022/

Tin 2007-11-28 22:39 发表评论

如何安装Siege并进行测试

Tin — Wed, 24 Oct 2007 05:52:00 GMT

如何安装Siege并进行测试

在CentOS 5上面的过程。其它系统安装方式略有不同参照它的官方网站。

安装siege

yum -y install siege

配置siege

运行一次siege，它会在你的~目录创建一个.siegerc。你可以在里面修改你需要的东西。里面有说明，可以自己修改。需要说明的是里面有一个benchmark的属性，为false。siege不同于ab在于测试并发的时候请求也有个随机延迟，这样比较接近实际效果。

运行siege

一般用法：

siege -c 100 -r 10 -f someScript.url

-c是并发量，-r是重复次数。 url文件就是一个文本，每行都是一个url，它会从里面随机访问的。

类似ab的纯并发压力测试：

siege -c 100 -r 10 http://www.google.com

手册在此，因为siege很早就有，命令语法也变了很多，要么直接man siege，要么就看官方手册： http://www.joedog.org/Siege/Manual

== 关于sproxy === sproxy是用来录制siege脚本的代理工具。可是我没有在CentOS上调试成功，需要自己编译安装。好处是方便模拟post请求和cookie等，但是目前没有用到。 http://www.joedog.org/Sproxy/Manual

Tin 2007-10-24 13:52 发表评论

Twitter的性能调优的关键点

Tin — Tue, 16 Oct 2007 00:42:00 GMT

Twitter的水平扩展的一些关键点，虽然它是个RoR应用，但是这些建议绝对是放之四海而皆准的，非常好的总结。
因为年初Twitter曾经遇到了性能瓶颈，而且几乎束手无策。当初很多人开始怀疑Ruby的性能问题，而后Twitter站起来了 ^__^

有时间的朋友看看这个slide：http://www.slideshare.net/Blaine/scaling-twitter，没有时间的看看我的摘要。

开发：
1、一定要测试！一定要早点测试！一定要早点测试！否则你就死定了。不要存任何侥幸心理，从项目的开始就写好测试。
2、对任何部分都要测试。还是测试！
3、性能测试要交给用户来做。那样才有意义。所以要做好log。用好分析工具：Munin（服务器内存占用监控）、Nagios（服务器服务网络状态监控）、AWStats & Google Analytics、错误日志、发现了错误马上进入问题跟踪系统（Trac、Jira……太多了，但是最好有一个）。

架构：
1、使用可以分区的架构。按照架构上的功能清晰的分区。这意味着你可以通过替换一个实现来改进性能，因为性能和复杂度往往是不可兼得的。

对于数据库：
1、尽量不要分布式数据库，包括数据库分区。最好通过提高单台服务器的性能提升这个节点的性能。更重要的是查询优化。通过备份服务器解决单点故障。
2、对where子句中的字段增加index。（这个当然了）
3、扁平化查询，比如一个user有很多朋友，查一个人的朋友如果通过外键会浪费很多性能。可以把ids序列化为1,2,3这样，然后用like查询速度更快。
4、一定要优化你的SQL，不要寄希望于ORM给你解决（不管是DataMapper、ActiveRecord或者UnitOfWork）。

Cache：
1、一定要考虑Cache，最重要的是领域对象的Cache，一定要考虑Memcache，如Memcached。
2、应该有90%的查询可以Cache。
3、但是要注意Cache实效问题（要及时标注实效），这个是个难点也是个重点。
4、可以考虑用Message来标记实效（这样可以保证异步，无阻塞的按照顺序的让数据失效），据称也不是很难。

Messaging：
1、混合应用。不用去看Java的OpenFire了，即使它很好，完全可以考虑erlang的ejabberd了，俄罗斯的产物。
2、排队问题有很多解决方案：ActiveMQ、RabbitMQ、MySQL + Lightweight Locking、Drb（for ruby）

Tin 2007-10-16 08:42 发表评论