Help understanding load test result with backpressure=1 #765

ishepard · 2025-12-16T13:46:08Z

ishepard
Dec 16, 2025

Hi @gi0baro,
we are moving our services from wsgi to Granian. We are also currently load testing our services to find out weaknesses and improvements.

We do see a strange behavior happening and would like to get your input.
Our services are not thread-safe. Hence, we currently use the setup:

ENV GRANIAN_WORKERS=8
ENV GRANIAN_BLOCKING_THREADS=1
ENV GRANIAN_INTERFACE=wsgi
ENV GRANIAN_BACKPRESSURE=1

So 1 thread and wsgi as interface.

Now, the issue we have is that during the load test a small percentage of requests will just timeout only when we set BACKPRESSURE=1. If we remove that, we don't see it happening.

I even created a small Docker setup for you to test.

CODE

app.py

def app(environ, start_response):
    body = b"<!doctype html><html><head><meta charset='utf-8'><title>granian-bot</title></head><body><h1>OK</h1><p>granian-bot (WSGI) is running.</p></body></html>"
    headers = [
        ("Content-Type", "text/html; charset=utf-8"),
    ]
    start_response(f"200 OK", headers)
    return [body]

Dockerfile:

FROM python:3.12-slim

WORKDIR /app

RUN pip install --no-cache-dir granian

COPY app.py .

ENV GRANIAN_WORKERS=8
ENV GRANIAN_BLOCKING_THREADS=1
ENV GRANIAN_INTERFACE=wsgi
ENV GRANIAN_BACKPRESSURE=1

EXPOSE 8000

CMD ["granian", "--host", "0.0.0.0", "--port", "8000", "app:app"]

To load test, we are using k6 with 500 VUs:

import http from "k6/http";
import { check } from "k6";

export const options = {
  vus: 500,
  iterations: 100000,
};

export default function () {
  const res = http.get("http://localhost:8000/");

  check(res, {
    "status is 200": (r) => r.status === 200,
    "body contains OK": (r) => r.body.includes("<h1>OK</h1>"),
  });
}

RESULT

    EXECUTION
    iteration_duration.............: avg=293.64ms min=176.12µs med=360.45µs max=1m0s   p(90)=479.29µs p(95)=540.33µs
    iterations.....................: 100000 1665.647291/s
    vus............................: 484    min=484           max=500
    vus_max........................: 500    min=500           max=500

See the max duration: 1 minute. So in this simple test, there were few requests that took 1 minute to complete.
This seems like the connection was just hanging, or timed out.

HYPOTHESIS

Now, our current hypothesis is:

BACKPRESSURE=1: each worker accepts 1 connection at a time
We have 8 workers, so 8 requests at the time. With backpressure=1, ~16 requests in total.
the other 484 connections sit in the TCP backlog. If the backlog fills up (deafult 1024), new connections get refused or hang

When we remove BACKPRESSURE=1, each worker can accept more connections, so the issue doesn't happen (as quickly, at least).

But then, the question is: in a single-threaded wsgi application, does it make sense to set BACKPRESSURE to something different than 1? According to the documentation, it doesn't.
Maybe we should set BACKLOG to a bigger number then? So that we can accept more connections?
What do you advise?

gi0baro · 2025-12-16T14:46:21Z

gi0baro
Dec 16, 2025
Maintainer

The problem relies on the fact almost every client out there use keep-alive connections.
Backpressure set to 1 means you accept only 1 connection, thus until that connection isn't closed, you can't accept any more connection. So, realistically speaking, I don't think you ever want to set that value.

My advise for a single-threaded application, is to set blocking-threads to 1 and backlog to the total amount of connections you expect to be alive at the same time. backpressure gets automatically set to backlog / no of workers.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Help understanding load test result with backpressure=1 #765

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

Help understanding load test result with backpressure=1 #765

Uh oh!

ishepard Dec 16, 2025

CODE

RESULT

HYPOTHESIS

Replies: 1 comment

Uh oh!

gi0baro Dec 16, 2025 Maintainer

ishepard
Dec 16, 2025

gi0baro
Dec 16, 2025
Maintainer