相当不错的工具

一个请求要 500ms 就和 rails 框架没有关系了，因为正常的 rails 返回也是几十 ms

可以在一两台机器上采样看下时间消耗在哪个方法上。

如果在 redis(看你程序的流程好像也没有别的地方可以出问题了)

你如果是用云的 redis 集群，他上面应该有监控，看下负载情况如何

redis 的 slowlog 里面都是什么？(slowlog 没有开开一下，2w rqs, 0.1ms 对你来说都是慢查询了，这还没有计算你一个请求有多个 redis command)

比较好解决的情况就是有人误用 keys 这样的操作，去掉就好了，正常就不应该这么用

这问题可能一眼就能看出来

比较麻烦的是 rang 这种 O(S+N) 的命令，在 slowlog 里比较难找出来

这种就考虑尽量改成 O(1) get set

建议使用 datadog 这种 statsd 采样一下每个命令的执行时间

开放给第三方就给两个，要求灵活，稳定 开放给自己的 app 用，就给一个，要求请求少

ruby 元编程，就像暗黑法师 30 级会瞬移

他不会帮你打倒敌人，但会助你冲突难关，关键时刻救命

再说了，职场上，装得一手好逼，也是个 big plus

把参数拼写成文件，然后用个测试工具发出去，强大的工具能还记录一下结果

说实话，这个问题我也没有去做过

但是如果这是面试题，我想正确应该答案是：

我没有试过 map 和 map! 的性能问题，因为我觉得这两个性能差别应该不会太大，但是我对 Ruby 应用的性能问题很关注，但我觉得这样的测试只要关注别人的测试结果就足够了，关注业务逻辑优化或数据库优化的性能可以得到更多的性能回报

require 'benchmark'

array = (1..10_000_000).to_a

Benchmark.bmbm do |x|
  x.report("map") { array.map { |e| e } }
  x.report("map!")  { array.map! { |e| e }  }
end

Rehearsal ----------------------------------------
map   10.520000   0.500000  11.020000 ( 11.600892)
map!   9.500000   0.220000   9.720000 (  9.803323)
------------------------------ total: 20.740000sec

           user     system      total        real
map   10.260000   0.430000  10.690000 ( 10.838827)
map!   9.510000   0.090000   9.600000 (  9.727683)

已入

因为你有第三方请求，所以可以看一下连接数

ulimit -n

再看看 TCP 的连接数

netstat -nap | grep tcp |wc -l

6 中三

做为程序猿，摸电脑的时间比摸女朋友的时间还多 有什么理由不买个"漂亮"点的 mac 其实就是胸大，腿儿长，脸蛋又漂亮的那个

只是如果你说"浪费"这点来说，mac 是性价比最差的笔记本，没有之一 linus 都用 mac 来做日常工作

互联网项目要是先考虑这些，设计完数据库，黄花菜都凉了

Rails 就像是自行车，这个问题就像是家里是不是要买辆，有经济实力的，一开始就奔驰宝马没问题

但钱少的，还是先买个自行车好了。甚至你说自行车不能跑长途怎么办？需要的时候再买个好车呗

Rails 其实上解决了没有钱买奔驰宝马但又要近距离出行的问题

到手的少，你应该高兴才对

现在的市场是 Java 需求量最大，会的人也最多，中低端很 low OC 需求量大，会的人少，中低端就也很吃香，很容易高薪 Ruby 这块小众，人少活多饿不死

但不知道你出来后的世界又变成什么样了

groovy 的脚本有漏洞，要小心哦

也可能是 thin 的 em 机制造成的，我以前有程序用到 em，在 rainbows 或是命令行下都没有问题，一到 thin 下就卡住 可以试下别的服务容器，puma 什么的，都很容易跑 sinatra 如果别的可以，那可能是他的 em 和你写的 em 代码哪里冲突了

sinatra-synchrony 的坑就写在 github 项目主页上了

民间借贷，月 2 分是正常的，法律支持最高是 3 分，所以年息 20% 不算高

其实用 passenger_max_instances_per_app 就好了，免费版本够用的 大部分主流的 server 我都用过 rainbow/puma/thin/unicorn 但我上一个用的是 passenger，免费版本。 线程类的没有 server 没有想象中的那么好，可靠性不高。经过压测，综合性能和可靠性，我选的是 passenger

现在的公司用的 unicorn，性能和可靠性还没有发现什么特别的问题，就是不能 touch ...

我前面一个项目在遇到性能问题的时候，也是用 golang 来解决的 中间尝试 puma/thin/rainbow 等等，大小坑无数 em 在纯 http 相关的性能不错，一但有数据库连接，就坑无数了 最近的高并发语言里，我就会点 golang...所以就选 golang，效果相当不错

我已被刷，并不知道 Rrails 是个什么鬼......

大意就是你用的字符集是 GBK，但你的那个文件不是 你把文件转成 GBK 就可以了

自家电脑...一直用的自动登录

我记得 rails girls 的 girls 定义是初学者...不是真的 girls 当然是 girls 更好

点赞，回去玩玩看

当然是联合索引快，两个单索引如果都用到的话，过程是符合两个索引 的记录都找出，然后合并，而联合索引只会在这个联合索引搜索，结果直接返回

但单索引的应用范围更广，因为他可以由应用端来指定组合

联合索引适用于一些已经稳定的用得很多的查询的优化，毕竟你不能改个条件就去改一个联合索引

验证代理端是否有效？ 你要是：

delegate :nickname, :to => :user, allow_nil: true

吗？

你的业务模型里都是带一个像 class_id 这样的元素，所以你的你模型里肯定 也是带有这个的

起码在传统的关系型数据库里没有办法避免

除非用非关系型的

班级可能做为一个命名空间一样的东西，这样就会很干净了

是因为你取出来的对象是 nil，就是没有取出来

wiki 里有怎么部署，你那个只能叫开个端口来看看