Introduction
When observing slow downloads of artifactory from Artifactory, it is important to understand that while Artifactory's application layer handles the data stream, download speed is primarily governed by network components between the client and the application, or by backend storage/database performance.
In this article we will focus on isolating which network component is causing the slow download.
It is important to execute the steps below at the same time you are observing the slowness.
Troubleshooting steps:
-
Exec to the Artifactory VM host or pod. For Docker deployments, exec into the container.
-
Run a curl command using the localhost hostname and port 8082 to run the API directly against the Artifactory. This will help isolate all other components.
The curl command should look something like this
curl -o /dev/null -w "Total time: %{time_total}s\nSpeed:%{speed_download}B/s\n" -uadmin http://localhost:8082/artifactory/repo_name/path/to/file
#localhost must be HTTP If the download speed is faster than the one of the original client, we proved that this is not related to Artifactory and we can move to the next component.
-
In most environments there will be a reverse proxy, e.g Nginx, component. If that component is deployed on a different VM, we will exec into that machine and run 2 curl commands
a. First will be from the VM to the Artifactory VM using the Artifactory VM IP. This will help us determine if the slowness is between the two machines.
curl -o /dev/null -w "Total time: %{time_total}s\nSpeed:%{speed_download}B/s\n" -uadmin http://ARTIFACORY_IP:8082/artifacroy/repo_name/path/to/file b. Second, If the reverse proxy listens on port 80 we can run a curl command with localhost against it, like the command below.
curl -o /dev/null -w "Total time: %{time_total}s\nSpeed:%{speed_download}B/s\n" -uadmin http://localhost:80/artifacroy/repo_name/path/to/file If the download speed is slow in step ‘a’ then the issue lies in the network between the nginx machine and Artifactory.
If the download speed was slow in step ‘b’ this indicates that the Nginx configuration needs tuning.
-
If there is an additional layer of network, e.g ALB, we can bypass it by running a curl command directly against the reverse proxy using the host name and the port it is listening on, for example:
curl -o /dev/null -w "Total time: %{time_total}s\nSpeed:%{speed_download}B/s\n" -u https://HOST_NAME:443/artifactory/repo_name/path/to/file If that download speed is fast, the issue most likely lies in the ALB.
Conclusion
We can easily determine which network component is causing the slowness in download speed by isolating each component and running a download command against Artifactory.
Furthermore, if the slowness is only observed by one user or from one environment, it is most likely that the issue is caused by a network between that environment and the first component in the network layers in front of Artifactory (usually LB).
In all cases where the slowness is determined to be network-related, the recommended action is to reach out to your dedicated Network Team with the evidence gathered.
The only exception is if the bottleneck is confirmed to be the reverse proxy (Step 3.b).
In this scenario, you can attempt to resolve the issue directly by tuning the proxy settings (e.g., Nginx buffers, timeouts). See this article.