On Mon, Feb 15, 2016 at 10:41 PM, Pablo Conesa <p.conesa.mi...@gmail.com> wrote:
> Thanks James. answers in line: > > El lunes, 15 de febrero de 2016, 23:04:48 (UTC+1), James Schneider > escribió: >> >> >> >> On Mon, Feb 15, 2016 at 10:20 AM, Pablo Conesa <p.cones...@gmail.com> >> wrote: >> >>> Hi, I posted this in stackoverflow. Now I'm trying here: >>> http://stackoverflow.com/questions/35413649/file-upload-fails-with-slow-network-bandwith-in-django >>> >>> I've got a code working fine that uploads a file to a DJANGO server. >>> >>> It works fine on a fine connection. >>> >>> Now if, using fiddler to simulate a slow connection....page freezes >>> (Chrome pop up offering to kill the page). >>> >>> I've tested in different ways and the only factor that causes the error >>> is a slow upload speed. e.g. If I choose a wi-fi network it fails but over >>> the ethernet it works. >>> >>> File is 100MB!. >>> >>> python: 2.7.6 >>> >>> DJANGO: 1.5.5 or 1.9 (I updated to 1.9 and is not working either) >>> >>> Fiddler show -1 in the response, and says: "No response body". >>> >>> Any ideas? >>> >>> >> >> How long does the file upload work before receiving the error? >> > > There is no response from the server (fiddler returns -1, whatever this > means) > Well, no response from the server doesn't necessarily mean that there were no logs. Can you check the error and access logs of the server? Does Fiddler return an immediate response of -1, or does it seem like there is a timeout period? After a quick glance at Fiddler itself, are you using any customizations on the rules >> My guess is that Fiddler is attempting to use an HTTP chunked transfer to >> send the file 'slowly' (by rate-limiting the chunks it sends rather than >> traffic shaping the data stream itself), which is how modern JS libraries >> normally handle large file uploads. However, this takes advantage of >> features built into the HTTP 1.1 standard, and I'm not entirely sure >> whether or not the Django dev server fully implements HTTP 1.1. That would >> explain why you are getting a response body error (since the Django dev >> server probably doesn't understand chunked requests and doesn't know to >> expect more data). See https://code.djangoproject.com/ticket/25619 >> <https://www.google.com/url?q=https%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25619&sa=D&sntz=1&usg=AFQjCNH4D4wtKNpxg_c-DnWeAjGPKSk1hg> >> That's purely a guess though, as I'm not familiar with how Fiddler works, >> and Django's internal support for HTTP 1.1 is somewhat ambiguous. >> > > Don't know either details about FIddler..but what you are saying sounds > reasonable and in the right direction... > >> >> This type of testing should be done against the production server (which >> likely fully implements HTTP 1.1), not the Django dev server, since >> performance of the dev server cannot be correlated with a production server >> that implements threading and/or multiple worker processes. >> > > I've done this. Actually the bug was reported in production (apache > forwarding to guinicorn) > Hmm, Apache should handle that fine. It's had 1.1 support forever, and I don't believe it requires any special configuration. Might be related to gunicorn, though, if it is responsible for handling the chunked response. Found this to be similar to your issue: https://github.com/benoitc/gunicorn/issues/1125, although sadly no resolution. Might point you in the right direction, though. > > >> >> On a side note, though. If you plan to have users regularly upload large >> files (>2MB), you should seriously look in to implementing chunked uploads >> via a JS library. With a standard upload via a regular form, the worker >> process in your server handling the upload are dedicated to that upload >> until it finishes. Usually this is fine for small uploads, but for larger >> uploads that can take minutes or hours, it becomes a large problem even on >> a site with a small user base. If 5 users are uploading a large file, and >> you only have 5 worker processes running, then literally nobody can access >> your site until at least one of those uploads finishes. With chunked >> transfers, the file is broken up into pieces and sent as many small >> requests rather than a single large one. This allows a server worker >> process to process the small upload, then step away to serve other users, >> and then process the next small upload. The net result on a busy server is >> usually a slower response, but at least there is a response. >> > > Nice advice...I'll look into this. Do you know any nice example for that > JS library chunk upload. > >> >> Probably best to stick with your existing JS framework of choice if you are using one. All of the major ones have some version of a chunked uploader (JQuery and Angular), and I come across resumable.js fairly frequently. I've never personally had a need for one, so I can't really comment on them in any sort of detail or make a recommendation. -James -- 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/CA%2Be%2BciVzhoAHMYYre%2BKyg-5U06fuWotPb%2BfMzQQcuoTsdW55xA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
