Howdy Boys & Girls!

Sometimes the public image of something is not a correct image, you might think that something/one is really quite sh*t at something when it really isn’t. I never really thought much of Miley Cyrus as a singer, but then I listened to her live session over at BBC1 while testing BranchCache and DeDuplication. Today I was blown away, by both Miley and BranchCache. Sometimes you are surprised of how wrong you are, so press play on this while reading the rest of this post and you might have a different view of Dolly Partons protégé as well as BranchCache:

Now what on earth does this have to do with BranchCache?

If our dear old friend Johan Arwidmark, who is deployment MVP, doesn’t know that BranchCache does De-Duplication then – “Seattle we have a problem!”

As someone in the comment field on the song above said; “The most talented douchebag since Kanye…” really tells you that sometimes the public appearance of both a singer and a technology can be deceiving. So lets dig deeper!

Now back on to the subject, as a part of our current project implementing BranchCache for a customer they wanted to know the efficiency of pushing media files, baked in zip files with small changes in them. How efficient would it be to figure out what has changed in them? Well, since we covered Johan’s 107GB images yesterday I thought I would throw together a few zip files and give it a go, taking a break from some very painful iPXE Anywhere development. (PXE can be a bitch if anyone missed that)

The Setup

We got 3 zip files that we are to transfer,, PXEDataReporting_2zip and As you can see 1 and 2 is fairly similiar in since and 3 being much larger.


File 1 – a zip file with a single .mp4 movie in it, shrinked down from about 183MB to 91MB


File 2 – a zip file with the same .mp4 as above and another 15KB .rtf file added to it, resulting in 4KB larger file than File1.


File 3 – a zip file with lots of copies of the same video, also another zip file inside the zip file with a copy of the same .mp4 file. Resulting in a 550MB file.


We host the files on an IIS server and will transfer them using BITS (BranchCache is in BITS on ALL Windows versions FFS!), and if you do this at home you have to remember that the BranchCache hash is generated at first download unless triggered in some other way.

The Test

First off I flushed the BranchCache Cache to make sure that I had no data that could be similar (not very likely) but I wanted to show the size of the BC Cache after all three files were transferred.

Then we kicked off the first bits job with bitsadmin.exe (I know I should have used PowerShell but I am an old school kind a guy and I know how many painstaking C++ lines of code that went into Bitsadmin.exe!)

So let’s kick of File 1 and put BranchCache to the test!
The transfers starts and takes a few minutes as I have my machine on a Bits policy.


As suspected the entire download was from the server and nothing came via the P2P Cache. Best way to check is to have a look at the BITS-Client event log and look at the reported figures in the Event 60’s, way simpler than looking at PerfStats.

Ok, let’s kick of File 2. It finished in a few seconds so I knew instantly that it worked very well you can see the download speed difference.


But let’s have a look at the data, ok so it did very well. More than 99% were taken from the Cache, kinda suspected.

On to test number 3. How will the big zip file work? Kicked it off and the speed varied greatly from about 100MB/s to about 200KB, so hard to tell.

The Result

What do you think happened? Have a look at the numbers down below:

File1 – Did zero bytes from the Cache, as suspected since it’s new.


File2 – Did 102KB from the server and the rest from the server, as stated above expected results.


File3 – Here we pulled down a small 4MB from the server, and the rest came from the Cache. The rusults can’t be shown in percentage as it’s just too confusing.


Ok, so we transferred more or less the entire file from Cache, not even a fragment of a full copy from the original movie went over the wire. Keep in mind, it was 550MB large. And in our Cache we only used up 93MB of disk space.


Awesome or what? – BranchCache and De-Dup FTW!