快速冲锋步

December 24th, 2008

快速冲锋也有节奏。把节奏记下来，下次可以改进。这就是泰勒在伯利恒钢铁公司做过的事。

  1. 愿景（1小时）：我要做个东西，要快。也许应该试试用Rails做？因为它很快。似乎没有特别的原因阻碍用Rails？是的，没有。
  2. 空谈（1小时）：它好像是个什么东西。它看起来有点像Mephisto吗？呃，Mephisto是什么？你看，我用Mephisto做了我的blog和AgileChina的网站。不错，看起来有点像。
  3. 部署（3小时）：给我服务器，我把Mephisto架起来。没问题，连域名都给你。
    1. Rails 2.2在Windows上不好使，因为MySQL gem的原因，也许应该装Ruby version而非win32 version
    2. 在Windows平台使用Apache2.2和Mongrel运行Ruby on Rails
  4. 原型+反馈（3小时）：现在你可以添加内容了。管理后台和我想的不一样。我们可以定制Mephisto。定制是一堆破事，重做也是一堆破事。你让我想想。
  5. 抛弃（30分钟）：现在我基本上知道你要什么了。我决定重做。
  6. 堆砌（2小时）：插件，generator。我知道所有的convention。没有测试。我要看到第一个页面，让我可以部署它。
    1. 第一个model不是User，而是核心概念
    2. 第一组数据写进fixture，直接load到产品系统
    3. 第一个migration叫做release_1，不允许回滚
    4. 第一个build脚本就用上svn.rake
    5. 用TODO文件来管理storys/defects/unknowns
  7. 再次部署（30分钟）：尝试过Mephisto，现在我知道该怎么部署了。
  8. 反馈+小步前进（6小时）：好像可以发布内容了，酷。用户权限我是这样设想的。能不能这样简化？以后我们可以这样去改变。可以，我们可以先控制邀请。
    1. 给build脚本加上stats：我允许现在测试覆盖率低，但从现在开始它必须一直提高
    2. 每次代码修改开始加上测试，因为我开始记不清每个细节了
    3. 没有Selenium
    4. 每个story完成后立即部署
  9. 发布+反馈（1小时）：告诉我一个帐号。quentin和admin都可以。我添加了一些东西，有些更多的想法。TMD…我本来没打算发布的。看在你费劲的份上，就算我发布了吧，现在开始不再清数据库。
    1. 新的migrations：每个migration只做一件事，每个migration都可以rollback。
  10. 继续小步前进（6小时）：SMTP server帮我搞搞好。80端口给我。我收到邮件了。80端口腾出来以后我再改Apache配置，共计需要删掉4字符。
    1. 界面的手工验证开始变多
    2. 复杂的业务逻辑出现，借用了上一个项目的经验，还是出了一点tricky的错误，耗时30分钟

从周六开始，共计5天业余时间，或换算成3个工作日。

Posted by gigix Filed in
33 comments »

Mongrel的内存占用确实成问题

December 14th, 2008

2 sets of configurations:
  • A. 20 mongrel instances * 300MB memory limitation for each
  • B. 10 mongrel instances * 512MB memory limitation for each
Findings without surprise:
  • with config A, total memory usage is about 6000+MBytes
  • with config B, total memory usage is about 4000+MBytes
  • in normal cases, the momory usage of each mongrel instance is about 400MBytes
  • for operations with light calculation, config A is generally faster than config B
Findings with surprise:
  • for operations with heavy calculation, config B is more efficient than config A when load (amount of concurrent users) grows
  • more importantly, config B performs more consistenly than config A
    • config A fails 2 test cases for 15 concurrent users, and the possibility of failure grows significantly to 5.57% for 20 concurrent users
    • config B doesn’t fail any test case
    • the degrading curve of performance of config B is flatter than config A
Conclusion:
  • besides the memory usage, CPU usage is yet another bottle neck of performance
  • 20 mongrel instances on 1 server overloads the CPUs, and thus degrades the performance
  • reducing the amount of mongrel instances makes HAProxy works as a queue, therefore makes the system performs linearly
Suggestion:
  • prefer config B than A: 10 mongrel instances on each of 2 production servers can handle 20 concurrent users, which (based on my experience) effectively means at least 1000 users online AT THE SAME TIME
  • try config C (15 mongrel instances * 400MB limitation for each) and D (5 or 7 mongrel instances * 512MB limitation for each), IF NECESSARY
Posted by gigix Filed in

HAProxy -> Mongrel -> Rails

April 24th, 2007

这是一个高性能、高伸缩性的Rails部署方案。有一组性能数据可供参考。

首先接收到HTTP请求的是HAProxy。HAProxy会把请求反向代理给其后的多个Mongrel实例。每个Mongrel实例同一时间只处理一个请求。只要Rails应用本身贯彻无共享架构，就可以直接通过增加服务器和改变HAProxy配置得到线性的性能提升。另外可以用Monit来管理Mongrel实例的开启和关闭，并且在异常状况发生时及时采取措施。这样一来，企业级超复杂所暗含的性能、伸缩性、可管理性等等要求都满足了。

“HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications.”
“Mongrel is a fast HTTP library and server for Ruby that is intended for hosting Ruby web applications of any kind using plain HTTP rather than FastCGI or SCGI.”
“monit is a utility for managing and monitoring, processes, files, directories and devices on a UNIX system.”

（今天下午和George讨论的主题：我们已经听厌了“企业级”这样的大帽子。我们需要做的是弄明白所谓“企业级”究竟代表什么，然后把解决方案拿出来。基本上——如果真的喜欢“企业级”的话——这就是所谓的“企业级Rails”了。）

Posted by gigix Filed in