Apr
02
Filed under: Technologies
最近由于 P1.cn 业务的推广，我们的 rails application 在以下几个方面遇到考验，分享一下我们处理这个问题的方法。
1. rails performance
这方面的问题我们以从以下几个方面处理：
- rails 的相关 plugin 性能及差，如 acts_commentable ，去掉这类的 plugin
- 改变数据库结构，使部分数据冗余，如 nickname, 使数据库关联查询变少
- memcached: cache db query in memcached, use acts_as_cached, cached_model, QueryCache (like javaeye)
- action cache: action cache 所有show action
- fragment cache: 少部分 privacy 页面使用
2. db cluster
master/slave mysql database, 现在是 one master, one slave, 计划结合 MySQL Proxy 做 one master , multiple slave
3. distributed file storage
用户图片增长速度非常快，我们感觉到了 storage 的压力，这是个即将到来的问题，但我不确定使用哪种方式来分布文件存储，我了解以下几种方式，但没有应用经验：
- NFS (大部分人不建议使用)
- DRBD - raid 1, 没有使用经验
- mogile fs - 文档几乎没有
- SAN
4. Nginx + mongrel cluster or something else
我们现在使用的是 Nginx + mongrel cluster , 发现 mongrel 在处理时，如果发生了一次异常，后续的请求都会被阻塞。以下是我们的处理方式：
- Swiftiply event mongrel instead of mongrel
- more mongrel running on different servers
希望得到你更多的建议，谢谢。
Tags:
四月 3rd, 2008 at 8:07 am
图片存储建议用mogile fs。资料少可以找:)
四月 3rd, 2008 at 12:45 pm
nickname应该单独作cache而不是作冗余
冗余的话，nickname改变了怎么办，如果nickname不会改变，那更应该作cache了
你之前肯定是用db join的方法拿nickname，这是下下策
rails调优不应该跟db调优同一次处理吧，真正的瓶颈只有一个地方，多数首先是app，过了一段时间才回到db
而且db cluster的代价很大，还不如对程序优化了
印象中曾经看你的blog说你们已经在使用mogile fs了。怎么现在从新评估了？
除了性能其实成本也是一个问题
四月 11th, 2008 at 10:58 pm
说一下第4点
Thoughtworks的Rubyworks的stack里面用到了monit，他可以监控mongrel，如果阻塞或者内存超过一定数值就重启进程，可以参考
四月 16th, 2008 at 6:39 pm
monit 我也试用过，但有时一个mongrel死掉后，使用mongrel_rails restart 是不能启动成功的，因为会有残废的pid文件存在，需要手动删除，