AWS c5xlarge集群下Puma配置参数与最大并发请求数咨询

Hey there! Great call switching to Puma—Passenger's free version's lack of multi-threading support and those persistent "request limit exceeded" errors were definitely holding you back. Let's walk through how to tune Puma for your two c5.xlarge instances behind an ELB.

First, Know Your Instance Specs #

AWS c5.xlarge instances come with:

• 4 vCPUs (logical cores; 2 physical cores with hyper-threading)
• 8 GB RAM (roughly 7-7.5 GB usable after OS overhead)

Worker & Thread Count Recommendations #

Puma uses a combination of workers (separate processes) and threads (lightweight execution paths within each worker) to handle concurrency. Here's how to calculate the right numbers for your setup:

1. Workers #

For Ruby/Rails apps (limited by the Global Interpreter Lock, GIL), each worker process can utilize one logical CPU core. To maximize CPU utilization without excessive context switching:

• Start with workers = 4 (matches the number of vCPUs)
• If you notice high CPU context switching (check via CloudWatch or top), drop to 3 workers instead.

2. Threads #

Threads are ideal for IO-bound workloads (e.g., database queries, external API calls) since they free up the GIL while waiting for IO responses. The key constraint here is memory:

• Each Rails process + its threads typically consumes 500 MB–1 GB of RAM. With 4 workers, you have ~2 GB of RAM allocated per worker.
• A safe starting point is threads 5, 10 (minimum 5, maximum 10 threads per worker). This balances concurrency and memory usage.
• If you see memory pressure (e.g., swap usage, OOM kills), lower the max thread count to 8 or 5. If CPU is underutilized and memory is available, bump it to 12.

Sample Puma Configuration (config/puma.rb) #

Here's a production-ready config based on the above recommendations:

# Use ENV vars for easy tuning without changing code
workers Integer(ENV['WEB_CONCURRENCY'] || 4)
threads_count = Integer(ENV['MAX_THREADS'] || 10)
threads threads_count, threads_count

# Preload the app to reduce memory duplication across workers
preload_app!

# Basic server settings
rackup      DefaultRackup
port        ENV['PORT'] || 3000
environment ENV['RAILS_ENV'] || 'production'

# Re-establish database connections after forking workers (critical with preload_app!)
on_worker_boot do
  ActiveRecord::Base.establish_connection if defined?(ActiveRecord)
end

Maximum Concurrent Requests #

Your total concurrent capacity depends on the number of instances and their individual Puma settings:

• Per instance: workers * max_threads = 4 * 10 = 40 concurrent requests
• Total across 2 instances: 40 * 2 = 80 concurrent requests

Keep in mind:

• This is a theoretical maximum—real-world capacity will depend on your app's latency (e.g., slow database queries will reduce effective concurrency).
• Match your database connection pool size to the total number of threads per instance (40 in this case) in config/database.yml to avoid connection timeouts.

Post-Deployment Tuning Tips #

• Monitor CPU, memory, and database connection usage via AWS CloudWatch or tools like New Relic.
• If you see frequent request queuing (check Puma's /status endpoint), increase threads or workers (if resources allow).
• If CPU is consistently at 100%, reduce worker count to cut down on context switching, or optimize your app's CPU-heavy code.

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