Slow uploads through BIG-IP
We have a web app running behind an F5 BIG-IP running version 11.6.0. The app is responsible for storing large binary files so it regularly gets large uploads and downloads. During initial setup a while ago I was able to get the download speeds increased to around 30Mbps which was acceptable. We did this by updating the TCP profiles and found the Memory Management settings directly correlated to significant improvements. Below is what we're using for both client and server TCP profiles with the tcp-lan-optimized and tcp-wan-optimized profiles being the parent. We also have no iRules applied to this VIP. Proxy Buffer High: 2516544 Proxy Buffer Low: 1258272 Receive Window: 1179630 Send Buffer: 1179630 Nagle: Disabled The receive window and send buffer are the ones that have direct correlation to the increases in download speeds. I've been trying to increase our upload speeds, but can't seem to find any setting that makes a difference. If I upload directly from the node the app runs on itself I'm getting 30M+ upload speeds, but my desktop running curl shows around 975k on average. Output from curl on upload and download is below. Any suggestions on what to try next or how to troubleshoot? C:\Temp>curl -u user -T file.mp4 -X PUT https://app.example.com/abc/test-generic/ > nul Enter host password for user 'user': % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 5 616M 0 0 5 34.7M 0 975k 0:10:46 0:00:36 0:10:10 1025k^C C:\Temp>curl -O https://app.example.com/abc/test-generic/file.rpm > nul % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 117M 100 117M 0 0 22.1M 0 0:00:05 0:00:05 --:--:-- 26.1M
Large file uploads with a OneConnect profile
I have fairly vanilla http virtual server (running 11.6.1) sitting infront of a websphere application (4 nodes load balanced). The config is as follows: TCP: default tcp HTTP profile: default http Source Address: Auto Map Rewrite profile: myRewrite Access Profile: myAccessProfile OneConnect Profile: default oneConnect Session persistence: Cookie I'm having an issue with Internet Explorer 11. When a user uploads a large file (1GB or larger) via the interface. After every 900-950MB the upload stops and the file is shown as partially complete. The user can resume the upload and it does continue, but I need to stop the upload from pausing mid upload. The upload will successfully complete in one attempt if the user does it with Chrome. The web application uses a jQuery tool to do the file upload. The file is chunked up into 10MB segments and sent through in multiple http requests. I added some log outputs to various events as a first step, and it was the LB events that I found most interesting. when LB_SELECTED { log local0. "member selected: [LB::server]" } when SERVER_CONNECTED { log local0. "from [IP::client_addr]:[TCP::client_port] to vip [IP::local_addr]:[TCP::local_port]" } when LB_FAILED { log local0. "whoops LB failed - [event info]" } With the OneConnect profile in place, I see the LB_SELECTED being fired for each of the 10MB segments being sent through as you would expect. When it gets up around the 900MB mark it seems to establishes a new TCP connection (this takes about 70 seconds). I can see the SERVER_CONNECTED event firing and the client port has changed. This occurs when using both IE and Chrome. However when using IE I also see a LB_FAILED event at the same time, but the [event info] is blank. It's at this point the download pauses in IE. I fired up tcpdump and captured the entire upload process. Right before the new TCP connection is established I can see a RST,ACK sent from the F5 VIP address to the client. I searched the entire capture and it is the only RST, so it doesn't look to have come from the node. I checked the logs to see if we had encountered a port exhaustion (https://support.f5.com/csp/article/K7820), but there was nothing in the logs. There's also no logs stating that the node/pool has been marked as down. Does anyone have any thoughts as to why a new connection would be established? There is clearly traffic being sent down the connection, so idle timeout shouldn't be an issue. Thanks for getting this far 🙂 Cheers, Simon