Start a new topic

Slow SFTP uploads when running CrushFTP in Linux - downloads and other OSes are fine

QPC Helpdesk @ Tue Feb 25 14:00:29 EET 2014
We are evaluating CrushFTP before purchasing an enterprise license. We really love the features and behavior so far but unfortunately, we're having a problem when trying to run it in Linux. When using SFTP, downloads run at several megabytes per second, but uploads average out to only about 530KB/sec over a local LAN. Plain FTP does not exhibit the issue.

We tried it first in CentOS 6.5, then FreeBSD. Both behaved identically with uploads vs. downloads. If we stop CrushFTP and start SSHd with a local account configured for SFTP, uploads run at 10-20MB/sec., so it doesn't seem like something about the system itself.

We then tried running CrushFTP on Windows 2008 R2 on the system and found that in that setup, SFTP uploads were very fast, running at several MB/sec. It seems like something specific to SFTP uploads while running CrushFTP on a Linux system. Has anyone else run into this issue?

spinkb @ Tue Feb 25 14:09:46 EET 2014
In your prefs, sftp port, ssh tab, remove all the ciphers in the list except the two AES based ciphers. Otherwise clients often "prefer" 3DES and its very CPU intensive and slow.

Thanks,
Ben
QPC Helpdesk @ Tue Feb 25 14:28:05 EET 2014
Thank you for the fast reply. I changed the list so it contained only "aes128-cbc,aes128-ctr" but unfortunately, it had no effect. Uploads stayed around 530KB/sec after Saving the changes and after rebooting and double-checking settings just to make sure. "ps aux" shows the CrushFTP process is only using single digits for CPU utilitization and around 6.6% memory utilization.

I did just discover that this seems to happen in FileZilla (on two different test systems) but not in WinSCP as the SFTP client. In WinSCP, it averages a more acceptable 3.8MB/sec to the same Linux server over the LAN. I'm not sure why FileZilla would perform so much worse only when connecting to CrushFTP on Linux and not on a Windows server.
spinkb @ Tue Feb 25 14:58:33 EET 2014
On my test system, I am doing SFTP at 25MB/sec upload, and 32MB/sec download.

128MB 25.6MB/s 00:05
128MB 32.0MB/s 00:04

So it can definitely go much faster than even your 3.8MB/sec.

Try a newer version of FZ? They occasionally have bugs in t eh client related to things like this. Try another client like CyberDuck.

Can you double check you change took effect as that is normally the issue with SFTP is those ciphers, and that is all. So it really just seems like its still using the old ciphers still...
QPC Helpdesk @ Tue Feb 25 15:15:29 EET 2014
I updated to the latest version of FileZilla but there was no change. I downloaded CyberDuck and it averages 7.8MB/sec which is faster still than WinSCP. I'd be less concerned about FileZilla performance if I didn't know that a few of our customers use it for non-batch jobs, but maybe they can live with the speed. It's just baffling that Windows server on the same system with CrushFTP is fine with FileZilla.

As for the ciphers, the change definitely took effect. When I hit save, the SFTP connection reset and I had also rebooted the server to make sure. I went back in to the web interface after and refreshed the page to make sure it's showing current information with just aes128-cbc,aes128-ctr listed.
spinkb @ Tue Feb 25 15:36:22 EET 2014
Possibly trying Java 6 versus Java 7 or Java 7 instead of Java 6 depending on what you currently are using.

Otherwise, not really sure what could cause that...

Thanks,
Ben
QPC Helpdesk @ Tue Feb 25 15:40:44 EET 2014
Thank you. We did try updating to the latest OpenJDK as well as uninstalling OpenJDK and trying Sun/Oracle's RPM of the latest 64bit Java 7 JRE but it had no effect. I'll see about going to version 6.
spinkb @ Tue Feb 25 15:43:22 EET 2014
OK, let me know some results if you find something.
QPC Helpdesk @ Wed Feb 26 17:11:49 EET 2014
Unfortunately, Java version 6 didn't help, either. We're proceeding anyway, so thanks for the help.
spinkb @ Thu Aug 07 10:42:14 EEST 2014
The fix for this for future reference ends up being tweaking the window space in the ssh daemon. Newer CrushFTP builds do this for you automatically, or on older builds, add this into the java arguments.

-Dssh.maxWindowSpace=10485760

Thanks,
Ben
I am running into the same issue. I expect SFTP to be significantly slower than say...  unencrypted FTP for example, but over HTTPS I am getting around 80Mb and over SFTP I'm getting 30Kb. That seems really off.

This is a fresh Ubuntu 14.04LTS install, Java 7 and CrushFTP 7.

You mentioned the Java arguments tweak. Where do I set that? In the Java settings or Crush somewhere?



I am starting Crush with the following in rc.local:
/var/opt/CrushFTP7_PC/crushftp_init.sh start





 

What is your latency from you to the server?


It could be exactly correct depending on your latency.  And I assume your referencing bytes and not bits?

Wow, you're working early.


Yes bits not bytes (that's why I used the tiny b).

Latency is not the issue because I am testing on the local network. Everything here is gigabit connections. My internet connection is 100Mb and most of the people who will utilize the server are on connections of 25Mb or lower so if I can get anywhere close to 25Mb that would be great.


Thanks

 

In your crushftp_init.sh file, modify the java lien starting CrushFTP.


Before the "-jar" put :


-Dssh.maxWindowSpace=10485760

Having a similar issue.  My server is running Centos 7.1.  


SFTP to CrushFTP averages right at 12 MB/s

SFTP to Centos (same box) averages 130 MB/s


I've tried with and without -Dssh.maxWindowSpace=10485760 with similar results.


CPU utilization (2 CPUs) is the same in both cases, topping out at around 35%.  4GB RAM, 1GB free.

Login to post a comment