Long Run Time for Get-NetAppInfrastructureVolume

[cczinski]

So, before I give up on this command and just use the NetApp Api, is it normal for Get-NetAppInfrastructureVolume to take 10 minutes to bring back about 3000 volumes? Even for 200 volumes it takes a little over a minute to come back.

If this command is expected to take that long, then I can just use the NetApp API for an almost instant return of 3000 volumes and the information I need to call Set-NetAppHost.

If the command is not expected to take that long, what would be causing it to be that slow?

[soncscy]

Just my $.02 before the (light) green posters appear, I kind of expect Powershell [anything] to be slower.

Powershell has to serialize all the data returned to present it in the shell -- at it's core, the cmdlet here is probably doing the same thing as the native API call from the Veeam server, but that data needs to be serialized for powershell and ultimately that adds excess overhead. I don't think there's a way to avoid this with Powershell except to do native REST calls within Powershell, and even then I'd still expect Powershell to be slower

Powershell's ubiquity is both a boon and a curse -- it's very nice and easy to learn, but serializing the data comes at the cost of cycles.

[oleg.feoktistov]

Hi guys,

Most likely, Harvey is right. Could reproduce the same behaviour in our lab. However, it is worth checking what is causing such performance anyway, just to be sure. Asked QA to take a look the next week. Will keep you posted.

Thanks,
Oleg

[cczinski]

Thanks for asking QA to look into that. Yeah expect PowerShell to be slower as well, but not that much slower.

Not quite sure what is happening behind the scenes in the Veeam PowerShell module, but to do a listing of 400 volumes using PowerShell to hit the NetApp api takes 7 seconds and then another 46 miliseconds to turn all that into a list of CSanInfrastructureVolume objects.
While using the Veeam PowerShell command for the same NetApp host takes about 10mins.

Also, have an odd and scary problem I'm going to make another post about.

[oleg.feoktistov]

Apologies, QA have been quite busy this week, so we couldn't duly discuss it. We have a suspicion that enumeration calls made with this cmdlet follow an unoptimized algorithm, but I can't say for sure because last week I had around 150 volumes returned in a minute and now it takes 17 seconds. So, we need to wait for a test from QA to see the precise cause. I will keep you posted as soon as I have answers. Thanks!

[oleg.feoktistov]

Hi Carl,

We confirmed our suspicion and submitted a bug for vNext to optimize cmdlet's performance.

Thanks,
Oleg

[cczinski]

That's great, thank you!