A few problems with FTP plugin

[AxemanMK]

I am using the FTP plugin v1.0.1.0, with SF7 v7.0.6.1.

Firstly, I have noticed that file transfers are exceptionally slow in comparison with the DOS FTP client via a command prompt.

Secondly, I have found that the "FTP.SetTransferType" command appears to be completely ignored.

I have tried....

FTP.SetTransferType(FTP.BINARY);

....and....

FTP.SetTransferType(1);

Neither option appear to set Binary mode, so I am forced to use.....

-- Set Binary mode
FTP.Command("TYPE I");
-- Get the last responce
strLastResponse = FTP.GetLastResponse();
-- Check for 200 in the response (FTP server code for OK)
nLastResponce = String.Find(strLastResponse, "200", 1, false);

Although I can achieve the desired result, I have to go "around the houses" to get there.

Has anyone else had any problems with setting Binary mode with the "FTP.SetTransferType" command ??

Cheers......... Andy

[AxemanMK]

Ok, Ive done some speed tests and read some more posts on the forum, and it appears others have found a similar issue with both the FTP plugin and with the HTTP.Download command.

Its seems that when you specify a callback function, performance drops to "virtually unusable". Do NOT use a callback function, and performance is quite reasonable.

My test environment is a P4 3Ghz Win2000 PC, connecting to an IBM Risc 6000 Server across a standard 100 Mbit switched LAN.

Using a callback function, uploading a 36meg file to the FTP server takes 18 minutes, 37 seconds (virtually unusable). The very same file takes only 1 minute 20 seconds when no callback is used (usable).

My callback function is as follows......

--------------------------------------------------------------------------
function fcnFtpUploadCallback(Bytes,TotalBytes)

DlgProgressBar.SetPos(CTRL_PROGRESS_BAR_01, (Bytes / TotalBytes) * 100);

return true;

end
--------------------------------------------------------------------------

I realise that there is a small calculation going on within my callback function, but hardly enough to overload a 3Ghz PC.

Surely there has to be a way to display the progress, without hindering the performance ??

At this point, I probably have no option but to output a batch file, and execute it. Obviously this completely defeats the object of using Setup software, and is not going to do much for my reputation around the company.

I am hoping someone out there might have an answer, or possibly IR has found this issue and is addressing it.

Cheers.......... Andy

[Adam]

Axeman,

It could be that there are so many callback calls and you are setting progress on every one. Try this code to see how many times the function is called:



count = 0;

function fcnFtpUploadCallback(Bytes,TotalBytes)
count = count + 1;
DlgProgressBar.SetPos(CTRL_PROGRESS_BAR_01, (Bytes / TotalBytes) * 100);
return true;
end


Then display count after the upload. If the number is very high then it may be better to only update the progress every 10 or 50 count cycles.

Updating progress is slow, doing binary counting and small if statements should be quick.

Post your count results

Adam.

[AxemanMK]

Hi Adam.

Thanks for the reply.
Ok, I have added a counter to the callback as follows....



--------------------------------------------------------------------------
function fcnFtpUploadCallback(Bytes,TotalBytes)

nCycleCount = nCycleCount + 1;

if nCycleCount > 256 then

-- Update top progress bar
DlgProgressBar.SetPos(CTRL_PROGRESS_BAR_01, (Bytes / TotalBytes) * 100);

-- Reset nCycleCount to 0.
nCycleCount = 0;

end -- of if nCycleCount == 256

return true;

end
--------------------------------------------------------------------------


For a file of 2382793 bytes, the cycle count was 9345.
For a file of 597333 bytes, the cycle count was 2343.

This averages out a approx 256 bytes per cycle.

So I decided to only update the progress bar when the counter is greater than 256, and indeed transfer is still slow.

Transfer of a 2382793 byte (2.27 mb) file took 1 min 38 secs.

I then decided to rem out the DlgProgressBar.SetPos command, essentially leaving the callback with nothing more than the calculations.......



--------------------------------------------------------------------------
function fcnFtpUploadCallback(Bytes,TotalBytes)

nCycleCount = nCycleCount + 1;

if nCycleCount > 256 then

-- Update top progress bar
--DlgProgressBar.SetPos(CTRL_PROGRESS_BAR_01, (Bytes / TotalBytes) * 100);

-- Reset nCycleCount to 0.
nCycleCount = 0;

end -- of if nCycleCount == 256

return true;

end
--------------------------------------------------------------------------


and indeed, no improvement on transfer.

It would appear that it is NOT the screen updates that are slowing things down, but simply the sheer amount of times the command calls the callback.

Regards.......... Andy

[AxemanMK]

OMG !! Problem solved, but I wouldnt mind knowing why this is happening.

I read through more posts on the forum, and found a posting by tigran..

http://www.indigorose.com/forums/showthread.php?t=20795

He had switched the error logging from "Extended Errors" to just "Errors", and found a drastic improvement in the way his apps performed.

I tried this, and BINGO !!! FTP'ing a 36meg file now only takes around 1 min 30 secs.

Consequently, I have now made this change across every project, and indeed have found an improvement in performance across every one.

I would like to suggest that a warning note be placed into the helper, to warn developers that using "Extended Error" trapping may hinder the performance of the application.

Cheers........... Andy

[ryanc]

Howdy apologies for the Necro post, but this describes my proplem exactly using the FTP plugin.

Downloading from a Pure-FTPd FTP server and the plugin seems to ignore requests to download in binary mode. Even using the TYPE I trick from above.

Help?