Not getting a high performance compared to gunicorn

[ZeyadMoustafaKamal]

So I started a Django project and compared gunicorn and granian but noticed no difference at all. This confuses me as I thought using a Rust-based server would be way more efficient than a Python-based one. Here is what I got using hey

Using gunicorn :

first

➜  ~  hey -n 1000 http://127.0.0.1:8000

Summary:
  Total:        0.7088 secs
  Slowest:      0.1720 secs
  Fastest:      0.0030 secs
  Average:      0.0243 secs
  Requests/sec: 1410.7955

  Total data:   10629000 bytes
  Size/request: 10629 bytes

Response time histogram:
  0.003 [1]     |
  0.020 [558]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.037 [252]   |■■■■■■■■■■■■■■■■■■
  0.054 [111]   |■■■■■■■■
  0.071 [30]    |■■
  0.088 [22]    |■■
  0.104 [10]    |■
  0.121 [5]     |
  0.138 [6]     |
  0.155 [4]     |
  0.172 [1]     |


Latency distribution:
  10% in 0.0056 secs
  25% in 0.0093 secs
  50% in 0.0167 secs
  75% in 0.0323 secs
  90% in 0.0499 secs
  95% in 0.0698 secs
  99% in 0.1252 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0003 secs, 0.0030 secs, 0.1720 secs
  DNS-lookup:   0.0000 secs, 0.0000 secs, 0.0000 secs
  req write:    0.0001 secs, 0.0000 secs, 0.0080 secs
  resp wait:    0.0221 secs, 0.0029 secs, 0.1441 secs
  resp read:    0.0017 secs, 0.0000 secs, 0.0539 secs

Status code distribution:
  [200] 1000 responses

second time:

➜  ~  hey -n 1000 http://127.0.0.1:8000

Summary:
  Total:        0.7556 secs
  Slowest:      0.1178 secs
  Fastest:      0.0029 secs
  Average:      0.0257 secs
  Requests/sec: 1323.3872

  Total data:   10629000 bytes
  Size/request: 10629 bytes

Response time histogram:
  0.003 [1]     |
  0.014 [326]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.026 [305]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.037 [169]   |■■■■■■■■■■■■■■■■■■■■■
  0.049 [75]    |■■■■■■■■■
  0.060 [49]    |■■■■■■
  0.072 [33]    |■■■■
  0.083 [23]    |■■■
  0.095 [16]    |■■
  0.106 [0]     |
  0.118 [3]     |


Latency distribution:
  10% in 0.0063 secs
  25% in 0.0113 secs
  50% in 0.0201 secs
  75% in 0.0338 secs
  90% in 0.0537 secs
  95% in 0.0701 secs
  99% in 0.0878 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0002 secs, 0.0029 secs, 0.1178 secs
  DNS-lookup:   0.0000 secs, 0.0000 secs, 0.0000 secs
  req write:    0.0005 secs, 0.0000 secs, 0.0522 secs
  resp wait:    0.0210 secs, 0.0027 secs, 0.1149 secs
  resp read:    0.0037 secs, 0.0000 secs, 0.0530 secs

Status code distribution:
  [200] 1000 responses

using granian:

first time:

➜  ~  hey -n 1000 http://127.0.0.1:8000

Summary:
  Total:        0.6708 secs
  Slowest:      0.2523 secs
  Fastest:      0.0024 secs
  Average:      0.0212 secs
  Requests/sec: 1490.7299

  Total data:   10629000 bytes
  Size/request: 10629 bytes

Response time histogram:
  0.002 [1]     |
  0.027 [784]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.052 [118]   |■■■■■■
  0.077 [56]    |■■■
  0.102 [25]    |■
  0.127 [10]    |■
  0.152 [1]     |
  0.177 [2]     |
  0.202 [0]     |
  0.227 [1]     |
  0.252 [2]     |


Latency distribution:
  10% in 0.0044 secs
  25% in 0.0068 secs
  50% in 0.0119 secs
  75% in 0.0239 secs
  90% in 0.0515 secs
  95% in 0.0720 secs
  99% in 0.1155 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0003 secs, 0.0024 secs, 0.2523 secs
  DNS-lookup:   0.0000 secs, 0.0000 secs, 0.0000 secs
  req write:    0.0001 secs, 0.0000 secs, 0.0137 secs
  resp wait:    0.0207 secs, 0.0023 secs, 0.2439 secs
  resp read:    0.0001 secs, 0.0000 secs, 0.0042 secs

Status code distribution:
  [200] 1000 responses

second time:

➜  ~  hey -n 1000 http://127.0.0.1:8000

Summary:
  Total:        0.6891 secs
  Slowest:      0.1511 secs
  Fastest:      0.0024 secs
  Average:      0.0242 secs
  Requests/sec: 1451.0717

  Total data:   10629000 bytes
  Size/request: 10629 bytes

Response time histogram:
  0.002 [1]     |
  0.017 [581]   |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.032 [210]   |■■■■■■■■■■■■■■
  0.047 [81]    |■■■■■■
  0.062 [28]    |■■
  0.077 [15]    |■
  0.092 [22]    |■■
  0.106 [34]    |■■
  0.121 [17]    |■
  0.136 [8]     |■
  0.151 [3]     |


Latency distribution:
  10% in 0.0044 secs
  25% in 0.0077 secs
  50% in 0.0143 secs
  75% in 0.0278 secs
  90% in 0.0615 secs
  95% in 0.0947 secs
  99% in 0.1255 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0006 secs, 0.0024 secs, 0.1511 secs
  DNS-lookup:   0.0000 secs, 0.0000 secs, 0.0000 secs
  req write:    0.0004 secs, 0.0000 secs, 0.0302 secs
  resp wait:    0.0228 secs, 0.0023 secs, 0.1510 secs
  resp read:    0.0003 secs, 0.0000 secs, 0.0743 secs

Status code distribution:
  [200] 1000 responses

The command in gunicorn is: gunicorn -w 16 --threads 16 project.wsgi:application

and the command in granian is : granian --interface wsgi --workers 16 --threads 16 project.wsgi:application

The page loaded is the default page for Django applications a simple HTML page. So is there anything I have done wrong or this is a normal thing??

[gi0baro]

So, in general the final performance is really dependant on your application code, as Granian can only affect the network part of that: there's no dark magic to apply here, Granian is still subject to GIL and blocking code whenever it interacts with your application.

Given that, I have a few considerations:

• from you numbers, looks like Granian is ~6% faster
• whenever you do benchmarks, I would use a time-based strategy to run at least for 15 seconds (or increase the requests number to higher values), as running for less than a second might increase standard deviation and produce unstable results (maybe you can try with 100k requests)
• I'm not sure why you want 16*16=256 threads running, as even if you have that number of CPU cores (which I hardly doubt), that sounds like threads will fight a lot with each other. Also, in Granian --threads refer to Rust threads (handling requests), not Python ones. If you want to increase the number of threads on Python side due to blocking code, you probably want to increase --blocking-threads instead. But I would still use lower number than yours, never exceeding like 2N where N is the number of CPU cores you have.
• also, you might experiment wether --threading-mode set to workers or runtime works the best for your application

[ZeyadMoustafaKamal]

Thanks a lot for this answer. So I have another question. Isn't there any way we can avoid the GIL ?? I am sure that we can do such a thing due to rust nature and I am sure that this will be way better for us.

[gi0baro]

It won't change a thing: every time a consuming operation is happening in Rust code, Granian doesn't hold the GIL. The GIL is only held during the execution of your application code or when Granian needs to interact with Python objects: there's no way to avoid that, at least until Python 3.13 will land, but that will require a lot of work also from other libraries to support the no-GIL version.