Strange slow email and jpg/pdf downloads
In the last month I have been experiencing slow email downloads, plus slow jpg and pdf downloads from within a Wordpress site I run.
I first noticed this on downloading emails (POP or IMAP) containing large attachments (several MB), with the download speed being 500 kbps on a FTTC broadband line running at 40 Mbps. Later I found that jpgs and pdfs (0.5 MB to 4 MB) were also slow - at the same rate.
Initial thoughts were that this was comms, dropped packets etc. or traffic shaping by nodes between me and the ISP. But all my other email account and web downloads are fine, with other providers such as gmx, gmail, Yahoo and Outlook.com and another domain on a different shared server with the same ISP that hosts my domain. Direct web downloads (by browser) of files from the affected domain are fine provided they are not beneath the Wordpress tree. Other users (including the ISP) cannot replicate the problem when I set up a test email for them. If I tether my laptop to a mobile phone (5Mbps connection), the problem also goes away, or at least I get the emails at connection speed.
I then found that downloads of files on my domain via cPanel File Manager were also slow (including files outside the Wordpress space), plus jpgs and pdfs off the Wordpress site were all slow, and all the same speed - 500 kbps - which is a bit odd in itself to have the same speed limit as the email.
On the basis of a possible network issue, I ran Wireshark on the email dowloads and got a bunch of errors:
TCP ACKed unseen segment
TCP Out-Of-Order ACK
TCP Previous segment not captured incl ACKs
TCP Ignored unknown record
DS-ACK sequence incl Dup ACKs
TCP Fast Retransmission
TCP Retransmission ACKs
TCP Dup ACKs
Wireshark dumps of jpeg/pdf downloads are similar. Does look like dropped packets in some way, but where and why? ISP says none of the 250+ users on the same shared server have reported any problem.
The issue arose after a server migration from an older to a newer server in the ISP. Obviously suspicion falls on a configuration in the new server. We found one thing, that the new server was defaulting to TLS1.2. On changing that to TLS 1.3 the error count for my test email (7.5 MB encoded) dropped from 17,000 to 6,000 errors.
But thus far the ISP has checked and rechecked and cannot find anything wrong. The server details are:
cPanel Version 118.0 (build 15)
Apache Version 2.4.62
MySQL Version 8.0.39-cll-lve
Architecture x86_64
Operating System linux
So it looks to me like a configuration issue somewhere, buffer size, stack size, with a common thread of it being stuff run under cPanel.
Any advice most welcome!
Thanks
p.s. I have eliminated the client email/web user by testing and getting the same result on other computers & a tablet, using the same broadband connection.
-
Hey there! I'm not sure I'm going to be much help either - there isn't anything inside cPanel that would limit download speeds, and especially not across different areas such as File Manager and email, as those are unrelated tools.
Have you confirmed that it is related to your location?
0 -
I did find some info (e.g. https://docs.cpanel.net/knowledge-base/cpanel-product/the-cpanel-config-file/ and https://docs.cpanel.net/whm/server-configuration/tweak-settings/#system ) indicating certain configurable elements to the back end of cPanel. Not sure if anything is at a level that would affect TCP and TLS behaviour.
Yes, it's sort of related to my location, but also not - it seems to be the particular combination of me and the hosting company:
- From me (via my broadband) to the shared server on which the ISP (i.e. by which I mean hosting company) hosts my mail and web space - problem exists
- From me to a different shared server at the same ISP and in the same rack - problem does not occur
- From any other location/user to the shared server I'm on - problem is not reproducible - and of course this includes the ISP themselves whose office is remote from the server farm. This is what's stopping them getting any further.
- From me to any other internet location (multiple different mainstream mail servers, web pages, FTP, etc) - problem does not occur
- From me to "my" server using different mail clients and machines to my normal laptop connection and from my normal location - problem occurs
- From me to "my" shared server using a tethered mobile connection (5 Mbps) problem does not occur
The Wireshark error messages indicated a clear loss of packets somewhere. Whilst it doesn't appear to be location related, it could be speed-related. My broadband is 40 Mbps, and I've had the problem on next door's broadband at 80 Mbps (different broadband supplier). But the other external users have been on much faster connections (FTTP etc), plus the one slower connection (mobile tethering) does not show the problem. So it feels to me like something in the comms set-up works well at fast speeds and slow speeds but not at intermediate speeds.
I and the ISP (who by the way are the best I've ever used and have been very solid for several years now) are stumped. Any suggestions gratefully received!
0 -
The only thought I have would be running an "mtr" from your location to the server in question. That would show which specific hop along the network is experiencing slowness, and may help to narrow down the issue a bit.
0 -
Never heard of mtr before, thanks. Have run WinMTR for a fair few minutes and the results are pretty much identical to a tracert, with no packets dropped at any node on the way (except ? for two nodes which don't respond to ICMP packets.)
To get round the ICMP non-response I also ran traceTCP which is the same result except that one of the big BT UK Core nodes does (occasionally) respond (the other non-responsive on ICMP is non-responsive on TCP packets too).
I ran ping for as large a packet as I can get through the MTU on my system, less packet overhead. No difference.
Stumped.
Thanks anyway
0 -
I'm sorry I don't have more ideas on that one - since cPanel doesn't limit the speed anywhere it has to be somewhere else on the network/system.
0 -
Thanks for your input.
0
Please sign in to leave a comment.
Comments
6 comments