现在有个项目，预计用户量在顶峰的时候会达到 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 模型应该会有质量的提升吧。
就算节假日，人都是分批到来，那么做好 cache，后台队列，应付 1000/s 还是很容易的。做的一个 laravel 站，每天万 pv 访问，双核，2G 内存，都跑不满，是你太高估同时访问的人数了。而且 laravel 的并发比 rails 还要差点...
#11 楼 @yzdel2000 我这儿只有 1 万多 ip，更多的是活活被爬虫跑死，700 万左右 http 请求/天。关键是做缓存没用，爬虫是挨个页面爬的，一个页面只爬一次。
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__ 多谢大大指教，但有几点疑问
- 关于 2/8 定理不太清除，查了下是关于财富分配啥的。。
-
100ms 里面 20ms cpu, 80 ms IO (2/8定理), 在这种情况下单个进程最好的线程数量是 100/20 = 5，为什么要 100/20 呢？ - 如何判断一次请求 CPU 的耗时和硬盘的耗时呢？
- 2/8 只是做个假设，具体项目中，cpu 和 IO 耗时可以通过 Rails 日志每个请求时间估计出来。
- 100/20 = 5 是因为 20ms 是 cpu 时间，那么一个 cpu 在 100ms 里面，最多 5 个 work 可以利用，如果超过 100ms，已经有 work 将上个任务处理完成，空闲出来了，又可以处理请求，这个只是大概数据。
每秒 10000 个请求，一小时就是 3600 万个请求，往小了说，一天 3600 万个请求吧，这多少用户，养活一个几百人的公司都没有问题，还差个几千块啊。
kevinli
回复
看业务场景呢，我一个项目还 4W QPS 呢
但是还养不活 10 人的团队呢
还得想办法节约机器和流量成本
从 passenger 到 puma，然后换到了 nodejs 