I am trying to use DSC to standardize deployment of our complex web application, replacing a Wix msi and many manuals steps and scripts.
A critical part of this operation is unzipping the application, which is a 360MB zip file. Using the native windows extraction, this operation takes 5 minutes on a local box. However, using DSC Archive operation (run natively on a VM, not push or pull while under development, this operation is taking north of 40 minutes.
This is my first DSC configuration, but it’s critical path and this performance is untenable. Is there something basic I’m not doing correctly? My script code is below and I’m running PS as administrator.
Configuration DirTest {
# param (
# [pscredential] $credential
# )
Node KerryTestIIS {
$archivePath = (Join-Path $node.DestinationRoot $node.InstallationFilePath)
$archiveFileName = "Elements." + $node.ElementsVersion + "_dbscript_" + $node.DBScriptVersion + ".zip"
$archiveFilePath = ($archivePath + "\" + $archiveFileName)
$elementsRoot = (Join-Path $node.DestinationRoot ("Elements " + ($node.ElementsVersion)))
File Payload {
Ensure = "Present"
Type = "Directory“ # Default is “File”
Force = $True
Recurse = $True
SourcePath = $node.SourcePath
DestinationPath = (Join-Path $node.DestinationRoot $node.InstallationFilePath)
}
Archive ElementsArchive{
Path = $archiveFilePath
Destination = $elementsRoot
Ensure = "Present"
Force = $true
DependsOn = "[File]Payload"
}
}
}
Kerry try xArchive and see if you get the same result. Also make sure any AV is disabled while testing.
Thanks, Zuldan. I did try xArchive with roughly the same results. There are a couple of 7zip options I’m going to give a shot at, though I don’t relish the thought of using 3rd party tools so soon in such a simple project.
No AV at all - this is a very basic VM. Just 2008R2 with WMF5 RTM (dual core processor, plenty of RAM) and a few utilities. 7-zip handled this file in less than a minute on this VM
There may be advantages to 7-zip down the road as well, but for now that would be YAGNI.
For that size of file i would not use the Archive\xArchive. Dont think the the current implementation of xArchive is meant to have good performance at such big file sizes yet.
I have not tried such a big file before although i have big sites im not packing them as zip files. I just have a different method of deploying .
Just remember all DSC resourced are based on a GET-TEST-SET methodoly. So every time you use a DSC resource to SET some state, a TEST will run first to see if the actuall state is already used. I can imagine whats happening in a big files is that the TEST itself is taking avery long time, while the deflating of the zip actually takes much faster and comparable to 'external" zip file managers.
Its not about using 3rd party tools. DSC has enough tools to help but you can also create your own resources. So say you create your own resource to handle big zip files to the speed you want, you can then publish it for others to use or add yours to the existing xArchive and by that make DSC better for all. to start with, i would open a case on UserVoice with the sample of your code and explainign the issue and let PS devs look at it and see if its really a bug in v5 (compared to v4 for example)
I would actualy go for the Package resource, create a nuget server and put all packages on it, including 7zip for example or ones you create yourself and then let DSC install. Thats part of a general bigger package management plan im pushing in my organization.
Other option would be to use a Script resource and then use your own code to extract the content of the zip using win32api or .NET classes .
When ever a resource isnt exactly giving you the expeted performance, theres plenty of info out there how to create your own implementation.
Thanks, Arie.
The option of rolling my own resource is definitely there, but at this stage of the game, I am somewhat in a “proof of concept” mode and trying to make this happen to demonstrate the viability of a new direction. Once past the initial hurdles of a basic deployment, we can look at improvements, and this is definitely one of them.
A package resource is not a bad suggestion either, nor is setting up a pull server. One question that I haven’t answered yet is how the actual model will work once we get onto a customer’s machine that is locked down behind a firewall. However, that is off-topic for this thread, so I will start another discussion on it.
You dont pick a 300MB zip file for proof of concept 
Create a new demo web site, connected to small DB if you want
zip that and demo it.
It willl have almost the same effect. Deal with issues of huge zp files and managine packages in parallell
Ultimately got this to work using a Script resource and calling Pscx\Expand-Archive. Learning how to use the configuration data inside the script was quite the bear (thanks to Brian Scholer and his excellent post Use Variables in a DSC Script Resource .
Extraction down to less than 4 minutes, and I didn’t have to install a third-party archive tool either.
Script ExtractPayload{
SetScript = {
$sourcePath = $Using:archiveFilePath
$outDirectory = $Using:elementsRoot
Write-Host "Creating $outDirectory"
New-Item $outDirectory -ItemType Directory
Write-Host "Expanding zip file at $sourcePath to $outDirectory"
Pscx\Expand-Archive -Force -Path $sourcePath -OutputPath $outDirectory
}
TestScript = {
$testPath = $Using:elementsRoot
(Test-Path -Path $testPath)
}
GetScript = {
#Do Nothing
}
DependsOn = "[File]Payload"
}