File copy too slow on tentacle

Hi,

I am experiencing extremely slow file/ package copy from Tentacle server to deployment folder (which is on network share). The package gets copied from Octopus server to tentacle in reasonable amount of time. However when it is transferred to network share it is unbearably slow.

I have checked the network share and the tentacle server, there is no latency on both of them.

Is there anyway I can speed up this process?

Thanks,
Rafid

Hi Rafid,

Thanks for getting in touch! Could you tell us a bit more about how are you copying the file from the Tentacle to the fileshare? If you could send us a deployent log, that would help us understanding your process bit more

http://docs.octopusdeploy.com/display/OD/Get+the+raw+output+from+a+task

If possible, send us the log of a deployment where you only ran the step where you are experiencing the slowness to avoid unnecesary logging noise . This would also help us big time :slight_smile:

Thanks

Dalmiro

Hi Dalmiro,

Thanks for getting back to me so quickly. I have attached the log you requested.

With regards to your question on how I am copying files , I am actually using ‘Deploy a Nuget package’ and ‘custom installation directory’ (our deployment location is a network share) feature in octopus.

The said package contains around 30k files but most of them are script and MVC view files not more than few KBs in size.

Kind regards,

Rafid Haroon
Online Systems Support Team Leader, Group IT

T: +44 20 8996 7867 | M: +44 7901 108907

ServerTasks-8447.log.txt (54 KB)

Hi Rafid,

Big thanks for sending a log with only that step. I cant seem to see a reason why the file transfer would take so long. Few more basic troubleshoot questions

  • Can you confirm that data is being transferred from the tentacle to the fileshare the entire time (seem to be around 1h) when the following line shows up on the log

Copying package contents to '\\public.bsi.cloud\cloud\IIS\IIS-Files\Cloud\PPD\eurocodes\3.2.3.0'

  • Can you confirm that the same doesn’t happen if you deploy to a local folder on the tentacle server using the Custom Dir feature?

  • Could you try remoting into that VM and use Powershell’s copy-item to transfer that folder manually and see if it takes the same amount of time?

Thanks,

Dalmiro

We too have this problem we certain large deployments, where the deployment is much slower than a regular copy. I gather Octopusdeploy uses copy-item could the problem come from something like this ? http://stackoverflow.com/questions/4676977/powershell-performance-issue

Hi,

Octopus doesn’t use copy-item for this task. Could you tell us which version of Octopus are you using? We made a significant improvement to the file copy on 2.6.

If possible send us a raw log so we see the timing ourselves

http://docs.octopusdeploy.com/display/OD/Get+the+raw+output+from+a+task

Thanks

Dalmiro

Hi,

OK. the developer who made this deploy sent me the rawlog. He says the deployment is 39 minutes.

Could I sent it to you by email or something. It seems to contain semi-sensitive information about our environment.

Hi Jesper,

Please send it to support@OctopusDeploy.com

Dalmiro

Hi Dalmiro,

Sorry for late reply, I was away for a while. I have answered your questions below

  1. Yes the data keeps transferring the entire time. We have one scripts folder which has got more than 29k files (most of the files are tiny). This folder takes longest time to copy.

  2. The file copy is faster if I give local path e.g. D:\SomeFolder.
    However if I convert the folder D:\SomeFolder to a network share \\SomeNetworkShare and copy the files to it, it is considerably slow even though the files I am trying to copy and the share are on the same machine.

  3. Copy-Item command for share is as slow as it is point 2

Thanks,

Rafid

Hi Rafid,

No worries for the delay. The problem seems to be when the network transfer comes into play. At this point i’m not sure there’s something we can do from the Octopus side unfortunately, as the same behavior is seen when you copy files using plain powershell.

Sorry its not better news

Dalmiro