Hi, To support file uploads or a large message body the http.request message could have an file_channel or body_channel (much like its reply_channel)? These would be something like http.request.file.Dj3Hd9J and would stream chunked file or body content in the same way as the http.response message with a more_content attribute.
Sam On Thursday, December 17, 2015 at 9:48:31 PM UTC, Andrew Godwin wrote: > > Yes, that is the idea. While it obviously adds overhead (a millisecond or > two in my first tests), it also adds natural load balancing between workers > and then lets us have the same architecture for websockets and normal HTTP. > > (The interface server does do all the HTTP parsing, so what gets sent over > is slightly less verbose than normal HTTP and needs less work to use, but > it's not a big saving) > > Andrew > > On Thu, Dec 17, 2015 at 9:01 PM, Anssi Kääriäinen <akaa...@gmail.com > <javascript:>> wrote: > >> Is the idea a large site using classic request-response architecture >> would get the requests at interface servers, these would then push the HTTP >> requests through channels to worker processes, which process the message >> and push the response through the channel backend back to the interface >> server and from there back to the client? >> >> - Anssi >> >> On Thursday, December 17, 2015, Andrew Godwin <and...@aeracode.org >> <javascript:>> wrote: >> >>> To address the points so far: >>> >>> - I'm not yet sure whether "traditional" WSGI mode would actually run >>> through the in memory backend or just be plugged in directly to the >>> existing code path; it really depends on how much code would need to be >>> moved around in either case. I'm pretty keen on keeping a raw-WSGI path >>> around for performance/compatability reasons, and so we can hard fail if >>> you try *any* channels use (right now the failure mode for trying to use >>> channels with the wsgi emulation is silent failure) >>> >>> - Streaming HTTP responses are already in the channels spec as chunked >>> messages; you just keep sending response-style messages with a flag saying >>> "there's more". >>> >>> - File uploads are more difficult, due to the nature of the worker model >>> (you can't guarantee all the messages will go to the same worker). My >>> current plan here is to revise the message spec to allow infinite size >>> messages and make the channel backend handle chunking in the best way >>> (write to shared disk, use lots of keys, etc), but if there are other >>> suggestions I'm open. This would also let people return large http >>> responses without having to worry about size limits. >>> >>> - Alternative serialisation formats will be looked into; it's up to the >>> channel backend what to use, I just chose JSON as our previous research >>> into this at work showed that it was actually the fastest overall due to >>> the fact it has a pure C implementation, but that's a year or two old. >>> Whatever is chosen needs large support and forwards compatability, however. >>> The message format is deliberately specified as JSON-capable structures >>> (dicts, lists, strings) as it's assumed any serialisation format can handle >>> this, and so it can be portable across backends. >>> >>> - I thought SCRIPT_NAME was basically unused by anyone these days, but >>> hey, happy to be proved wrong. Do we have any usage numbers on it to know >>> if we'd need it for a new standalone server to implement? It's really not >>> hard to add it into the request format, just thought it was one of those >>> CGI remnants we might finally be able to kill. >>> >>> Andrew >>> >>> On Thu, Dec 17, 2015 at 6:32 PM, Anssi Kääriäinen <akaar...@gmail.com> >>> wrote: >>> >>>> On Thursday, December 17, 2015, Carl Meyer <c...@oddbird.net> wrote: >>>> >>>>> Hi Andrew, >>>> >>>> >>>>> - I share Mark's concern about the performance (latency, specifically) >>>>> implications for projects that want to keep deploying old-style, given >>>>> all the new serialization that would now be in the request path. I >>>>> think >>>>> some further discussion of this, with real benchmark numbers to refer >>>>> to, is a prerequisite to considering Channels as a candidate for Django >>>>> 1.10. To take a parallel from Python, Guido has always said that he >>>>> won't consider removing the GIL unless it can be done without >>>>> penalizing >>>>> single-threaded code. If you think a different approach makes sense >>>>> here >>>>> (that is, that it's OK to penalize the simple cases in order to >>>>> facilitate the less-simple ones), can you explain your reasons for that >>>>> position? >>>>> >>>> >>>> We would also need some form of streamed messages for streamed http >>>> responses. >>>> >>>> Is it possible to handle old-style http the way it has always been >>>> handled? >>>> >>>> - Anssi >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers (Contributions to Django itself)" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to django-developers+unsubscr...@googlegroups.com. >>>> To post to this group, send email to django-developers@googlegroups.com >>>> . >>>> Visit this group at https://groups.google.com/group/django-developers. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/CALMtK1Gz%3DaYMLyFW2da2C6Wo_-c_V2T_4p6K9eh0vwrKB91dKw%40mail.gmail.com >>>> >>>> <https://groups.google.com/d/msgid/django-developers/CALMtK1Gz%3DaYMLyFW2da2C6Wo_-c_V2T_4p6K9eh0vwrKB91dKw%40mail.gmail.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 developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-developers+unsubscr...@googlegroups.com. >>> To post to this group, send email to django-developers@googlegroups.com. >>> Visit this group at https://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/CAFwN1upm8N8tOhCdAgPEbYbBO6MU%2BmnEQ%3D%3Dp6EmW75%3DbNXHkfg%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/django-developers/CAFwN1upm8N8tOhCdAgPEbYbBO6MU%2BmnEQ%3D%3Dp6EmW75%3DbNXHkfg%40mail.gmail.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 developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> Visit this group at https://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CALMtK1FOVa6K-MMsZ9vACfcw0w0KHwdCXJ2vxu7_Y5Q9PHJ6Gg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/django-developers/CALMtK1FOVa6K-MMsZ9vACfcw0w0KHwdCXJ2vxu7_Y5Q9PHJ6Gg%40mail.gmail.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 developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9c7233b8-64b2-454a-8b13-1c8e33b77214%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
