性能扩展问题要趁早

与国内的 Web 2.0 Startup 技术人员相比,国外技术人员更乐于分享。分享也是一种更好的宣传手段,如果不是看到了这篇 Scaling an early stage startup, 或许我就不会知道这位 Mark Maunder (他还有个中文名字:马孟德) 以及他的 FeedJet

一般来说,一个刚刚发布的 Web 应用,因为用户量并不多,性能问题可能并不是很明显。可一旦宣传展开,用户增长或许不是线性的而是暴增(从几十个到几万个,相比之下怎不是暴增?),这时候如果遇到性能问题,毫无疑问会影响初期用户的信任。

Maunder 文档中列举了一个扩展过程,相信这些例子也是他实际遇到的。毕竟 Startup 都是一两个人打通关,不可能所有技术都面面俱到的精通。下面记录一点。

错误的设置

数据库服务器的参数配置问题:导致 MySQL 消耗了大量资源。Apache Keepalive 的设置为不合理,修改为 off。我想这个前提应该还是要选择自己最擅长的技术路线。如果错误的选择另一条不熟悉的技术路线,那么遇到技术时解决问题的速度怕是更让用户恼火。对于 Apache 还应该知道 Httpd.Worker 比 Prefork 消耗更多内存 (httperf 来进行 Benchmark) ,内存也是蛮贵的。

尽可能的缓存动态内容

尽可能的利用数据库的 Cache,利用其他 Cache 工具,如 MemCacheD,来减轻对磁盘的 IO 压力。为了节省成本,很多站点都是用的低速大容量的磁盘,所以,充分利用 Cache 是一个网站成功的必然条件。这样的软件BerkeleyDB 的最高事务处理记录是 90000 事务/秒。

剥离图片与CSS 到单独的服务器

说白了,也是为了减轻磁盘的压力。现在很多 Web 2.0 站点都把图片放到 Amazon S3 上,省心了不少。当然,国内还没这样的服务。

阻止内容引用”窃贼”

现在连那些大站点都在阻止图片被第三方引用,小站点更要提防被大站引用,很容易耗光网站的容量。另外一个要注意的是网络爬虫的频率。

在线观看这篇 Scaling an early stage startup。顺便说一下,最近在 Scribd 上看到了不少有意思的文档。

EOF


  • http://dotimes.com Cherife

    在开发前期就该考虑
    重构的代价可不小

  • http://www.dbanotes.net/ Fenng

    国内 Web 2.0 站点很少有人能够打通关的。所以或多或少会存在技术缺陷……

  • http://www.anysql.net AnySQL

    前期有资金和人力投入此事吗?

  • wenshu

    我也觉得前期就应该考虑,起码要想到扩展的方向,保证不犯方向性错误。

  • wzp8880

    刚开始接触网站架构,认为初期考虑网站架构的发展方向,应该知道一些著名网站的架构重构历史,为将要开发的程序架构的设计做参考