Not sure about tuning the network – that is out of my skill set – I am lucky at work to have a 1G connection to my desk so these sort of uploads are not an issue. From home I only have around 18M
so it is noticeable how long uploads take. You may want to look to see if you have intermediate hosts on your network – are you going through a transparent proxy?
If the user is using a VPN there is often a large overhead than you see on the local network – not just the “distance” he is away – but whatever security layer the VPN adds, and whether content goes through multiple different nodes to get to you. We have noticed
quite large differences with users going through VPNs having major issues. And remember that remotely many users will be using asymmetric connections – download is fast, upload is usually throttled to between 10 and 25% of the download speed.
James
From: eric tse <hfetse@xxxxxxxxx>
Sent: 29 October 2020 19:16
To: users@xxxxxxxxxxxxxxxx
Subject: Re: [users@httpd] Bad Gateway with large file upload [EXT]
Good afternoon James
Thank you very much for your help.
We are inside a working organization network.
I don't know if you guys have a little bit more extra tips/directions to tune the enterprise network,
if not, it is all okay for now.
Thank you very much for your help.
Is your test over a local network or over the internet. If the latter there is little you can do.
HTTP upload was never really designed for large files like this. That’s why more languages/frameworks put a limit on the size of uploads. And these are usually in the 5-10M size.
There are much better ways of transferring large files in web-browsers nowadays using clever _javascript_ which slices the file and a script which stitches the parts back together at your end – transfers are smaller and avoids time outs. Can also parallelize
them if required.
James
Hi community,
Thank you for your valuable hint again.
Can we tune something from chrome?
that can make chrome 147MB test works?
Or we need to tune our network infrastructure?
For now, I haven't been able to google anything yet.
Good morning,
Thanks for your excellent tip last night.
We have some significant turn around from an investigation perspective.
We’ve done some additional testing this morning and had a surprising result. Does this provide any hints to the cause?
Firefox 60 MB: bad gateway
Firefox 147 MB: bad gateway
Chrome 60 MB: success!
Chrome 147 MB: bad gateway
IE 11 60 MB: bad gateway
IE 11 147 MB: bad gateway
My client said that we’re bound to using IE 11 for this project, although Chrome was identified as a acceptable alternative.
For now we can ignore his comment for troubleshooting.
Is it a bug, or limitation, or work as designed?
Or something we can tune (like browser or network infrastructure?) ?
On 28 Oct 2020, at 18:05, eric tse <hfetse@xxxxxxxxx> wrote:
> We’re are getting a Bad Gateway error returned when trying to upload large files through an IE browser to our webserver.
Have you tried with a currently supported browser?
IE is on death watch.
--
If I were you boys, I wouldn't talk or even think about women.
'T'ain't good for your health.
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail:
users-help@xxxxxxxxxxxxxxxx
-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1
2BE.
--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
|
