4 ms·

It's always the first request in the waterfall that take the longest. All other requests are well under 100ms, except a few JS scripts that can go to 1s of load

by linkdd 2y ago

It's always the first request in the waterfall that take the longest. All other requests are well under 100ms, except a few JS scripts that can go to 1s of loading. I don't have any addon, I run a vanilla chrome+adblock. Is suspected the DNS as well, but `nslookup` is instantaneous most of the time.

deleted 2y ago
[deleted]
LinuxBender 2y ago
You mentioned adblock but do you also have antivirus? Some of them act as proxies and will look something up on the first request. Beyond that there are a million little things that can cause the first lookup to be slow. Overloaded firewall, edge router trying to purge stateful sessions, link duplex mismatches, disk cache enabled and disk being slow, MSS/MTU too high when using a VPN so the OS retrying with a smaller segment tcpdump would show this, initial window size too big microsoft will block this from people tweaking for high throughput. Try viewing the page with curl and see if that is slow. I would just be guessing at this point without knowing everything involved in the setup. If it's a network issue then Wireshark [1] may be able to highlight some issues. Also try another machine on your network and then take that machine to someone elses network like a coffee shop or bookstore that has public wifi. [1] - https://www.wireshark.org/ https://www.wireshark.org/
- linkdd 2y ago
  Those would not explain why only Github is impacted, except maybe the antivirus one. All machines on my network are impacted as well. I'm using BitDefender as an antivirus on all of them, I might try to disable it for Github and see if it fixes the issue.
  - LinuxBender 2y ago
    The only oddity I have noticed with Github is that if a network stack is optimized for high throughput large initial window size they seem to choke on it but you would know if you tuned for that on your router or each of your machines so it's probably not that. Have you by chance closed your browser, started tcpdump then fed the cap file into Wireshark and run the Analyze -> Expert Information tool? What OS are you using? If Linux, as root: tcpdump -i any -p -NNnn -s0 -v -c10000 -w /dev/shm/p443.cap port 443 all interfaces, not promisc, disable dns, full packet size, verbos, up to 10k packets, write to a ram disk to avoid dropping, port 443 both tcp and udp just in case we try quic and time out when that fails.

by linkdd 2y ago

deleted 2y ago

[deleted]

LinuxBender 2y ago

You mentioned adblock but do you also have antivirus? Some of them act as proxies and will look something up on the first request. Beyond that there are a million little things that can cause the first lookup to be slow. Overloaded firewall, edge router trying to purge stateful sessions, link duplex mismatches, disk cache enabled and disk being slow, MSS/MTU too high when using a VPN so the OS retrying with a smaller segment tcpdump would show this, initial window size too big microsoft will block this from people tweaking for high throughput. Try viewing the page with curl and see if that is slow. I would just be guessing at this point without knowing everything involved in the setup. If it's a network issue then Wireshark [1] may be able to highlight some issues. Also try another machine on your network and then take that machine to someone elses network like a coffee shop or bookstore that has public wifi. [1] - https://www.wireshark.org/ https://www.wireshark.org/

linkdd 2y ago
Those would not explain why only Github is impacted, except maybe the antivirus one. All machines on my network are impacted as well. I'm using BitDefender as an antivirus on all of them, I might try to disable it for Github and see if it fixes the issue.
- LinuxBender 2y ago
  The only oddity I have noticed with Github is that if a network stack is optimized for high throughput large initial window size they seem to choke on it but you would know if you tuned for that on your router or each of your machines so it's probably not that. Have you by chance closed your browser, started tcpdump then fed the cap file into Wireshark and run the Analyze -> Expert Information tool? What OS are you using? If Linux, as root: tcpdump -i any -p -NNnn -s0 -v -c10000 -w /dev/shm/p443.cap port 443 all interfaces, not promisc, disable dns, full packet size, verbos, up to 10k packets, write to a ram disk to avoid dropping, port 443 both tcp and udp just in case we try quic and time out when that fails.