WSGI servers (Gunicorn, uWSGI) in Flask - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when you run a Flask app with Gunicorn using multiple workers?

Consider a Flask app started with Gunicorn using the command gunicorn -w 4 app:app. What is the effect of specifying -w 4?

A Gunicorn runs 4 instances of the Flask app in the same process, but only one handles requests at a time.

B Gunicorn runs a single process with 4 threads, sharing the same memory space.

C Gunicorn runs 4 separate worker processes, each handling requests independently, improving concurrency.

D Gunicorn runs 4 worker processes but only one can handle requests at any moment.

💡 Hint

Think about how Gunicorn uses workers to handle multiple requests simultaneously.

Gunicorn creates multiple worker processes (4 in this case). Each worker runs independently and can handle requests concurrently, improving performance under load.

📝 Syntax

intermediate

Which Gunicorn command correctly binds the server to port 8080?

You want to start a Flask app with Gunicorn and bind it to port 8080 on all interfaces. Which command is correct?

A gunicorn -p 8080 app:app

B gunicorn -b localhost:8080 app:app

C gunicorn --bind 127.0.0.1:8080 app:app

D gunicorn --bind 0.0.0.0:8080 app:app

💡 Hint

Binding to 0.0.0.0 means listening on all network interfaces.

The --bind option specifies the IP and port. 0.0.0.0:8080 means listen on all interfaces at port 8080.

🔧 Debug

advanced

Why does uWSGI fail to start with this config snippet?

Given this uWSGI config snippet:

[uwsgi]
module = app:app
master = true
processes = 4
socket = 127.0.0.1:5000

What is the likely cause of failure?

Flask

[uwsgi]
module = app:app
master = true
processes = 4
socket = 127.0.0.1:5000

A The socket option requires 'http-socket' instead of 'socket' for HTTP serving.

B The 'module' option should be 'app.app' not 'app:app'.

C The 'master' option must be false to run multiple processes.

D The 'processes' option must be set to 1 for uWSGI to start.

💡 Hint

Check if the socket type matches the expected protocol for HTTP serving.

Using socket creates a raw socket expecting a WSGI server behind a proxy. To serve HTTP directly, http-socket is needed.

❓ state_output

advanced

What is the output when using Gunicorn with multiple workers and a global counter?

Consider this Flask app:

from flask import Flask
app = Flask(__name__)
counter = 0

@app.route('/')
def index():
    global counter
    counter += 1
    return str(counter)

If you run it with gunicorn -w 3 app:app and make 3 requests, what is the possible output sequence?

Flask

from flask import Flask
app = Flask(__name__)
counter = 0

@app.route('/')
def index():
    global counter
    counter += 1
    return str(counter)

A The responses could be any combination of 1, 2, or 3 repeated because each worker has its own counter.

B The responses will be 1, 2, 3 in order because the counter is shared across workers.

C All responses will be 3 because Gunicorn synchronizes the counter across workers.

D The app will crash because global variables cannot be used with Gunicorn.

💡 Hint

Think about how global variables behave in multiple processes.

Each Gunicorn worker is a separate process with its own memory. The global counter is not shared, so each worker increments its own counter independently.

🧠 Conceptual

expert

Why is using uWSGI with Emperor mode beneficial in production?

What is the main advantage of running uWSGI in Emperor mode for managing multiple Flask apps?

A Emperor mode allows uWSGI to run without configuration files, simplifying setup.

B Emperor mode automatically manages multiple uWSGI instances, restarting them if they crash, improving reliability.

C Emperor mode enables uWSGI to serve static files faster than Nginx.

D Emperor mode disables worker processes to reduce memory usage.

💡 Hint

Think about how production servers handle multiple apps and failures.

Emperor mode supervises multiple uWSGI instances, automatically restarting them if they fail, which helps keep apps running smoothly in production.

Practice

1. What is the main role of a WSGI server like Gunicorn or uWSGI when running a Flask application?

easy

A. To connect the Flask app to the web and handle multiple user requests efficiently

B. To write the Flask application code

C. To create the HTML templates for the Flask app

D. To manage the database connections directly

Solution

1. Step 1: Understand WSGI server purpose

   WSGI servers act as a bridge between the web and Flask app, managing requests.

2. Step 2: Identify what Gunicorn and uWSGI do

   They handle multiple users and serve the Flask app efficiently in production.

3. Final Answer:

   To connect the Flask app to the web and handle multiple user requests efficiently -> Option A

4. Quick Check:

   WSGI server role = Connect app and handle requests [OK]

Hint: WSGI servers link web and app, not write code [OK]

Common Mistakes:

• Thinking WSGI servers write app code
• Confusing WSGI with template engines
• Assuming WSGI manages databases

2. Which of the following is the correct command to start a Flask app using Gunicorn on port 8000?

easy

A. gunicorn app.py --port 8000

B. gunicorn run app --port=8000

C. gunicorn -w 4 -b 0.0.0.0:8000 app:app

D. gunicorn app:app --workers=2 --port=8000

Solution

1. Step 1: Recall Gunicorn syntax

   Gunicorn uses '-w' for workers and '-b' for binding address and port.

2. Step 2: Check correct app reference and port

   Correct format is 'gunicorn -w 4 -b 0.0.0.0:8000 app:app' to run app with 4 workers on port 8000.

3. Final Answer:

   gunicorn -w 4 -b 0.0.0.0:8000 app:app -> Option C

4. Quick Check:

   Gunicorn uses -w and -b flags [OK]

Hint: Gunicorn uses -w for workers and -b for bind address [OK]

Common Mistakes:

• Using --port instead of -b for binding
• Incorrect app reference like app.py instead of app:app
• Wrong flag order or missing workers

3. Given the command gunicorn -w 3 -b 127.0.0.1:5000 app:app, what will happen when you try to access the Flask app from another computer on the network?

medium

A. The app will be accessible from any computer on the network

B. The app will automatically bind to all interfaces

C. The app will refuse all connections and crash

D. The app will only be accessible from the local machine (127.0.0.1)

Solution

1. Step 1: Understand binding address 127.0.0.1

   Binding to 127.0.0.1 means the server listens only on localhost, not external network.

2. Step 2: Check network accessibility

   Other computers cannot access the app because it is not bound to the external IP or 0.0.0.0.

3. Final Answer:

   The app will only be accessible from the local machine (127.0.0.1) -> Option D

4. Quick Check:

   127.0.0.1 = localhost only [OK]

Hint: 127.0.0.1 binds only local access, not network [OK]

Common Mistakes:

• Assuming 127.0.0.1 allows network access
• Thinking Gunicorn auto-binds to all interfaces
• Confusing localhost with external IP

4. You run uwsgi --http :5000 --module app:app but get an error saying the module 'app' cannot be found. What is the most likely cause?

medium

A. The app.py file is missing or not in the current directory

B. The uWSGI command requires the --wsgi-file option instead of --module

C. The port 5000 is already in use by another process

D. The Flask app is not installed properly

Solution

1. Step 1: Understand module loading in uWSGI

   Using --module expects a Python module named 'app' with an 'app' variable inside.

2. Step 2: Check file presence and location

   If 'app.py' is missing or not in the current directory, uWSGI cannot find the module.

3. Final Answer:

   The app.py file is missing or not in the current directory -> Option A

4. Quick Check:

   Missing app.py causes module not found error [OK]

Hint: Check app.py file exists in current folder [OK]

Common Mistakes:

• Confusing --module with --wsgi-file
• Assuming port conflicts cause module errors
• Ignoring file location issues

5. You want to deploy a Flask app with uWSGI to handle 8 worker processes and bind it to all network interfaces on port 8080. Which command correctly achieves this?

hard

A. uwsgi --http 0.0.0.0:8080 --workers 8 --module app:app

B. uwsgi --http :8080 --processes 8 --module app:app --master

C. uwsgi --socket 0.0.0.0:8080 --processes 8 --wsgi-file app.py

D. uwsgi --http 127.0.0.1:8080 --workers 8 --module app:app

Solution

1. Step 1: Identify correct uWSGI flags for HTTP and workers

   --http :8080 binds to all interfaces on port 8080; --processes 8 sets 8 worker processes.

2. Step 2: Confirm module and master process usage

   --module app:app correctly points to the Flask app; --master enables master process for better management.

3. Step 3: Eliminate incorrect options

   A: uwsgi --http 0.0.0.0:8080 --workers 8 --module app:app uses invalid --workers flag (use --processes); B: uwsgi --http 127.0.0.1:8080 --workers 8 --module app:app binds only to localhost; C: uwsgi --socket 0.0.0.0:8080 --processes 8 --wsgi-file app.py uses --socket which is for socket mode, not HTTP.

4. Final Answer:

   uwsgi --http :8080 --processes 8 --module app:app --master -> Option B

5. Quick Check:

   Use --http :port and --processes with --master for production [OK]

Hint: Use --http :port and --processes with --master for uWSGI [OK]

Common Mistakes:

• Using --workers instead of --processes
• Confusing --socket with --http
• Binding only to 127.0.0.1 for network apps