• 相当不错的工具

  • 一个请求要 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 采样一下每个命令的执行时间

  • 接口的功能粒度 at 2016年01月11日

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

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

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

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

  • 关于发送短信的问题 at 2015年12月15日

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

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

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

    我没有试过 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)
    
  • Ruby 微信开发群 at 2015年12月09日

    已入

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

    ulimit -n
    
    

    再看看 TCP 的连接数

    netstat -nap | grep tcp |wc -l
    
  • 存在内存泄露的 Gem 列表 at 2015年10月21日

    6 中三

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

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

  • 。。。这算黑吗??? at 2015年10月08日

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

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

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

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

  • HR 该不该这样做 at 2015年09月15日

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

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

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

  • groovy 的脚本有漏洞,要小心哦

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

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

  • 民间借贷的问题 at 2015年08月11日

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

  • Rails 到底该选择什么 server at 2015年08月11日

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

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

  • 我们为什么会选择 Golang at 2015年08月10日

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

  • 北京好多拆迁的 at 2015年08月01日

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

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

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

  • 为什么要做 Rails Girls? at 2015年07月29日

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

  • 点赞,回去玩玩看

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

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

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

  • 验证代理端是否有效? 你要是:

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

    吗?

  • 想做同学录,求思路 at 2015年07月14日

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

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

    除非用非关系型的

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

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

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