Skip to content

How do I troubleshoot and optimize performance issues for my Transfer Family SFTP server?

8 minute read
0

My AWS Transfer Family Secure File Transfer Protocol (SFTP) server has slow file transfers, high latency, and intermittent connectivity issues to my SFTP client. I want to troubleshoot and optimize these performance issues for my SFTP server.

Resolution

Use network diagnostic tools to identify SFTP server performance issues

Use the Transfer Family console to access your Transfer Family SFTP server endpoint. If your Transfer Family server uses a virtual private cloud (VPC) endpoint, then find the DNS name of your VPC endpoint that corresponds with your Transfer Family server.

To diagnose and troubleshoot network performance issues with your Transfer Family SFTP server, use one or more of the following methods.

Use tcpdump to capture and analyze network traffic

It's a best practice to initiate packet capture on your network interfaces before you troubleshoot performance and latency issues for Transfer Family SFTP servers.

To capture the TCP port 22 traffic and save the output in a pcap file, run the following tcpdump command:

sudo tcpdump -i eth0 port 22 -s0 -w sftpcapture.pcap

Note: Replace eth0 with the interface that you configured in your environment.

In the output of the command, check the timestamps between packets to identify delays or irregularities.

Use My Traceroute to diagnose network latency and packet loss

My Traceroute (MTR) continuously monitors the network path between the client and server and provides details on packet loss and latency.

For Transfer Family SFTP-activated servers, run the following mtr command to perform the MTR performance test:

mtr -n -T -c 200 sftp-server-endpoint -P 22 --report

Note: Replace sftp-server-endpoint with your SFTP server's endpoint. To change the port, replace 22 with your port.

Example output for mtr command:

HOST: ip-10-0-1-100.ap-south-1    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ???                       100.0   200    0.0   0.0   0.0   0.0   0.0
  2.|-- ???                       100.0   200    0.0   0.0   0.0   0.0   0.0
  3.|-- ???                       100.0   200    0.0   0.0   0.0   0.0   0.0
  4.|-- ???                       100.0   200    0.0   0.0   0.0   0.0   0.0
  5.|-- 240.4.192.5                0.0%   200    0.3   0.5   0.2  51.1   3.7                     
  6.|-- 242.13.1.195               0.0%   200    1.4   2.8   0.5  46.2   6.2                                                              
  7.|-- 240.0.236.35               0.0%   200  185.4 343.3 183.8 1929. 442.9                                        
  8.|-- 242.13.126.1               0.0%   200  197.1 188.6 183.8 226.5   6.5                                      
  9.|-- 240.4.116.106              0.0%   200  186.1 186.1 183.9 191.0   1.5                                                             
 10.|-- 240.0.28.16               87.0%   200  189.0 186.8 184.1 189.2   1.4                     
 11.|-- 34.235.46.57               4.5%   200  189.1 185.7 183.8 189.2   1.2

Review the MTR test output to check your destination hop first and work backwards to identify where issues begin. Look for packet loss and latency at the final hop, and then confirm the that the final hop matches your intended destination. Look for sudden spikes in the Avg and Wrst columns. Sudden spikes show network bottlenecks or routing problems that require further client-side investigation.

Use traceroute to identify routing issues

To network the path between a client and a server, run the following traceroute command:

sudo traceroute -n -T -p 22 sftp-server-endpoint

Note: Replace sftp-server-endpoint with your SFTP server's endpoint. Replace 22 with your port.

Example output for traceroute command:

1 * * *
2 * * *
3 * * *
4 * * *
5 240.4.192.4 0.199 ms 0.190 ms 240.4.192.6 0.192 ms
6 242.13.0.199 1.328 ms 242.13.0.69 10.007 ms 242.13.0.193 1.093 ms
7 240.0.184.34 185.206 ms 240.0.236.34 184.032 ms 240.0.184.34 185.292 ms
8 242.2.212.33 186.242 ms 242.3.85.161 186.147 ms 242.2.213.33 186.095 ms
9 240.0.160.44 187.570 ms 240.0.160.47 189.964 ms 240.0.160.9 184.179 ms
10 241.0.11.214 188.132 ms 241.0.11.204 184.478 ms *
11 44.218.201.163 186.145 ms 185.897 ms 187.554 ms
12 * * *
13 44.218.201.163 188.708 ms 186.378 ms *
14 44.218.201.163 189.314 ms 191.099 ms 187.291 ms

Check the output for latency increases between hops to make sure that they're consistent with your expected network distances. If you see repeated IP addresses or excessive latency spikes, then your network might have routing inefficiencies or congestion that affects performance.

Use hping3 to test TCP latency and packet loss

The hping3 command provides end-to-end packet loss and latency measurements over TCP connections. Also, the command tests whether you can reach the SFTP port. For more information, see hping3 on the Linux website.

To measure TCP latency and packet loss for your Transfer Family SFTP server, run the following hping3 command:

sudo hping3 -S -c 5 sftp-server-endpoint -p 22

Note: Replace sftp-server-endpoint with your SFTP server's endpoint. The preceding command sends 5 TCP Synchronize (SYN) packets to port 22 of the Transfer Family SFTP server.

Example output for the hping3 command:

len=46 ip=44.208.155.179 ttl=242 DF id=0 sport=22 flags=SA seq=0 win=26883 rtt=191.9 ms
len=46 ip=44.208.155.179 ttl=239 DF id=0 sport=22 flags=SA seq=1 win=26883 rtt=187.8 ms
len=46 ip=44.208.155.179 ttl=242 DF id=0 sport=22 flags=SA seq=2 win=26883 rtt=187.8 ms
len=46 ip=44.208.155.179 ttl=242 DF id=0 sport=22 flags=SA seq=3 win=26883 rtt=187.8 ms
len=46 ip=44.208.155.179 ttl=242 DF id=0 sport=22 flags=SA seq=4 win=26883 rtt=187.7 ms

--- s-example123456789.server.transfer.region.amazonaws.com hping statistic ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 187.7/188.6/191.9 ms

Check the output for packet loss, round-trip times, and irregular response times. Network congestion or firewalls that block traffic might drop packets or significantly increase latency.

Note: Rate-limiting or firewall rules might affect hping3 results. Make sure that you're authorized to use the hping3 command on networks or systems that you don't own or manage.

Improve file transfer performance for Transfer Family SFTP-activated servers

Compress and batch files for faster file transfers

To maximize the efficiency of your file transfer operations, use a combination of compression and batch techniques. Also, when possible, batch multiple files into a single archive, such as a TAR or ZIP file, to further optimize your transfers.

Note: In the following instructions, replace large-file.csv and batch-files.tar with the name and file extension of your file.

To compress your files, run the following gzip command:

gzip large-file.csv

Then, run the following put command to transfer the compressed file to your remote SFTP server:

sftp> put large-file.csv.gz

To batch several small text files into a single TAR file, run the following tar command:

tar -czvf batch-files.tar.gz file1.txt file2.txt file3.txt

Note: Replace file1.txt, file2.txt, and file3.txt with your files that you want to batch.

Then, run the following put command to transfer the file:

sftp> put batch-files.tar.gz

Use SFTP session multiplexing

SFTP session multiplexing allows multiple file transfers to share a single SFTP session. Transfer Family supports up to 10 concurrent multiplexed SFTP sessions per connection.

To configure your session to use multiplexing in OpenSSH-based SFTP clients, run the following sftp command:

sftp -o ControlMaster=auto -o ControlPath=/tmp/sftp-%h_%p_%r -i private-key-name sftpusername@serverID.server.transfer.region.amazonaws.com

Note: Replace private-key-name with the name of your private key and sftpusername with your SFTP username. Also, replace serverID with your Transfer Family server identifier and region with your AWS Region. The ControlMaster=auto parameter initiates a main connection that subsequent sessions can reuse. The ControlPath=/tmp/sftp-%h_%p_%r argument specifies the control socket's location and name format.

To check the status of your session's multiplexing, run the following ssh command:

ssh -O check sftpusername@serverID.server.transfer.region.amazonaws.com

Note: Replace sftpusername with your SFTP username, serverID with your Transfer Family server identifier, and region with your AWS Region.

If your output contains a process ID (PID), then the session multiplexing correctly works.

Note: To avoid connection problems to your Transfer Family SFTP-activated server, make sure that your ControlPath directory name is 108 characters or less. Also, make sure that you can access the ControlPath directory and only the owner has write permissions.

Use concurrency tuning and compression in SFTP clients to improve throughput

To maximize your available bandwidth and resources, use concurrency tuning to adjust the number of parallel transfers.

To use concurrency tuning and compression, run the following sftp command:

sftp -R 100 -C -i private-key sftpusername@sftp-server-endpoint

Note: Replace sftusername with your SFTP username and sftp-server-endpoint with you SFTP server's endpoint. The -R 100 option configures the SFTP client to allow up to 100 concurrent file transfers. The -C option turns on compression.

If your network has low bandwidth, then it's a best practice to use compression. For faster networks that have high bandwidth, it's a best practice to not use compression.

Related information

Improve throughput for internet facing file transfers using AWS Global Accelerator and AWS Transfer Family services

Minimize network latency with your AWS Transfer for SFTP servers

AWS OFFICIALUpdated a month ago