Puma server configuration in Ruby on Rails - Step-by-Step Execution

Concept Flow - Puma server configuration

Start Puma Server

↓

Load config/puma.rb

↓

Set Threads min and max

↓

Set Worker count

↓

Bind to port or socket

↓

Preload app if enabled

↓

Start workers and threads

↓

Listen for requests

↓

Handle requests concurrently

↓

Shutdown gracefully on signal

Puma server starts by loading its configuration, sets threads and workers, binds to a port or socket, preloads the app if configured, then runs workers and threads to handle requests concurrently until shutdown.

Execution Sample

Ruby on Rails

threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
threads threads_count, threads_count
port ENV.fetch("PORT") { 3000 }
workers ENV.fetch("WEB_CONCURRENCY") { 2 }
preload_app!
plugin :tmp_restart

This Puma config sets thread count, port, worker count, preloads the app, and enables restart plugin.

Execution Table

Step	Action	Value/Setting	Effect
1	Fetch RAILS_MAX_THREADS	5 (default)	Set min and max threads to 5
2	Set threads	5, 5	Puma will use 5 threads per worker
3	Fetch PORT	3000 (default)	Puma binds to port 3000
4	Fetch WEB_CONCURRENCY	2 (default)	Puma will start 2 worker processes
5	Call preload_app!	Enabled	App code loaded before workers fork
6	Enable plugin :tmp_restart	Enabled	Allows restart via rails restart command
7	Start workers and threads	2 workers x 5 threads	Server ready to handle requests concurrently
8	Listen for requests	Port 3000	Server accepts incoming HTTP requests
9	Shutdown signal received	SIGTERM or SIGINT	Server stops workers and threads gracefully

💡 Server stops when shutdown signal is received

Variable Tracker

Variable	Initial	After Fetch	Final
threads_count	undefined	5	5
port	undefined	3000	3000
workers	undefined	2	2
preload_app	false	true	true

Key Moments - 3 Insights

Why do we set both minimum and maximum threads to the same number?

Setting min and max threads equal fixes the thread pool size, ensuring consistent concurrency as shown in execution_table step 2.

What does preload_app! do and why is it important?

preload_app! loads the app before workers fork, saving memory and speeding worker startup, as seen in step 5.

How does Puma handle multiple requests at the same time?

Puma uses multiple workers and threads (step 7) to handle requests concurrently, improving performance.

Visual Quiz - 3 Questions

Look at the execution_table, what is the thread count set to after fetching RAILS_MAX_THREADS?

A 5

B 2

C 3000

D Undefined

💡 Hint

Check execution_table row 1 under Value/Setting column

At which step does Puma bind to the port to listen for requests?

A Step 3

B Step 6

C Step 8

D Step 5

💡 Hint

Look for 'Listen for requests' in execution_table

If WEB_CONCURRENCY is changed to 4, how does the final worker count change?

A Workers remain 2

B Workers become 4

C Workers become 5

D Workers become 3000

💡 Hint

See variable_tracker row for workers and execution_table step 4

Concept Snapshot

Puma server config sets threads and workers for concurrency.
Use ENV variables with defaults for flexibility.
preload_app! loads app before forking workers.
Bind to port or socket to accept requests.
plugin :tmp_restart enables easy server restart.
Graceful shutdown on signals ensures clean exit.

Full Transcript

Puma server configuration starts by reading environment variables or defaults to set thread counts and worker processes. Threads control concurrency within each worker, while workers allow multiple processes for better performance. The preload_app! directive loads the application code before workers fork, saving memory and speeding startup. Puma binds to a specified port or socket to listen for incoming requests. The plugin :tmp_restart enables restarting Puma with the rails restart command. When a shutdown signal is received, Puma gracefully stops all workers and threads. This setup allows Puma to handle many requests efficiently and reliably.