Channels, Websockets and 'Backpressure'

[hanks...@gmail.com]

 

Can someone help me understand the concept of websocket “backpressure” in a 
Django Channels project? What is it? How do diagnose it? At what level of 
the stack does it occur? How do I cure it? The docs are a little hazy on 
this.


I wired up a quick Channels project for my mid-sized website. Before 
deploying the project, I load-tested it with thor 
 and started scaling up. When I reached 
two Daphne processes and four worker processes, it seemed like I had enough 
power behind the project to handle the load on my site. It was able to 
handle 2000 simultaneous websocket connections without errors, according to 
thor. That should have been more than enough.


I deployed, and everything went fine for a while. After a bit, though, the 
websockets got slow and the server started to drop connections. Eventually 
the whole project stalled out. I looked through the Daphne logs and found a 
flurry of lines like this:


2016-12-01 14:35:14,513 WARNING WebSocket force closed for 
> websocket.send!QbxCqPhvyxVt due to receive backpressure


I restarted all the server and worker processes to no effect. I was able to 
put the project back online by manually deleting all the “asgi:*” keys in 
Redis. But then, after a while, the backpressure built up and everything 
crashed again.


The problem, I suppose, has something to do with the high frequency of 
messages that were to be passed via websocket in this particular project. A 
click triggers a message in each direction, and people were encouraged to 
click rapidly. So I probably have to throttle this, or else launch more 
workers and/or servers.


But I'd like to know what, specifically, triggers these “backpressure” 
disconnections, and where I might look to monitor them /before/ errors 
start to occur. In one of the Redis queues, I suppose? If so, which one(s) 
– inbound or outbound? I suppose my idea, here, is that I might be able to 
automatically scale up if the queues start to fill up.


Thank you in advance. Fun project!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/79eb8c4d-0223-4320-8295-c936ebc4a68f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Need to examine and act on old vs. new at .save() time

[hanks...@gmail.com]

 > But is costly when the field in question is foreign, no?  Mine's a
M2M.

Sure. There's probably no way around that, though, except for
judicious use of select_related.

https://docs.djangoproject.com/en/dev/ref/models/querysets/#select-related

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Need to examine and act on old vs. new at .save() time

[hanks...@gmail.com]

I go about this a different way, which is to monkeypatch the object
with the relevant initial values at __init__:

https://gist.github.com/1595055

Saves you a database call.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Figuring out what has changed at save()

[hanks...@gmail.com]

Sorry for the unwieldy title, but nothing else strikes me at the
moment.

I have a blog app -- a version of basic.blog, actually. There's a
field in the model called "status" with two options: "draft" and
"public."

What I want to do is trigger an action the first time (and /only/ the
first time) a particular instance is saved as "public."

So:

Write a post in the admin, save as draft --> No action
Edit the post some, save as draft again --> No action
Edit more, publish   --> Action triggered!
Edit again   --> No action.

How would I go about this? My thought is to override save(), but I
can't figure out how to inspect the instance at that point to
determine if the status attribute has changed since it was created. I
assume that this information must be in there somewhere, since it
seems like you'd need it to generate the SQL statement.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---