SCP and SFTP can be quite different.
Putty has an SFTP command, psftp.exe, which is on its downloads page:
It might also be worth looking at the FTP log in Opus (available from the FTP menu at the top of the window) while doing the transfer, to see if anything is being reported there which might indicate why it's so slow.
Understood. I used PSFTP this time, and here are the updated results:
FileZilla - 32 MB/s
PSCP - 27 MB/s
PSFTP - 25 MB/s
DOpus - 0.4 MB/s
I am also looking at the FTP log, and there is nothing unusual (to my eyes), just listing and sending generic events:
Opening Connection [address:ip removed]
Server version: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.5
Using SSH protocol version 2
We claim version: SSH-2.0-PuTTY_Directory_Opus
Server supports delayed compression; will try this later
Doing Diffie-Hellman group exchange
Doing Diffie-Hellman key exchange with hash SHA-256
Host key fingerprint is:
ssh-rsa 2048 [removed info]
Initialised AES-256 SDCTR client->server encryption
Initialised HMAC-SHA-256 client->server MAC algorithm
Initialised AES-256 SDCTR server->client encryption
Initialised HMAC-SHA-256 server->client MAC algorithm
Sent password
Access granted
Initiating key re-exchange (enabling delayed compression)
Opening session as main channel
Doing Diffie-Hellman group exchange
Doing Diffie-Hellman key exchange with hash SHA-256
Initialised AES-256 SDCTR client->server encryption
Initialised HMAC-SHA-256 client->server MAC algorithm
Initialised zlib (RFC1950) compression
Initialised AES-256 SDCTR server->client encryption
Initialised HMAC-SHA-256 server->client MAC algorithm
Initialised zlib (RFC1950) decompression
Opened main channel
Started a shell/command
SSH: CTS CONNECTED
SSH: Listing Directory
SSH: List complete 24 files.
SSH: Listing Directory
SSH: List complete 41 files.
SSH: Listing Directory
SSH: List complete 24 files.
SSH: Sending [removed filename].7z
I also installed WinScp and did an upload test using SFTP (not scp); updated results:
| Program | Upload speed |
|---|---|
| FileZilla | 32 MB/s |
| SFTP via WinScp | 30 MB/s |
| PSCP | 27 MB/s |
| PSFTP | 25 MB/s |
| DOpus | 0.4 MB/s |
I think I've reproduced a situation where it's slow. We'll try and take a look, although it's likely not going to be something we change in the very short term. (We're thinking about switching SFTP libraries, as a longer-term project, but have not properly evaluated that yet as we're finishing several other pieces of work. Whether we do that or not, we'll look into this as part of that work.)
Thanks for the update @Leo
Can I request a refund for the feature until then, since it is of no use to me in its current state and I purchased it under the assumption that speed would match the free alternatives?
Please email sales, as I can only answer technical questions. Address is at the top of Common purchasing, upgrading and licensing questions
I wrote sales to ask for a refund and Greg told me they don't guarantee performance and mentioned there's a free trial. So there you go, I made a mistake by assuming the quality of the ftp add-on would match the high quality of the rest of the program.
Additional info:
Using DOpus FTP with Explicit TLS to the same server I get 45MB/s. Further evidence that it's DOpus's SFTP implementation that's the cause.
| Program | Upload speed |
|---|---|
| FileZilla SFTP | 32 MB/s |
| SFTP via WinScp | 30 MB/s |
| PSCP | 27 MB/s |
| PSFTP | 25 MB/s |
| DOpus FTP over TLS | 45 MB/s |
| DOpus SFTP | 0.4 MB/s |
I recently bought the ftp supplement and for sure it does everything I want except for that speed issue...
One thing I have noticed is that if I run sftp transfers in parallel I can then achieve my max upload speed which is around 6 mb/s but if I try to transfer all of them at once it will never go above 1.3 mb/s which is painfully slow.
It's the single thing where I ever ran into a roadblock on dopus so I hope this is in your checklist for the future.
I'm no expert but by looking at it I would say it's related to the way dopus handles the process of uploading files as other ftp clients do not encounter this issue.
It seems that other people have this problem and some not so I don't know... Let's hope for the best here.
I'm in same situation
sftp upload very slow, but download is normal speed
why?
Just wanted to add that this is affecting me as well. I max out at about 1.3 megabytes per second when I have 40 megabit upload. I can get around 5-6 megabytes up with other FTP apps.
how is this still an issue?
Why is it being ignored? We're all PRO members here..
It’s not being ignored, but we need to finish other work first.
Sorry Leo, that's very hard to believe when this thread alone is 7 years old.
Every time there's new release notes, I look to see if there's any update to FTP and the Sync stuff. It's the main reason I use DO. There never is and I wonder why you're working on the stuff you do when this poor experience remains - and when this is a premium extra.
I'm often syncing via SFTP to European servers (from Australia) and you really get to know how painfully slow this app is. Especially for directory reads as well - that can take longer than the uploads.
The only reason I stick with DO is I have a couple of dozen lister layouts saved for syncs which is a nice feature.
And since you deny the ignore comment - this forum has complaints about slow FTP dating back to 2007.
What would you call it?
OK, so seems I missed a few release notes with some mention of FTP.. nothing to address the speed issue - but the priority still seems broken.
We are going to completely replace the SFTP code, but that's not a small task and not one we're going to start until finishing other work.
The main driver for this isn't upload speed (although that definitely has become a problem for more people over the years as internet speeds get faster, while there seems to be a bottleneck due to latency in the code we're using), but the fact it's become difficult to update the code the existing SFTP component is based on. Choosing a component with better performance will be part of that process.
If you don't believe me then I don't know what else to say really.
Since it's not a high priority to fix this issue, and since it's a now well known and document issue, you should at least put a disclaimer on the add-on purchase page or stop selling it under the guise of being usable for sftp uploads.
There's a free trial so people can already test it works for them before buying.
Your implication that it's the users' fault for not finding out the add-on is broken because they didn't try the free trial is embarrassing.
The cherry on top is that you don't offer refunds for the broken add-on.
