瞬间 6000 的请求？

是的。。差不多就是这个数值吧。。在这个区间的样子。。。

并发取决于几个因素：

1. 单个请求的时长
2. 业务能接受的处理时间
3. 有没有资源争夺
4. 有多少硬件算力

那你们老系统什么配置可以撑那么多？

同一个操作

什么操作？读还是写？是同一个数据还是不同数据？

系统是负载的，有 3 太服务器跑。都是 8 核 16g 内存。。数据库另外的服务系统， 同一时间检索同一数据表做查询。。跟插入。。， 现在老系统已经不行了。。

单个的处理速度还是很快的。。

信息太少了，不同的业务场景差别巨大的，例如插入是插入什么是并发插入，还是个别的。

或者说那些并发具体是写什么东西。

同样的业务 Java 顶不住，换 ruby 只能加更多的服务器，虽然代码简洁但是成本并没有降低，Ruby 处理这个场景没有比 Java 更好的性能优势和成本优势。

如果需要实时处理建议用 golang 重写或在 Java 基础上再优化，否则如果不需要实时可以考虑 sidekiq golang 版去处理

不要认为说单个请求的响应足够快好了，并发的时候和你单个请求的时候完全不一样的，会有很多问题。

例如：

1. 资源是有限的，你得有足够的机器处理能力
2. 决定 Rails 应用程序吞吐量的是 (Response Time * 进程/线程数量)
3. 并发来的时候，处理不当，造成锁，例如同时修改数据库一行的数据，同时修改一个文件等等

换框架，换语言不能解决你的问题，一样做不出来，你们需要一个有经验的架构师

先定位问题，才能解决问题，找到吞吐量上不去的瓶颈在哪里

这需求我觉得还是 java 靠谱，虽然最靠谱的是人。

无法满足要求，你们团队选型 rails 的人该被开除

rails 做到 10000 QPS 需要

• 代码质量极高，
• 一层一层的 cache，
• 精简 gems and rails middleware
• 以及对业务理解...
• 外加 cdn 等护身法宝...

换 rack + sequel 吧，rails 只能堆机器 + 各种优化来弥补性能上的损失

不要引入 active X 系列 activemodel activerecord activesupport

太占内存，rails 系列，随便一个进程 150M+ 内存是无压力的，代码质量差点，跑的时间久点，内存是会涨的，300M，500M/进程 无压力。

查询加缓存

非必要实时写入 (指你当前时段写入的数据，在本次并发查询【一定】不会用到)，可以考虑做延迟写入； 如果 DB 是 mysql，精通 mysql 的话，可以自己做 binlog 收集及批量导入，不精通就算了，风险指数略高。

rack + sequel + puma 多 worker，在目前公司项目中，内存 50M 一个进程，几月稳定跑，进程不假死，内存固定不涨，不能说太多，说多了算是在黑 Rails 了。

很僵硬。。很尴尬。

是。没有代码示例确实有点枯燥

• 办法一：可以考虑从业务上调整。整点同时 6000 并发，这不是人为操作，而是有程序在向你们服务器发请求。你们作为上游可以尝试让下游调整。
• 办法二、如果下游不要求 rails 同步立即给出最终结果的话，可以把业务处理交给后台程序（via sidekiq, resque or RabbitMQ），然后快速响应下请求。
• 办法三、用 Node.js 试试看，启用 Cluster 模式。
• 办法四、找出瓶颈，就用原来的 Java 跑。
• 办法五、8 核 16g 内存这种服务器已经比较老了，建议更新下硬件（包括硬盘）。

这并发量真的大

用 ruby 不可行，用其它语言吧

何况你还不懂。。

这样想想，如果从语言和框架分析，干脆继续从 java 方向优化，性能也许比 rack 要好。比如，用适应高并发的 java 框架。