• 服务本身应该还好 m$ 对中国市场还是很重视的 gov 不是还拿到了windows 的源码么 主要是墙高了 或者国家从安全层面考虑 要求私有代码必须落地国内

  • 在我举的例子当中, 当进行数据库事务的时候 本机的 CPU 是闲置的状态, 这个时候切换上下文是会提高cpu 效率的, 而这种情况的变种我觉得还经常会发生(瓶颈在数据库). 所以我会对您那个公式有点不同意见

  • 简化一下情况

    假设运行后端的服务器只有1核的CPU

    之后开一个 PUMA , puma 跑20 个线程,

    现在有大量数据库事务的任务,每个事务执行需要1s,

    再假设除了执行数据库, 其他操作小于1ms 的响应

    如果pool的大小是2, 那么是不是此时就只能并发两个请求?

    是否能等效理解为 在执行事务的时候, 此时服务器的cpu 是空闲状态, 但是却因为数据库连接池的问题不能进行服务?

    如果此时连接池开到20, 将puma 的线程池满

    似乎就可以进入20个并发了

    或者我的理解有问题, 有一些概念上的错误?

  • 这个线程池个数设置方式 应该比较靠谱.

    特例是, 在puma 的一个 thread 里并行用到了一个以上的连接. 但是似乎我也没想到这种情况的场景.

    而且算法是在 puma max threads的情况下的, 一般压力不会那么大

  • 看上去都是数据库?

    加大点 pool 比如 30 - 50 试试 ?

  • 😆 不能老让小姐姐们玩 postman 不是么......

    最后还是决定牺牲一点性能, 在 rails-api 上 继续写传统 view, 复杂点的就 webpacker react 跑一下凑凑热闹

    在pv 没到10m 之前 性能损失在20% 以下都还能接受

  • 我试试 @kayakjiang

  • 理论上你可以让puma 承担所有工作, 只是说 puma 是基于 ruby 的 , 效率没有基于 nginx 的高

    比如你开一个puma 进程, 进程再跑20个线程

    但是很有可能你一个网站就有超过5个静态资源, 之后只要有4个访问并发, 你puma 的线程数就占完了, 新访问就没办法进来了

    而nginx 首先在处理静态资源的情况下效率就比puma 高很多, 对 wait 的处理也非常好, 对于静态资源, 几千个并发随便来,

    同时就算puma 资源耗完了, nginx 也可以先将连接进入wait 状态, 等待 puma 可以接受新资源了, 再进行转发

    再就是一些跟网站本身没有多大联系的功能, 比如 SSL证书, 或者多个网站部署到同一个ip 等等, 要说用puma 可以不可以实现, 也可以, 但是复杂性大大增强了, 耦合性也急速的膨胀. 然而对于这种东西, nginx 处理起来驾轻就熟, 直接上配置就好了

    总结下来, 就是专业的事情, 专业的工具来干. 用螺丝刀也可以钉钉子, 但是如果有锤子, 还是上锤子比较好

  • 邮件写的已经要delay了

  • 印象中猎聘是在八里庄那边 没想到也是用的 rails 啊