• 如果没有复杂业务逻辑和需要一些第三方gem的,只是对redis的操作,这个业务场景没必要用rails,单纯用grape这个框架都会性能倍升,并还是在ruby这个语言scope内。而rails的光是启动一个实例就加载上百个Initializer策略(实测130个),楼主描述的场景(完全实时查询)rails提供的很多缓存策略都用不上,有力使不上劲的感觉,一开始框架选型就不妥了。

  • Rails 5.1 add delegate_missing_to at 2017年07月21日

    这个就是 draper 的delegate_all 实现,而draper就是装饰器模式的典型使用场景

  • DHH、林志颖、韩寒三大跨界开赛车的男神

  • before_create do
      article.increment!(:likes_count)
    end
    

    这个已经改变了业务逻辑:先累加赞,再添加赞记录。

    一个思路是把这类计数器累加操作可以放入队列里异步、顺序执行。

    另外我的使用counter_culture+pg 经验中发在多线程高并发时,累加值容易互相覆盖,最好还是定时或在某些callback再call 一个update_counter_by_counts

  • Rails 与 Django 性能的疑问 at 2017年05月19日

    有意义的,意思就是如果你打算做很care性能的产品,就选py驱动的框架;如果很care能否快速实现、需求变化频繁、组件丰富拿来就用、care开发人员情绪的,就顺便考虑下rails

  • 说起CI时间的话,想起4年前的一个rails项目,CI上跑一次完整回归大概5个多小时

  • 楼主也叫Rain?缘分

  • Rails 最佳实践 - 定时任务 at 2017年01月19日

    赞同楼主,crontab在多实例部署就有容易有问题,另外无重试、统计,精度到分钟级别,顶多算个触发器,是比较粗糙的解决方案,不过也能解决80%的早期项目需求。跟sidekiq结合是不错的实践,可充分利用slidekiq的重试、统计。

  • #6楼 @kgen 分析帝跪了 ORZ。实际情况是为了赶在元旦前发布,数据收集是在假期最后一天的下班前收集的(第一条提交数据时间:2016-12-30 17:41:54, 而我们6点下班),实际数据收集不是全的,不过作为抽样可以用来参考一些问题了。

  • #5楼 @freefishz 那个是163的数据,没有错