Gunicorn as WSGI server in Django - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

Gunicorn Worker Process Behavior

What happens when you send multiple simultaneous HTTP requests to a Django app served by Gunicorn with 3 worker processes?

A Gunicorn distributes requests among the 3 workers, allowing parallel processing of up to 3 requests.

B Gunicorn queues all requests and processes them one by one in a single worker.

C Gunicorn processes all requests in a single worker ignoring the others.

D Gunicorn rejects requests exceeding one at a time until the first finishes.

💡 Hint

Think about how multiple workers help handle concurrent requests.

Gunicorn uses multiple worker processes to handle requests in parallel. With 3 workers, it can process up to 3 requests simultaneously by distributing them among workers.

📝 Syntax

intermediate

Correct Gunicorn Command to Run Django App

Which Gunicorn command correctly runs a Django project named myproject with the WSGI application located at myproject.wsgi:application?

A gunicorn wsgi:myproject.application

B gunicorn myproject:application

C gunicorn myproject.wsgi:application

D gunicorn application.myproject:wsgi

💡 Hint

The Gunicorn command requires the Python path to the WSGI callable.

The correct syntax is gunicorn module_path:callable. For Django, the WSGI callable is usually application inside the wsgi.py module of the project.

🔧 Debug

advanced

Gunicorn Fails to Start with ImportError

You run gunicorn myproject.wsgi:application but get an ImportError: No module named 'myproject'. What is the most likely cause?

A The Django project is missing the <code>manage.py</code> file.

B Gunicorn is run outside the Django project root or PYTHONPATH is not set correctly.

C Gunicorn requires a different command syntax for Django projects.

D The <code>application</code> callable is missing inside <code>wsgi.py</code>.

💡 Hint

Think about how Python finds modules when importing.

Python needs the project directory in its path to import the myproject module. Running Gunicorn outside the project root or without proper PYTHONPATH causes ImportError.

❓ state_output

advanced

Effect of Increasing Gunicorn Workers on Memory Usage

If you increase Gunicorn worker count from 2 to 10 for a Django app, what is the expected effect on memory usage and request handling?

A Memory usage decreases because workers share code in memory.

B Memory usage stays the same; Gunicorn shares memory across workers.

C Memory usage increases slightly but request handling capacity decreases.

D Memory usage increases roughly 5 times; more requests can be handled concurrently.

💡 Hint

Consider how each worker is a separate process.

Each Gunicorn worker is a separate process with its own memory space. Increasing workers increases memory usage roughly proportionally but allows more concurrent requests.

🧠 Conceptual

expert

Why Use Gunicorn Instead of Django's Development Server in Production?

Which reason best explains why Gunicorn is preferred over Django's built-in development server for production deployments?

A Gunicorn is designed to handle multiple concurrent requests efficiently and is more stable for production use.

B Django's development server does not support Python 3.12 and newer versions.

C Gunicorn automatically updates Django code without restarting the server.

D Django's development server cannot serve static files at all.

💡 Hint

Think about stability and concurrency in production environments.

Django's development server is single-threaded and meant only for testing. Gunicorn supports multiple workers and is built for production stability and performance.

Practice

1. What is the primary role of Gunicorn when used with a Django project?

easy

A. It replaces the Django ORM for database queries.

B. It acts as a bridge between the web server and the Django application.

C. It manages static files like CSS and JavaScript.

D. It compiles Django templates into HTML.

Solution

1. Step 1: Understand Gunicorn's purpose

   Gunicorn is a WSGI server that connects web requests to the Django app code.

2. Step 2: Identify what Gunicorn does not do

   Gunicorn does not handle database queries, static files, or template compilation directly.

3. Final Answer:

   It acts as a bridge between the web server and the Django application. -> Option B

4. Quick Check:

   Gunicorn = bridge server [OK]

Hint: Gunicorn connects web requests to Django code [OK]

Common Mistakes:

• Thinking Gunicorn manages static files
• Confusing Gunicorn with Django ORM
• Assuming Gunicorn compiles templates

2. Which of the following is the correct command to start Gunicorn for a Django project named myproject with the default WSGI application?

easy

A. gunicorn myproject.settings:application

B. gunicorn myproject.manage:application

C. gunicorn myproject.urls:application

D. gunicorn myproject.wsgi:application

Solution

1. Step 1: Identify the WSGI application path

   In Django, the WSGI app is located at projectname.wsgi:application.

2. Step 2: Match the correct command format

   The correct Gunicorn command uses gunicorn myproject.wsgi:application.

3. Final Answer:

   gunicorn myproject.wsgi:application -> Option D

4. Quick Check:

   WSGI app path = myproject.wsgi:application [OK]

Hint: Gunicorn command uses <project>.wsgi:application [OK]

Common Mistakes:

• Using manage or settings instead of wsgi
• Confusing URLs module with WSGI
• Omitting the ':application' part

3. Given the command gunicorn --workers 3 --bind 0.0.0.0:8000 myproject.wsgi:application, what will happen when you run it?

medium

A. Gunicorn will start 1 worker and listen only on localhost at port 8000.

B. Gunicorn will fail because the bind address is invalid.

C. Gunicorn will start 3 worker processes and listen on all network interfaces at port 8000.

D. Gunicorn will start 3 workers but will not bind to any port.

Solution

1. Step 1: Analyze the --workers option

   The command specifies 3 workers, so Gunicorn will start 3 worker processes.

2. Step 2: Analyze the --bind option

   Binding to 0.0.0.0:8000 means listening on all network interfaces at port 8000.

3. Final Answer:

   Gunicorn will start 3 worker processes and listen on all network interfaces at port 8000. -> Option C

4. Quick Check:

   --workers 3 + --bind 0.0.0.0:8000 = Gunicorn will start 3 worker processes and listen on all network interfaces at port 8000. [OK]

Hint: 0.0.0.0 binds all interfaces, workers set process count [OK]

Common Mistakes:

• Assuming 0.0.0.0 is invalid
• Thinking workers default to 1 always
• Ignoring the bind port

4. You run gunicorn myproject.wsgi:application --workers two and get an error. What is the likely cause?

medium

A. The workers option must be a number, not a word.

B. The WSGI application path is incorrect.

C. Gunicorn does not accept the --workers option.

D. The command is missing the --bind option.

Solution

1. Step 1: Check the --workers option value

   The value 'two' is a word, but --workers expects an integer number.

2. Step 2: Confirm Gunicorn option requirements

   Gunicorn requires a numeric value for workers; using a word causes an error.

3. Final Answer:

   The workers option must be a number, not a word. -> Option A

4. Quick Check:

   --workers needs number, not text [OK]

Hint: Workers count must be numeric, not text [OK]

Common Mistakes:

• Assuming WSGI path error causes this
• Thinking --workers is unsupported
• Believing --bind is mandatory for this error

5. You want to deploy your Django app with Gunicorn on a server accessible only on port 8080 and use 4 workers for better performance. Which command correctly achieves this?

hard

A. gunicorn --workers 4 --bind 0.0.0.0:8080 myproject.wsgi:application

B. gunicorn --workers 4 --bind 127.0.0.1:8080 myproject.wsgi:application

C. gunicorn --workers 1 --bind 0.0.0.0:8080 myproject.wsgi:application

D. gunicorn --bind 0.0.0.0:80 myproject.wsgi:application

Solution

1. Step 1: Set the correct number of workers

   The requirement is 4 workers, so use --workers 4.

2. Step 2: Bind to port 8080 on all interfaces

   Binding to 0.0.0.0:8080 makes the app accessible on port 8080 from any network interface.

3. Step 3: Verify the WSGI application path

   The path myproject.wsgi:application is the correct WSGI app for Django.

4. Final Answer:

   gunicorn --workers 4 --bind 0.0.0.0:8080 myproject.wsgi:application -> Option A

5. Quick Check:

   4 workers + bind 0.0.0.0:8080 = gunicorn --workers 4 --bind 0.0.0.0:8080 myproject.wsgi:application [OK]

Hint: Use --workers 4 and bind 0.0.0.0:8080 for access [OK]

Common Mistakes:

• Binding only to localhost (127.0.0.1) limits access
• Using wrong port number
• Setting wrong number of workers