1

I'm very frustrated by the slowness of the OpsHub migration utility. I've even moved our TFS infrastructure to Azure just so that I could pump things through faster, but the gains are minor.

One of the things I noticed was that the TFS_Temp folder (C:\Program Files\OpsHub Visual Studio Online Migration Utility\TFS_Temp) is being hit with a bit of random IO.

So, my question is how can I tell OpsHub to use a different drive location (where Random IO is better processed) for the TFS_Temp folder?

Jaans
  • 4,598
  • 4
  • 39
  • 49

2 Answers2

1

OK I'm using a workaround using Symbolic Links.

First I move the actual TFS_Temp folder, and then symlink that new location back to the original path:

mklink /J "C:\Program Files\OpsHub Visual Studio Online Migration Utility\TFS_Temp" D:\TFS_Temp

Jaans
  • 4,598
  • 4
  • 39
  • 49
1

The TFS_Temp is the folder which the utility maps to an additional drive for the system (usually O:\ by default, and additional ones if the path is too long for some files). This is where the utility creates a workspace of your VSO.

And the migration utility utilizes this space for data processing of each changeset. Hence a lot of IO processing. However, this location is hard coded and non-modifiable directly through any configuration.

But glad to know you got is working through symbolic links. Has it improved your performance?

OpsHub Inc.
  • 1,095
  • 1
  • 6
  • 13
  • Thanks for the feedback. Because this is running in an Azure VM, and the OS drive is backed by Azure Storage, the Disk IOPS is quite poor (300 IOPS or 500 IOPS depending on on configuration). By using temporary local storage or SSD storage as the target for the Symbolic Link, the IOPS limitation is greatly reduced. I did find that it made a visibly noticeable improvement. Nothing spectacular, but an improvement nonetheless. Related question, is it better to run multiple smaller migrations concurrently, or rather a larger migration sequentially? – Jaans Mar 16 '15 at 12:15
  • Hi Jaans, are the migrations atomic? Like no across project merge-branch / move etc? In that case smaller migrations are best if run concurrently. But if the answer to the previous question is yes, then I am afraid to maintain the same history in VSO, it has to migrate sequentially and hence a single migration where all projects are selected should be executed. – OpsHub Inc. Mar 16 '15 at 14:19
  • Thanks. Our projects are all independent of each other, so in theory we should be able to run them in parallel. Does this (one big migration vs. multiple smaller migrations) affect the Work Item #, as per this question https://stackoverflow.com/questions/29079899/opshub-tfs-to-vsonline-migration-utility-will-workitem-not-stay-the-same ? – Jaans Mar 16 '15 at 14:59