部署 Rails 在高并发下的性价比

tangmonk · 2015年11月10日 · 最后由 losingle 回复于 2019年05月04日 · 8875 次阅读

现在有个项目,预计用户量在顶峰的时候会达到 10000 requests / few second

我计算了下,如何一个 request 需要耗费 0.1s, 那么单进程单线程的话 1 秒钟就只能处理 10 个请求。 如果用上 16 核服务器,puma 开启 16 个 process, 每个 process 开 10 个 thread, 那么并发数量只能达到 1600。(以上情况不考虑缓存)

那么这样的话大概 需要 10000 / 1600 = 6.25, 至少需要 6 台 16 核服务器,6 台 16 核服务的价格总共 7200 / 月。

这个价格也太贵了,这种 process/thread 的并发模型是不是太不给力了。

如果某个高频率的服务采用 Nodejs 的 event 并发模型,或者采用 erlang 的 actor 模型应该会有质量的提升吧。

那么问题来了, 7200/月 能雇的来 @bhuztez 吗? 逃.......... @bhuztez 请你保证不打死我。

#1 楼 @huobazi O(∩_∩) O~~ 真早

合适工具用合适场景!

高并发的部分建议抽出来单独用其他工具改写,例如 golang node.js

#3 楼 @huacnlee 站长达人,请问下 ruby china 的并发最高的时候能达到多少呢?

#5 楼 @tangmonk 顶多 50 个/s

所以你想太多了,10000 个/s,什么样的应用有这样的场景

#6 楼 @huacnlee 是一个游乐园,他们人流量在节假日大约有一万多人

#7 楼 @tangmonk 不是那样计算的

#8 楼 @huacnlee 哦哦。。那是我随便估计的。 现在想想他们并发最高 1000 已经很不错了

改了语言不考虑改架构是耍流氓啊,也无非是把语言层先跑死换成后端数据库一类的服务先跑死.

就算节假日,人都是分批到来,那么做好 cache,后台队列,应付 1000/s 还是很容易的.做的一个 laravel 站,每天万 pv 访问,双核,2G 内存,都跑不满,是你太高估同时访问的人数了。而且 laravel 的并发比 rails 还要差点...

#11 楼 @yzdel2000 很多地方都是实时的, 能做 cache 的地方很少

#11 楼 @yzdel2000 我这儿只有 1 万多 ip,更多的是活活被爬虫跑死,700 万左右 http 请求/天。关键是做缓存没用,爬虫是挨个页面爬的,一个页面只爬一次。

@nine 是不是可以考虑在 nginx 层把来自爬虫的请求集中导入到一台廉价的、慢的后端服务器上

15 楼 已删除

#14 楼 @psvr 那爬虫会判定页面打开太慢,体验不好,而把搜索排名降低。。

你想多了 3g 内存 2 核 ssd 磁盘, 日 ip8w pv70w 毫无压力 laravel

有人分享过 “屌丝如何日访问量一百万” 的演讲,你可以找找视频。

这是 PPT:屌丝程序员如何打造日 Pv 百万的网站架构

#9 楼 @tangmonk 按你的访问量,估计连 1000 request/second 都达不到。

可以先把云主机加到 6 台,看一下 newrelic 中的流量,观察一两周,然后根据流量调整实例的数量。

数据库瓶颈也是一个问题。

10000 人每天的游乐园,撑死 1 个小时内到齐,每秒 3 个请求好么才。

10000 人每天的游乐园,撑死 1 个小时内到齐,每秒 3 个请求好么才。

可能游乐园有广播,某时某分有抽奖,倒数十秒一起抢。

当开始数 10 的时候,楼主心跳开始加速

游乐园搞个活动 7200 / 月不算高,你可以预算里面报 12000,还赚 5000 呢。。

10000 qps 这还是挺吓人的,你不用 20 台服务器还真的顶不下来。 手头一个每天 IP 六七万的网站,每秒访问也才两三百,一个 VPS 就能吃下了。

到了 10000 qps 的话,每个月多掏 1 万根本不算什么,如果开公司的话最起码百万疯投拿好了吧?

在讨论问题之前,先需要确定 0.1s 里面 cpu 耗时是多少,不然没有意义。

就你给出的描述,有一个点问题: puma开启16个process, 每个process开10个thread 并发数量其实只有 16*10 = 160,单位吞吐量 (/秒) 才是 1600 .

假设如果你的是 IO 密集型应用 , 比如 100ms 里面 20ms cpu, 80 ms IO (2/8 定理), 在这种情况下单个进程最好的线程数量是 100/20 = 5(因为多了没有意义), 这样你的并发又减少到了 16* 5 = 80,单位吞吐量 (/秒) 才是 800 ,再根据常见的用户可忍受的等待时间 3 秒为例,你可以同时接 800*3 = 2400 请求。

接着如上假设,根据你的数据 10000 requests / second(持续一段时间),在这个高流量来之前,确实必须需要 > 10000/ 800 台机器 . 但是你可以使用云主机,实现弹性扩容,按时收费,这样整体便宜不少,例如青云,非高峰期保留两台主机即可。

#27 楼 @small_fish__ 多谢大大指教,但有几点疑问

  1. 关于 2/8 定理不太清除,查了下是关于财富分配啥的。。
  2. 100ms 里面 20ms cpu, 80 ms IO (2/8定理), 在这种情况下单个进程最好的线程数量是 100/20 = 5,为什么要 100/20 呢?
  3. 如何判断一次请求 CPU 的耗时和硬盘的耗时呢?

#28 楼 @tangmonk

  1. 2/8 只是做个假设,具体项目中,cpu 和 IO 耗时可以通过 Rails 日志每个请求时间估计出来。
  2. 100/20 = 5 是因为 20ms 是 cpu 时间,那么一个 cpu 在 100ms 里面,最多 5 个 work 可以利用,如果超过 100ms, 已经有 work 将上个任务处理完成,空闲出来了,又可以处理请求,这个只是大概数据。

每秒 10000 个请求,一小时就是 3600 万个请求,往小了说,一天 3600 万个请求吧,这多少用户,养活一个几百人的公司都没有问题,还差个几千块啊。

kevinli 回复

看业务场景呢,我一个项目还 4W QPS 呢

但是还养不活 10 人的团队呢

还得想办法节约机器和流量成本

从 passenger 到 puma,然后换到了 nodejs 😪

需要 登录 后方可回复, 如果你还没有账号请 注册新账号