Puma server configuration in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

Understanding Puma's thread pool behavior

Given this Puma configuration snippet, what is the maximum number of threads Puma will use concurrently?

Ruby on Rails

threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }.to_i
threads threads_count, threads_count

A 1

B 5

C 10

D 0

💡 Hint

Look at the minimum and maximum thread counts set by the threads method.

The threads method sets both minimum and maximum threads to the same value, so Puma will use exactly 5 threads concurrently.

📝 Syntax

intermediate

Correct syntax for binding Puma to a TCP port

Which option correctly binds Puma to listen on TCP port 3000 on all interfaces?

A bind 'tcp://0.0.0.0:3000'

B bind tcp://0.0.0.0:3000

C bind 'http://0.0.0.0:3000'

D bind 'tcp:0.0.0.0:3000'

💡 Hint

The bind method expects a string with the protocol prefix.

The correct syntax requires the protocol prefix 'tcp://' inside quotes. Option A is correct.

🔧 Debug

advanced

Identify the error in Puma worker configuration

What error will this Puma configuration cause when starting the server? workers ENV.fetch("WEB_CONCURRENCY") { 2 } preload_app! on_worker_boot do ActiveRecord::Base.establish_connection end

Ruby on Rails

workers ENV.fetch("WEB_CONCURRENCY") { 2 }
preload_app!
on_worker_boot do
  ActiveRecord::Base.establish_connection
end

A No error, configuration is correct

B RuntimeError due to missing block in on_worker_boot

C SyntaxError because of missing colon after on_worker_boot

D NoMethodError because establish_connection is called without parentheses

💡 Hint

This is a standard Puma configuration for Rails applications using multiple workers.

No error; this is the recommended configuration for Puma with preload_app! and multiple workers in Rails. The establish_connection call works without parentheses as it uses the default specification.

❓ state_output

advanced

Effect of preload_app! on application state

What is the main effect of calling preload_app! in Puma configuration?

A Preloads the app after workers start, increasing memory usage

B Automatically reloads code on every request in development

C Disables worker forking and runs all requests in a single process

D Loads the application before workers fork, sharing memory and reducing startup time

💡 Hint

Think about how forking affects memory and startup speed.

preload_app! loads the app before forking workers, so memory pages can be shared, improving performance and reducing startup time.

🧠 Conceptual

expert

Choosing Puma worker count for CPU cores

If a server has 8 CPU cores and you want to optimize Puma for concurrency and memory, which worker count is best practice?

A 1 worker with 16 threads to maximize concurrency

B 16 workers, double the CPU cores for more parallelism

C 8 workers, matching the number of CPU cores

D 4 workers with 2 threads each to balance load

💡 Hint

Consider how Puma uses workers and threads relative to CPU cores.

Best practice is to set workers equal to CPU cores to maximize CPU usage without excessive context switching. Threads handle concurrency within each worker.

Practice

1. What is the main purpose of configuring the threads setting in a Puma server for a Rails app?

easy

A. To control how many requests Puma can handle concurrently within a single worker

B. To set the number of worker processes Puma will spawn

C. To specify the port number Puma listens on

D. To define the Rails environment (development, production, etc.)

Solution

1. Step 1: Understand the role of threads in Puma

   Threads allow Puma to handle multiple requests at the same time inside one worker process.

2. Step 2: Differentiate threads from workers and ports

   Workers are separate processes, ports define network access, threads are about concurrency inside a worker.

3. Final Answer:

   To control how many requests Puma can handle concurrently within a single worker -> Option A

4. Quick Check:

   Threads = concurrent requests per worker [OK]

Hint: Threads = concurrent requests per worker process [OK]

Common Mistakes:

• Confusing threads with workers
• Thinking threads set the port
• Mixing threads with environment settings

2. Which of the following is the correct syntax to set Puma to listen on port 3000 in the configuration file?

easy

A. bind 'tcp://3000'

B. set_port 3000

C. listen 3000

D. port 3000

Solution

1. Step 1: Recall Puma configuration syntax for port

   Puma uses the simple directive port followed by the port number.

2. Step 2: Check other options for correctness

   set_port and listen are not valid Puma config commands; bind requires a full URL, not just a port number.

3. Final Answer:

   port 3000 -> Option D

4. Quick Check:

   Use port to set listening port [OK]

Hint: Use 'port' keyword followed by number [OK]

Common Mistakes:

• Using 'listen' instead of 'port'
• Omitting quotes in 'bind' URL
• Using non-existent 'set_port' command

3. Given this Puma config snippet:

threads 5, 5
workers 2
port 4000

How many total threads can Puma handle at once across all workers?

medium

A. 5

B. 10

C. 2

D. 20

Solution

1. Step 1: Understand threads and workers relationship

   Each worker runs with 5 threads, and there are 2 workers.

2. Step 2: Calculate total threads

   Total threads = threads per worker * number of workers = 5 * 2 = 10. But note the config uses 'threads 5, 5' which means min and max threads are 5, so max threads per worker is 5.

3. Step 3: Re-examine the question carefully

   Actually, the question asks total threads Puma can handle at once across all workers. Since each worker has 5 threads, and there are 2 workers, total is 5 * 2 = 10.

4. Final Answer:

   10 -> Option B

5. Quick Check:

   Threads per worker * workers = 10 [OK]

Hint: Multiply threads by workers for total concurrency [OK]

Common Mistakes:

• Confusing min and max threads
• Ignoring number of workers
• Assuming threads is total, not per worker

4. You added preload_app! in your Puma config but your Rails app crashes on worker boot with a database connection error. What is the most likely fix?

medium

A. Increase the number of workers

B. Remove preload_app! from the config

C. Add a on_worker_boot block to reconnect ActiveRecord

D. Change the port number to 8080

Solution

1. Step 1: Understand what preload_app! does

   It loads the app before workers fork, so connections like database must be re-established in each worker.

2. Step 2: Fix database connection error on worker boot

   Use on_worker_boot block to reconnect ActiveRecord to the database after forking.

3. Final Answer:

   Add a on_worker_boot block to reconnect ActiveRecord -> Option C

4. Quick Check:

   Use on_worker_boot to fix DB connections [OK]

Hint: Reconnect DB in on_worker_boot after preload_app! [OK]

Common Mistakes:

• Removing preload_app! instead of fixing connections
• Changing unrelated settings like port
• Increasing workers without fixing connections

5. You want Puma to run with 3 workers and a thread pool between 2 and 6 threads per worker. You also want to ensure your Rails app reconnects to the database properly after forking. Which Puma config snippet correctly achieves this?

hard

A. threads 2, 6\nworkers 3\npreload_app!\non_worker_boot do\n ActiveRecord::Base.establish_connection\nend

B. workers 3\nthreads 6, 2\npreload_app!\non_worker_boot do\n ActiveRecord::Base.connection.disconnect!\nend

C. threads 2, 6\nworkers 3\nport 3000\non_worker_boot do\n ActiveRecord::Base.establish_connection\nend

D. workers 3\nthreads 2, 6\npreload_app!\non_worker_boot do\n ActiveRecord::Base.connection.reconnect!\nend

Solution

1. Step 1: Set threads and workers correctly

   Threads should be set as threads 2, 6 for min and max, and workers as 3.

2. Step 2: Use preload_app! and reconnect DB properly

   preload_app! must be present, and on_worker_boot should call ActiveRecord::Base.establish_connection to reconnect DB.

3. Step 3: Check each option for correctness

   threads 2, 6\nworkers 3\npreload_app!\non_worker_boot do\n ActiveRecord::Base.establish_connection\nend matches all requirements. workers 3\nthreads 6, 2\npreload_app!\non_worker_boot do\n ActiveRecord::Base.connection.disconnect!\nend reverses thread min/max and disconnects DB incorrectly. threads 2, 6\nworkers 3\nport 3000\non_worker_boot do\n ActiveRecord::Base.establish_connection\nend misses preload_app!. workers 3\nthreads 2, 6\npreload_app!\non_worker_boot do\n ActiveRecord::Base.connection.reconnect!\nend uses a non-existent reconnect! method.

4. Final Answer:

   threads 2, 6 workers 3 preload_app! on_worker_boot do ActiveRecord::Base.establish_connection end -> Option A

5. Quick Check:

   Correct threads, workers, preload_app!, and DB reconnect [OK]

Hint: Use preload_app! with on_worker_boot to reconnect DB [OK]

Common Mistakes:

• Swapping min and max threads
• Omitting preload_app!
• Using wrong DB reconnect method