Ruby on Rails 开发的 api,能支撑多大的日请求量,我知道不说硬件条件可能被喷,大家用 Ruby on Rails 开发的 api,已经上线的最大支撑了多大的日请求量?
basecamp 1800 rps: https://twitter.com/dhh/status/885599200746057728
shopify 80000 rps: https://twitter.com/dhh/status/885776244532551680
阿里云 4 core 8G, puma 4 workers 8 threads, 约 2100 rpm, 50-1000 ms/r avg 200ms, 每次请求都读写数据库的 api, cpu 几乎保持 80% 以上,load 都 4.x 以上。数据库不在同一台机。
newrelic 的数据,再优化一下,单机 50rps 以上应该问题不大。看需求做横向扩容,比如单机做到 50 rps,目标是 1000rps,那堆 20 台服务器呗。
补充一下,cpu 占有高跟业务有关,计算型的。另外还有几个 Sidekiq 在跑。可能阿里云的 cpu 配置也不高,在本地测试没这么高占用率。
大致系统是这样的:
[物联网设备] ---- [ Go 中心处理系统 ] --- [ Rails 业务系统 ]
Go 处理着几千长连接,占用的资源非常少,简单处理后转发到 Rails 业务系统。
Go htop:
Rails puma top:
API,简单点说就是一个 CGI 而已,你这样讲真的没有任何意义。
具体说来,不仅仅是上面各位提到的要看请求的时间分布,还要看业务场景,比如 IO 密集还是计算密集?相同硬件配置在不同业务场景下的表现可比性就很差了,而你什么也不说。
那我只能说,你看 Github 的请求量,我觉得,一定行的通。
人家已经说了是机器系统里运行 htop
的界面的截图。
没有用过 Linux 发行版吗?去试试吧。
htop
可以说是 top
的一种变种,默认会列出当前运行的系统各个 CPU core 的资源使用比例而不是所有 CPU core 的总资源使用比例。还有很多不同,比如列出同一个进程里的不同线程的信息而不是仅仅列出进程的信息,等等。
如果和 Python 比... Python 处理字符串比 Ruby 慢,然而也能支撑很大规模的网站。而且就算这个性能,主要花钱的机器也不是应用服务器...
你配置 4 个 worker 加每个 worker 一个线程,给你带来 cpu 使用率下降,request 处理变快了的原因是在:
你的 puma 现在只能同时处理 4 个请求。其它的请求在排队进入 puma。所以实际上并发高的时候只是在 puma 处理请求这块变快了 (同时处理 4 个,与同时处理 4*8 个,显然前者的速度更快),而有更多的请求因为在排队,导致用户从发送请求到响应花了更多的时间。