Reserved connection for healthcheck requests

[nicolasbriere1]

Hi!
We have a use case where we use Granian with our Django backend service instead of uWSGI. Thanks for the work.
We use the backlog parameter to limit connections to preserve our database.

In our previous implementation, we split connections into two categories:

• Reserved capacity for healthcheck
• Lambda capacity for application requests

We would like to reproduce this with Granian. Do we already have this capability with Granian, or would it be possible to add this as a new feature?

[gi0baro]

We use the backlog parameter to limit connections to preserve our database.

You should use backpressure instead. See the readme.

We would like to reproduce this with Granian. Do we already have this capability with Granian, or would it be possible to add this as a new feature?

How did you do that with uWSGI? Sounds hard to add facilities for smth like this in Granian: there's no request processing (eg host/url check for routing) performed at all, everything gets just passed to the wsgi application.

Also, on a side note, I personally find this kind of approach quite weird: if I have an healthcheck it should report the real application status, not the fact the server is running. So having the healthcheck splitted from everything else, I would say it reports its own status rather than the application one: if all the application requests are stuck, why the healthcheck should report a good status? Kinda misleading.

[nicolasbriere1]

Hi !

You should use backpressure instead. See the readme.

We hesitate between backlog and backpressure, for us the need is to limitate for each django instance number of connection. backpressure is a settings by worker and depends of backlog value. That's the advantage for you?

I personally find this kind of approach quite weird: if I have an healthcheck it should report the real application status

If our application has reached its maximum allowed connections, this doesn't mean it's unhealthy.
For example, let's say we have a limit of 128 connections; it's relevant to limit lambda connections to 125 and keep 3 for healthcheck requests.
We prefer to scale the number of containers in our service rather than within a single container.

How did you do that with uWSGI? Sounds hard to add facilities for smth like this in Granian: there's no request processing (eg host/url check for routing) performed at all, everything gets just passed to the wsgi application.

Below an extract of our uswsgi conf file :

[uwsgi]
; Listen on 0.0.0.0:8000
socket = :8000

module = app.wsgi
need-app = true
single-interpreter = true

; expose http for healthcheck
http-socket = 0.0.0.0:9001

; uWSGi
listen=128

We use socket listener for lambda call with a Nginx at front and we use http listener for internal healthcheck

[gi0baro]

We hesitate between backlog and backpressure, for us the need is to limitate for each django instance number of connection. backpressure is a settings by worker and depends of backlog value. That's the advantage for you?

If you set the backlog taking into account backpressure would be backlog / workers then it's the same. Just remember your "django instance" will match to the single worker, as workers are independent processes and each of them will load your application independently.

If our application has reached its maximum allowed connections, this doesn't mean it's unhealthy. For example, let's say we have a limit of 128 connections; it's relevant to limit lambda connections to 125 and keep 3 for healthcheck requests. We prefer to scale the number of containers in our service rather than within a single container.

Below an extract of our uswsgi conf file :
[...]

We use socket listener for lambda call with a Nginx at front and we use http listener for internal healthcheck

I'm sorry, but I can't think of a proper way to do that with Granian, at least at the time being.

[nicolasbriere1]

Thanks for details about backlog/backpressure.
For healthcheck subject i think we gonna keep a Nginx in front to limit number of connections, if you don't have in mind a way to do it with Granian :)
Thanks for your time