Slow SFTP transfer on Large Files / Timeout = 0
I had an issue that was bugging me over the weekend. I finally figured it out and thought I'd post it in case someone else ran into the same problem I did. The issue was that from the WinSCP GUI, transferring a large file to my server was pretty quick. However, doing the same transfer from the .net assembly took 100x longer. So here's what happened:
I was trying to be good, and I had wrapped the WinSCP objects with my own to limit 3rd party code touches. However, what I did not realize, was that my object's SessionOptions.Timeout defaulted to 0, and I cheerfully passed the value to WinSCP - overriding it's default of 15. So consequently, my sessions were dying constantly, and then I was being relogged in and the transfer would resume. Obviously all of those login/resume handshakes were crippling my speed. I'm not sure if a timeout of 0 is ever desired, so maybe an error or reset to 15 secs would be nice. That's what I'm doing now on my object - if <=0 then 15. But don't take it as a complaint - WinSCP has been a lifesaver. Thanks.
Oh, also I missed that the logging in the assembly is set on the Session object. I kept looking at the SessionOptions object. Thinking I needed to do something with the AddRawSettings call. Oops. Once I turned on logging and did a quick compare, the issue was obvious.
Here is the log that shows a Timeout of 0 seconds:
. 2012-08-20 10:15:53.611 --------------------------------------------------------------------------
. 2012-08-20 10:15:53.611 WinSCP Version 5.0.8 (Build 2438) (OS 6.1.7601 Service Pack 1)
. 2012-08-20 10:15:53.611 Configuration: nul
. 2012-08-20 10:15:53.611 Local account: NMFF-NET\jsmyth
. 2012-08-20 10:15:53.611 Login time: Monday, August 20, 2012 10:15:53 AM
. 2012-08-20 10:15:53.611 --------------------------------------------------------------------------
. 2012-08-20 10:15:53.611 Session name: jsmyth@VX36138 (Ad-Hoc session)
. 2012-08-20 10:15:53.611 Host name: VX36138 (Port: 22)
. 2012-08-20 10:15:53.611 User name: jsmyth (Password: Yes, Key file: No)
. 2012-08-20 10:15:53.611 Tunnel: No
. 2012-08-20 10:15:53.611 Transfer Protocol: SFTP
. 2012-08-20 10:15:53.611 Ping type: -, Ping interval: 30 sec; Timeout: 0 sec
I was trying to be good, and I had wrapped the WinSCP objects with my own to limit 3rd party code touches. However, what I did not realize, was that my object's SessionOptions.Timeout defaulted to 0, and I cheerfully passed the value to WinSCP - overriding it's default of 15. So consequently, my sessions were dying constantly, and then I was being relogged in and the transfer would resume. Obviously all of those login/resume handshakes were crippling my speed. I'm not sure if a timeout of 0 is ever desired, so maybe an error or reset to 15 secs would be nice. That's what I'm doing now on my object - if <=0 then 15. But don't take it as a complaint - WinSCP has been a lifesaver. Thanks.
Oh, also I missed that the logging in the assembly is set on the Session object. I kept looking at the SessionOptions object. Thinking I needed to do something with the AddRawSettings call. Oops. Once I turned on logging and did a quick compare, the issue was obvious.
Here is the log that shows a Timeout of 0 seconds:
. 2012-08-20 10:15:53.611 --------------------------------------------------------------------------
. 2012-08-20 10:15:53.611 WinSCP Version 5.0.8 (Build 2438) (OS 6.1.7601 Service Pack 1)
. 2012-08-20 10:15:53.611 Configuration: nul
. 2012-08-20 10:15:53.611 Local account: NMFF-NET\jsmyth
. 2012-08-20 10:15:53.611 Login time: Monday, August 20, 2012 10:15:53 AM
. 2012-08-20 10:15:53.611 --------------------------------------------------------------------------
. 2012-08-20 10:15:53.611 Session name: jsmyth@VX36138 (Ad-Hoc session)
. 2012-08-20 10:15:53.611 Host name: VX36138 (Port: 22)
. 2012-08-20 10:15:53.611 User name: jsmyth (Password: Yes, Key file: No)
. 2012-08-20 10:15:53.611 Tunnel: No
. 2012-08-20 10:15:53.611 Transfer Protocol: SFTP
. 2012-08-20 10:15:53.611 Ping type: -, Ping interval: 30 sec; Timeout: 0 sec
