Hi Jamie, I don't use Stack Overflow, so feel free to answer there yourself for posterity.
As for the load-balancing bit, what I mean is that because the Channels model is that all workers draw from a single work-queue, there are no balancing artifacts like you can get from a plain round-robin model; the tradeoff being, of course, more limited capacity. If you wanted separate workers for the HTTP and WebSocket handling, right now that can be one using the --only-channels and --exclude-channels arguments to runworker to specialise them. This will change with the rewrite as the handling will be local to the socket-terminating process like WSGI, so you will be able to load balance with Nginx/HAProxy like anything else. There's no dynamic scaling support at all because that's something that's far too specialised for a framework to ship. As for the rewrite, the main source of info right now is my blog post at https://www.aeracode.org/2017/7/11/towards-channels-20/ - more docs will come as we finalise the design, but that will take a bit longer. Andrew On Tue, Aug 8, 2017 at 1:43 PM, Jamie Counsell <jamiecouns...@me.com> wrote: > Hey Andrew, > > Thanks for the prompt response. If you'd like to post this as an answer to the > StackOverflow question > <https://stackoverflow.com/questions/45122724/load-spike-protection-for-django-channels>, > that would be great. Otherwise, I will answer my own question. > > I'm not sure what you mean by workers being load-balanced? Right now, when > I run daphne, I run several workers on a system level using the runworker > command. What if I wanted to start more workers under certain conditions? > Also, if workers are all assigned to work on every channel, then I agree > this is the case, but if I want to make sure that the HTTP channel never > fails to respond even if the websocket channel gets hammered, I can start a > worker that will only work on the HTTP channels. Is there any way to do > this dynamically? > > I understand that this is out of scope of channels, and I appreciate your > willingness to work with me on this. The main thing I think would be > helpful is middleware that could be assigned to each channel, similar to > Django's current HTTP middleware. > > Lastly, do you have any documentation or public discussions on this > rewrite? I'm working on a project right now that I'm hoping will see the > light of day in production, but would hate to get version-locked if the > rewrite changes too much. > > Thank you! And keep up the great work. > > Jamie > > On Tuesday, 8 August 2017 15:45:03 UTC-4, Andrew Godwin wrote: >> >> Hi Jamie, >> >> At the moment Channels has quite limited support for throttling - it >> pretty much consists of an adjustable channel size for incoming connections >> which, when full, will cause the server to return a 503 error. Workers are >> load-balanced based on availability due to the channels design, so there's >> no risk of a worker gaining a larger queue than others. >> >> Providing more advanced DoS or DDoS protection is probably not something >> we can do within the scope of Channels itself, but I'd like to make sure we >> provide the appropriate hooks. Were there particular things you think we >> could implement that would help you write some of the things you need? >> >> (It's also worth bearing in mind that right now we're changing the >> worker/consumer layout substantially as part of a major rewrite, which is >> going to mean different considerations when scaling, so I don't want to >> give too precise advice just yet) >> >> Andrew >> >> On Tue, Aug 8, 2017 at 10:19 AM, Jamie Counsell <jamiec...@me.com> wrote: >> >>> Hey folks, >>> >>> I'm working on a Django Channels project and was wondering if there was >>> (or was a roadmap for) features that could help us control load issues at >>> the application level. I asked on StackOverflow >>> <https://stackoverflow.com/questions/45122724/load-spike-protection-for-django-channels/> >>> but >>> made the mistake of including the term "DDoS" and so I received a bunch of >>> generic DDoS explanations. I know that DDoS is in some cases a different >>> beast entirely, but I also think that smaller attacks or load issues >>> related to any traffic increase could be handled at the application level. >>> For example, Django Rest Framework's Throttling support provides a great >>> way to do things like prioritize or not throttle authenticated users, but >>> throttle anonymous users. I'm wondering if Channels or Daphne has support >>> for something like: >>> >>> - Throttling (per channel, ideally) >>> - Dynamic worker assignment based on queue size, response time, etc. >>> - Middleware to provide priority to requests based on some metric >>> (authenticated, for example) >>> - Priority decorators for consumers that could tell workers not to >>> run certain consumers if the queue is large >>> >>> Right now I have a design that could cause the socket channel to >>> experience high latency or a full queue in certain situations. This is fine >>> as there is very little that it does that is critical, but I've had to move >>> a specific feature to the HTTP layer to make sure it doesn't get mixed up >>> in the websocket traffic. >>> >>> Again, I'm not specifically looking at protecting the site against a >>> malicious attack - accidental load spikes are probably more common and can >>> happen for lots of reasons like slashdotting >>> <https://en.wikipedia.org/wiki/Slashdot_effect>. >>> >>> I'm happy to discuss this in more detail, but am just working on first >>> finding a community of people that can provide some educated insight. >>> >>> Thanks! >>> >>> -- >>> 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...@googlegroups.com. >>> To post to this group, send email to django...@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/ms >>> gid/django-users/147c4fdc-b051-4918-93cb-7732096e46ca%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-users/147c4fdc-b051-4918-93cb-7732096e46ca%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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/871e001c-6a58-4e76-b5c3-1ef9d7fc1535%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/871e001c-6a58-4e76-b5c3-1ef9d7fc1535%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAFwN1uoXxj9dv%2B%3D6B5%2B4qZ4e%2BVXdf_tCVgW5QLZuALqdbOXVoQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
