有 N 套房的飘过...都来鄙视我吧，可以结帖不？

#14 楼 @huacnlee 是在 Nginx 之前加 Haproxy 吧？在之间加没意义啊，我们以前是这样用的，那个项目是 Nginx+Passenger，不过 Unicorn 也一样： http://quake.iteye.com/blog/1313623

#6 楼 @zj0713001 正如#8 楼 @outman 所说，ruby2.0 开启 COW，内存使用还是可接受的，unicorn.rb 里面有这样一段：

# To save some memory and improve performance
preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
  GC.copy_on_write_friendly = true

另外我在主贴，补充了 2 个图，共 3 台服务器 (每台都是 2core, 4G，监控上显示 4 台，其中一台是内部测试的），每台开 6 个 unicorn worker，平均一个 200MB 左右，如果内存紧张的话，减少 worker 和 WorkerKiller::Oom 的内存上限，1G 左右的内存 +20% 的 CPU，很轻松一台就可以支持 200 RPM。

#9 楼 @ashchan unicorn 本身启动命令就是 capistrano 里面的 start 命令： "cd #{current_path} && RAILS_ENV=production bundle exec unicorn_rails -c #{unicorn_config} -D"

将他放到服务器的启动脚本里面就可以实现自动重启了。

你想多了，接触过的投资人从来没问过我们网站是用什么写的，人家真不关心这个...

#19 楼 @luikore 配置 Redis 用 LRU 就不用关心 expire 拉。

#11 楼 @jasl 不会返回 email 的 api，可以给用户随机生成一个

另外，你说的这个问题，devise 的 wiki 上已经提到过，可以翻一下 wiki 上关于 omniauth 集成的，password 是用随机 token，email 是从 api 获取。

另另外，通常我喜欢用 create!，提早抛出异常，而不是用 create 的返回值来判断

devise 不算复杂，花点时间看一下源码，特别是 models 下面的几个 able.rb，就能理解一下它为什么这么设计。对于掌握一个系统的用户登录，管理等基础设施来说，这点投资是绝对划算的。

在 FPS 玩家世界里面 RPG 明显是 rocket propelled grenade

一直在用 mariadb，无压力飘过

#9 楼 @robbin 看了 uncorn 的各种好处，再加上 passenger 非企业版本不支持平滑重启，所以换了 :)

#12 楼 @_samqiu 用 https://github.com/agentzh/headers-more-nginx-module 改的，好处你懂的 :)

服务器 nginx+unicorn 部署用 capistrano

好吧，还有 xss，sql 注入，我真是蛋疼浪费时间在这个网站上，这个是广告吧？

用 pagespeed 测一下，得分只有 30 多，连 js 和 css 都不响应压缩版本，其他还要提么？

改成校验 article 试试看：

belongs_to :article
validates_presence_of :name, :article

实在不行的话，只能自己写 validate 方法了

我有个朋友，鼻孔很大。在北京坚持晨跑，一个月胖了二十斤。

正则替换的解法：

"aaabbac".gsub(/(([a-z])\2*)/) {|s| $1.length > 1 ? $2 + $1.length.to_s : $2}

如果有机器资源的话，master/slave 是最好的 如果服务器是用 LVM，可以用 snapshot 都没有的话，推荐用 xtrabackup

1G 内存实在太小了，稍微复杂一点的 rails 应用，一个进程很容易就跑到 200M，还是升级一下内存吧，4G 是标配了。

没遇到过这样的问题，试试看换 memcache 的 client gem 到 dalli 看看，我记得 dalli 解决了 fork 导致的 socket share。

我承认有点蛋疼

json.cache! 这是 rails 4 json builder 自带的？没用过呢，之前用 cache 都是在 controller 里面用 caches page 或者 view 里面用 fragment cache，这个性能对比测试看上去是 cache 没生效的样子。

#15 楼 @aptx4869 cache 用的是 disk cache？生成的 json 内容是不是很小？换 memcached 或者 redis 试试看

#10 楼 @huacnlee 如果没有内存监控自杀的话，我发现在 gc disable 的情况，用 oob 内存会莫名暴涨，很奇怪。

#8 楼 @huacnlee 搭配文中提到的 unicorn-worker-killer，根据服务器的内存和 unicorn worker 配置数量调整一下单个上下限，我们的应用实测下来平均从 140ms 下降到了 120ms，效果还是很明显的

碉堡，我现在已经改入 Lego 的坑了，发现比 Arduino 贵多了，泪奔

#6 楼 @huacnlee 这样在用户请求的时候不会发生 GC，然后在请求完成后进行 GC，避免 GC 对用户请求时间的影响。

竟然和我们用的组件惊人的一致，unicorn，oob，memory killer，slim•••