Rails应用中Puma线程工作机制疑问：请求为何被阻塞？

测试代码 #

class TestsController < ApplicationController
  def index
    puts 'Going to Sleep'
    sleep 30.seconds

    render json: { message: 'ok' }
  end
end

问题描述 #

使用Puma作为应用服务器，生产模式启动Rails后，用浏览器5个不同标签访问localhost:3000/tests。原本预期Puma是并发服务器，每个请求由不同线程处理，首个请求的阻塞不会影响其他请求，但实际日志显示首个请求输出Going to Sleep后休眠30秒，期间其他请求的日志直到首个请求完成才出现。

疑问：

1. 首个请求为何会阻塞其他请求？
2. 这是否会带来实际问题？比如调用第三方API耗时较长时，是否会阻塞其他用户的请求？
3. 是否需要不同IP才能实现并发？

更新：Puma配置 #

max_threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
min_threads_count = ENV.fetch("RAILS_MIN_THREADS") { max_threads_count }
threads min_threads_count, max_threads_count

解答 #

1. 阻塞原因：同一用户会话的Session锁是核心因素 #

Rails默认会对同一用户会话的请求加锁：当处理包含Session的请求时，Rails会锁定该用户的Session资源，直到当前请求处理完毕才释放锁。这是为了防止同一用户的多个并发请求同时修改Session数据，导致数据不一致的问题。

你用同一个浏览器的多个标签访问时，所有请求共享同一个Session（浏览器会自动带上相同的Session Cookie），因此这些请求会被Rails强制串行处理——必须等第一个请求的sleep执行完成、释放Session锁后，下一个请求才会开始处理。

另外，主流浏览器对同一域名的并发TCP连接数有上限（比如Chrome默认是6个），但这个不是你当前场景的主要原因，即使连接数足够，同一Session的请求依然会被排队。

2. 实际影响范围：仅阻塞同一用户的请求，不影响其他用户 #

• 对于不同用户的请求：每个用户的Session是独立的，Puma的线程会并行处理这些请求，不会互相阻塞。比如其他用户用自己的浏览器访问，或者你用隐私模式/不同浏览器访问，这些请求会同时被处理，日志会同时输出Going to Sleep。
• 对于同一用户的请求：如果单个请求耗时很长（比如调用慢第三方API、处理大文件），该用户的其他请求会被阻塞，直到耗时请求完成，这会影响该用户的使用体验。

3. 无需不同IP，只需不同会话即可实现并发 #

不需要更换IP，只要让请求使用不同的用户会话就能触发Puma的并发处理：

• 使用浏览器的隐私/无痕模式访问
• 清除当前浏览器的Cookie后访问
• 使用不同的浏览器访问
• 模拟不同用户登录（每个用户有独立Session）

这些方式下，每个请求的Session独立，Rails不会加锁排队，Puma的5个线程会同时处理多个请求，你就能看到多个Going to Sleep日志同时输出。

内容的提问来源于stack exchange，提问作者r3b00t