SftpFileStream OpenAsync/CopyToAsync vs DownloadFile performance gap

[Rayzbam]

I didn't find issue with a useful answer to this comparison.

I'm trying to download files from SFTP Server (the platform i'm building can access multiple SFTP in a generic way).

I'm facing an issue where downloading a 10Mo file using SftpFileStream.OpenAsync with SftpFileStream.CopyToAsync is a nightmare.

To download this kind of file, i have to wait at least 45sec-60sec in average (same behavior using the synchronous CopyTo).

Seems to have an issue in the Read/ReadAsync of the SftpFileStream here.

After looking for a workaround, i found a potential solution was using the synchronous method to download a file.

And, unfortunately, this solution was indeed better (10-15sec for this 10Mo file) which is still low, but i can live with that, i'm not that familar with the protocol, maybe it's part of it.

In my case, where i have a lot of SFTP traffic, using a synchronous download is a bit annoying to be honest.

I can afford to wait 10-15sec (synchronous call), but i would like to use the asynchronous call.

When i'm looking at the implementations of both, it seems that "DownloadFile" tries to download chunk concurrently (with a Semaphore limit to 100) which the ReadAsync clearly don't do. So the async read is sequential and read stream sequentially according to the bufferSize (65536 even if i try to increase it).
Is my understanding good ? If so, why this behavior change between sync and async read ?

Is the issue known ? Is that even an issue ?

PS : I'm using the latest version : 2025.0.0

PS2 : It seems that this behavior is happening on some SFTP Server, not everyones. Let me know what you need on the server specs if it can be useful (i only have what is offers by the discover made by the connection)

[Rob-Hague]

Yes it is known - SftpFileStream issues one read request at a time. For DownloadFile, there is an internal type (SftpFileReader) which issues multiple read requests in parallel and is faster.

I imagine it was easier to implement the parallel version separately to SftpFileStream. Perhaps one day they could be combined in some way.

Note, the recently added DownloadFileAsync will also be slower because it is using SftpFileStream. It would take a bit of work to make SftpFileReader async so that DownloadFileAsync is on par with DownloadFile. In the meantime, your workaround is valid if not truly async

[Rayzbam]

Understood.

Do you know if this change is in the pipeline ? At any priority.
I can switch to the synchronous read, after reading the implementation the BeginDownloadFile seems a bit useless until it only start the work on a different thread, so it will be the same to call directly DownloadFile here.

Currently, async code is a must have, especially in a big load platform, it's a bit sad having to switch back to the synchronous implementation.

• Other issue is having to load the file in memory in every case (for example i have to put it on a blob storage)

[Rob-Hague]

I have been thinking on and off about how to bring DownloadFileAsync on the same plan as DownloadFile. But no guarantees, and priority does not really exist around here

Other issue is having to load the file in memory in every case

I don't see why this would be the case - you can pass it a FileStream or other kind of stream

[Rayzbam]

I have been thinking on and off about how to bring DownloadFileAsync on the same plan as DownloadFile. But no guarantees, and priority does not really exist around here

You probably right, didn't mean it like a potential backlog or something but if everyone was working on it or planned to work on it soon.

I don't see why this would be the case - you can pass it a FileStream or other kind of stream

Generally, when you want to store a file (or a blob in my case) you have to pass a stream, i wanted to pass the NetworkStream from the SFTP directly.
If i'm not wrong, with the synchronous way (without OpenRead or OpenReadAsync), i have to first download the file in a stream (like a MemoryStream) and then put this stream in my blob container. The stream in which i downloaded the file is, in this case, in memory; but i guess it's not all use cases i agree, mine is particular.