Purpose

Your connection when cloning, pushing or pulling from Bitbucket Cloud seems really slow. You checked the site status at http://status.bitbucket.org and the status doesn't show any downtime or issues. Bitbucket Cloud uses NTT/Verio, a top-level ISP and hosting service. NTT/Verio provides some of the fastest connections possible globally. Problems can exist anywhere between multiple points.  So, it is difficult for Bitbucket Cloud Support to troubleshoot your specific network connection issues.

Below, we've listed common troubleshooting steps to help you self-diagnose your issues.

Solution

Diagnostic Steps

Step 1. Test your connection speed

You should see speeds around 200+ KiB/sec or (much) faster consistently from anywhere globally. To test your connection, use Git and the public Git repository mirror we host.

1. Ensure you have Git setup. 
   If you aren't using Git, you will need it. Please follow our setup guide to get everything set up.

2. Clone the  Git mirror using https. 

   $ git clone https://bitbucket.org/mirror/git.git
   Cloning into 'git'...
   remote: Counting objects: 156094, done.
   remote: Compressing objects: 100% (43595/43595), done.
   remote: Total 156094 (delta 115504), reused 150622 (delta 110685)
   Receiving objects: 100% (156094/156094), 36.57 MiB | 1.21 MiB/s, done.
   Resolving deltas: 100% (115504/115504), done.

3. Examine the output for this line:
   

   Receiving objects: 100% (156094/156094), 36.57 MiB | 1.21 MiB/s, done.

   The speed in this test was 1.21 MiB/s which is very fast. Any number equal to or larger than 200 KiB/s is a good result.

Let this serve as your benchmark to target. If you aren't seeing 200 KiB/s or faster, continue troubleshooting. 

Step 2. Isolate the source

Try to find out the source of the slower connection. Is it your computer, the environment on your computer, or the network the computer is on.

Is your computer the problem?

1. Go to another computer on your network.
2. Run the clone mirror test.
3. Is the speed significantly faster on the other machine
   • Yes? Then, likely the slowness you are experiencing is a result of your computer or its environment. Check the common causes below to further narrow down the issue.
   • No? Go on to check if your network is the problem.

Is your network the problem?

1. Go to a computer outside your network.
   For example, if your office has the issue, check your home connection or even your cell using tethering. 
2. Run the clone mirror test.
3. Is the speed significantly faster on this network?
   
   • Yes? Then, likely the slowness you are experiencing on the original machine is caused by your network. Check the common causes below to further narrow down the issue.
   • No? Go on to check the other common causes.

Step 3. Check the common causes

Once you've narrowed down the issue to a specific machine or machines, double check the following 

• Check all network and configuration settings between the two machines if you see slowness in only a single machine
  • Network configuration (DHCP, DNS)

    • DNS

      Try changing your DNS server to Google DNS if you're having issues trying to resolve the site:

      8.8.8.8

      8.8.4.4

  • Git configuration
• Check all wired and wireless interfaces physically. Sometimes a simple cable issue can cause significant slowness or a flaky network connection. 
• For wireless networks, try cloning when very near to your access point.
• Connect your computer directly to your internet connection, if possible. This will rule out any intermediate networking equipment.

• If you're in an office with an issue, contact your local network administrator to be sure that they aren't blocking/slowing connections. You can sometimes test this by running a ping or traceroute to bitbucket.org. You should see ~ 10-100ms responses depending on where you are located geographically.

  ping bitbucket.org

  

  traceroute bitbucket.org

Step 4. Check the uncommon issues

• Check latency between major internet backbones (AT&T, Cogent, NTT, Sprint, Verizon, Level3, etc.) – http://www.internetpulse.net/
• Check our status page to ensure we haven't reported any outages/issues: http://status.bitbucket.org

• Customer Routing from NTT

  • First acquire your IP address (http://www.whatsmyip.net/)
  • Use the IP address and go to http://www.us.ntt.net/support/looking-glass/ (NTT is our network provider):
    • Select the 'Ashburn, VA' Router
    • Select 'BGP' (Border Gateway Protocol)
    • Enter your IP
    • Submit
  • Once you receive this output, please send to our support team – also, we encourage to contact your ISP as well if you are noticing difficulty connecting to bitbucket.org or any other Atlassian products.

Step 5.Collect information

There could many other issues affecting your network connection to us and may require more in-depth troubleshooting. We recommend always learning more about these suggestions before installing any utilities or executing any of these commands. Note that Bitbucket Cloud support cannot help you with these tools and this guide is only to help you troubleshoot.

Windows

Check the MTU

If you're on DSL, a possible issue could be a larger than expected MTU size being forced somewhere along the way, this can cause packet fragmentation and loss in some cases. You can check this with a utility called mturoute.exe – http://www.elifulkerson.com/projects/mturoute.php

 mturoute.exe -f -t bitbucket.org

You should see output similar to the below:

Windows packet size auto-tuning:

There can be an issue where speeds on Windows machines can be slower compared to Linux/OSX. This is when window packet size auto tuning is disabled. It can be re-enabled with the following command:

C:\> netsh interface tcp show global

C:\> netsh int tcp set global autotuninglevel=normal

OSX

Check the ideal MTU

If you're on DSL, a possible issue could be a larger than expected MTU size being forced somewhere along the way, this can cause packet fragmentation and loss in some cases. To check this on your local machine, do the following:

ping -s 1500 -D google.com

If you get a message similar to the below, then your MTU is set higher than it should be for your connection. Try lowering it incrementally until you no longer see these messages.

ping -s 1500 -D google.com
PING google.com (74.125.239.39): 2000 data bytes
ping: sendto: Message too long
ping: sendto: Message too long

Forcing IPv4:

Often times, newer machines will default to IPv6. The problem is that not all routers or ISPs are setup correctly to handle IPv6 traffic, causing delays. If you're using SSH, you can force your connection to use IPv4 to improve speeds by adding the following entry to your ~/.ssh/config file:

AddressFamily inet

Linux

If you're on DSL, a possible issue could be a larger than expected MTU size being forced somewhere along the way, this can cause packet fragmentation and loss in some cases. You can check this with a utility called tracepath, available from the iputils package – http://www.linuxfoundation.org/collaborate/workgroups/networking/iputils

• Install tcptraceroute on the affected machine(s)
• Your Operating System and Version
• Your network setup (Wired/Wireless)

Summary

Ultimately, the people who will be able to help resolve your issues are your local ISP. They have direct access to the same network as you and are in a much better position to help troubleshoot possible issues. 

Helpful Links

There are numerous guides out there to help you troubleshoot:

Troubleshooting path MTU problems

Traceroute

A discussion and explanation of MTU and path discovery

http://www.elifulkerson.com/projects/mturoute.php

http://kb.linksys.com/Linksys/GetArticle.aspx?docid=fbf8e8564632422eaa8ea80bf9dcba64_386.xml&pid=8&converted=0

Fix slow SSH connections (delays) on Mac OS X