Benchmarking Peer Cache vs. BranchCache – Bare-metal OS Deployment

With Windows 7 out of support, protecting your WAN links, and reducing the network impact Windows 10 will have on your environment has never been more important. In this post I wanted to compare Peer Cache and BranchCache in ConfigMgr for a specific scenario to see how they compared to each other. The scenario: I wanted to deploy (bare-metal) a Windows 10 image to a bunch of machines (well 25 of them) in a remote office, with no local DP and find out which solution that was the best.

TL;DR

For this particular scenario BranchCache did the better job. From a core deployment speed, the two platforms where quite similar for most tests, but BranchCache used less WAN traffic, and the users working on the machines peering content were not interrupted.

But please continue to read all the details about the tests. Chances are you learn a bit about Peer Cache and BranchCache in the process 🙂

25 Deployments – Scenario Details

As you learned in the introduction, the scenario I wanted to compare the two P2P technologies for is quite simple: Deploying a Windows 10 image to 25 machines in the remote Chicago office.

The Chicago office does not have a local DP (purposely), and is connected via a 155 mbit link to New York where the remote DP is. The DP in New York also had PXE enabled. My network looks like this:

Windows 10 and more than 20 Connections

An interesting thing about various Windows 10 peer-to-peer platforms – Peer Cache, BranchCache, and Delivery Optimization – is that they are actually not limited to 20 simultaneous connections like for example file and print sharing have. At least not from a licensing point of view. From the section 2.3.d in the Windows 10 license terms: "You may allow any number of devices to access the software on the licensed device to synchronize data between devices."

Below is a link to the terms:
https://www.microsoft.com/en-us/Useterms/OEM/Windows/10/UseTerms_OEM_Windows_10_English.htm

Note: Just to prove a point I tested to deploy the 25 machines with a single peer cache source in the boundary group, and most of the clients (24 out of 25) connected at the same time to the peer cache source (which was quite busy servicing those clients).

Benchmark Lab setup

For this Benchmark Lab I'm using a pretty Powerful Hyper-V host for most of the testing, using multiple networks separated with a virtual pfSense router. But I also added a bunch of regular Dell desktops to provide real-world peering data.

Hyper-V Host and Desktops

The Hyper-V host is a HP Z840 Workstation, 2 Sockets and 24 cores, 256 GB RAM, and 2 NVMe SSD's for the VMs. The Dell Desktops are Optiplex 7040 micro towers, i7, 32 GB RAM, and with NVMe SSD.

Networking

The Chicago network is throttled to 155 mbit, and all machines in Chicago, including the VMs, where limited to 1 gigabit traffic. The reason for the latter is that I didn't wanted a peer being able to deliver more than 1 gigabit total to any other machines. I mean there are VERY few organizations having 10 GB network adapters in their client computers 🙂

Virtual Machines

All Windows 10 VMs were given two virtual CPU's and 4 GB RAM. The VMs outbound traffic were throttled using native Hyper-V bandwidth management, and I used native Hyper-V Metering to measure the WAN traffic out from the DP in New York.

Peer Cache and BranchCache for OSD

Peer Cache supports OS Deployment by default, but to have BranchCache supporting OS Deployment, you need to add BranchCache to WinPE using the free OSD Toolkit from 2Pint Software. This kit also includes an Alternate Content Provider (ACP) for BITS, that works very well with BranchCache.

PXE Server

The PXE Server I used for the DP in New York was the iPXE Anyhwere solution from 2Pint Software. This solution can download boot images via HTTP/HTTPS, and also get the boot image from nearby BranchCache clients that happen to have the boot image in their cache. iPXE is quite much faster than any of the two native PXE providers that comes with ConfigMgr, and certainly more suitable to use over a WAN link. To learn more about iPXE Anywhere, check this link: https://2pintsoftware.com/products/ipxeanywhere/

Windows 10 v1903 Task Sequence

The Task Sequence I used was based on a native ConfigMgr task sequence template, and I deployed a Windows 10 v1903 image with a driver package for the Dell machines.

The driver package was downloaded and staged also when deploying the virtual machines to add extra data. The driver package was zipped prior to deployment to optimize it for Peer Cache and BranchCache. To learn more about how to speed up driver package downloads in ConfigMgr, read this post: Speed Up Driver Package Downloads for ConfigMgr OSD.

I added a few applications that was installed by the task sequence, like Office 365, Edge, and Adobe Reader. I also enabled software updates in the task sequence. All in all the total package size for the task sequence is about 7.5 GB plus whatever size the monthly cumulative update is (0.3 GB for this deployment).

Note: For best peer to peer efficiency I recommend archiving any really large applications, or any applications with lots and lots of small files, into either a ZIP file, or a WIM file, or whatever you prefer. WIM files has the benefits that they simply can be mounted by a script wrapper, and you don't need to extract content first.

The 8 Magical Benchmark Tests

Below follow a list of the 8 benchmarks I did in Chicago, and how they affected the WAN link as well as deployment time. Again, for each of the 8 tests, I deployed the Windows 10 image and a driver package to 25 new machines in the remote Chicago office. For each test round, the 25 machines were started up with about 10 seconds in between. Basically to simulate somewhat quick technician with a pair of brand new runner shoes 🙂

Test #1: No Peer Cache or BranchCache enabled

Obviously not recommended, at all, but I wanted to see how long time it took to deploy the 25 machines over the WAN link with no Peer Cache or BranchCache enabled. The result:

Total Deployment time: 3 hours and 48 minutes
Total traffic over the WAN: 203.76 GB

Included in the WAN traffic was 0.08 GB from Active Directory (domain join, GPO), and 0.58 GB from the ConfigMgr MP (ConfigMgr policies, client registration).

Test #2: Peer Cache with one Peer Cache Source

Peer Cache enabled, and one extra machine in Chicago already having the Windows 10 task sequence packages in its ConfigMgr cache. The result:

Total Deployment time: 1 hour and 21 minutes
Total traffic over the WAN: 19.12 GB

Included in the WAN traffic was 0.07 GB from Active Directory (domain join, GPO), and 0.56 GB from the ConfigMgr MP (ConfigMgr policies, client registration).

Note #1: A Peer Cache Source only starts to reject content requests when CPU hits 80 percent, and the disk queue length hits 10. Not to mentioning fully saturating its network card (1 Gbit/s). At this point the peer cache source computer is pretty much useless for anyone trying to use it. It took 10 seconds to just launch notepad.

Note #2: Since Peer Cache requires the entire content to be in its cache before starting to share, you are more or less forced to pre-cache the content to at the very least one device in each boundary group. See the following post for pre-caching content for Peer Cache: https://deploymentresearch.com/speed-up-driver-package-downloads-for-configmgr-osd/

Test #3: Peer Cache with two Peer Cache Sources

Peer Cache enabled, and two extra machines in Chicago already having the Windows 10 task sequence packages in their cache .

Total Deployment time: 1 hour and 24 minutes
Total traffic over the WAN: 19.5 GB

Included in the WAN traffic was 0.07 GB from Active Directory (domain join, GPO), and 0.56 GB from the ConfigMgr MP (ConfigMgr policies, client registration).

Note: In my lab, all peers still reached out to just one Peer Cache Source, even though two peer cache sources was available with the content in the boundary group. This is not supposed to happen, and the ConfigMgr team is investigating why it does not randomize in between the two sources.

Test #4: Peer Cache with three Peer Cache Sources

Peer Cache enabled, and three extra machines in Chicago already having the Windows 10 task sequence packages in their cache. Like when having two peer cache sources, all peers still reached out to just one Peer Cache Source, even though three was available with the content.

Total Deployment time: 1 hour and 22 minutes
Total traffic over the WAN: 19.72 GB

Included in the WAN traffic was 0.06 GB from Active Directory (domain join, GPO), and 0.56 GB from the ConfigMgr MP (ConfigMgr policies, client registration).

Tip: ConfigMgr only returns peer cache sources in the same boundary group as your client (unless the limit per subnet option is selected, then its per subnet). And, starting with ConfigMgr 1806, it only returns peer cache sources that have their fast-channel status set to online. Here is a quick SQL query you can run to find what content that are available, on which online peer cache sources, and on which subnet or boundary group:

SELECT S.Name0, BGBNI.IPAddress, BGBNI.IPSubnet, ContentID, SPCM.SiteNumber, SPCM.Version, SPCM.Flag, BG.GroupID as BoundaryGroupID, BG.Name as BoundaryGroupName FROM SuperPeerContentMap as SPCM
INNER JOIN v_R_System as S ON S.ResourceID = SPCM.ResourceID
INNER JOIN BGB_ResStatus as BGBRS ON BGBRS.ResourceID = SPCM.ResourceID
INNER JOIN BGB_LiveData_Boundary as BGBLB ON BGBLB.ResourceID = SPCM.ResourceID
INNER JOIN BoundaryGroup as BG ON BGBLB.BoundaryGroupID = BG.GroupID
INNER JOIN BGB_NetworkInfo as BGBNI ON BGBNI.ResourceID = SPCM.ResourceID
WHERE BGBRS.OnlineStatus = '1' AND BGBNI.IPAddress NOT LIKE '%:%'
ORDER BY SPCM.ContentID

Test #5: Branch Cache Enabled, no Pre-caching

Since BranchCache is the only P2P technology I know of that can share content to other peers while in WinPE, I thought it was relevant to included a test with just BranchCache enabled, but no pre-caching done to any other clients in the Chicago office. The result:

Total Deployment time: 1 hour and 37 minutes
Total traffic over the WAN: 20.86 GB

Included in the WAN traffic was 0.07 GB from Active Directory (domain join, GPO), and 0.54 GB from the ConfigMgr MP (ConfigMgr policies, client registration).

Test #6: BranchCache with one Peer

BranchCache enabled, and one extra machine in Chicago already having the Windows 10 task sequence packages in its BranchCache cache.

Total Deployment time: 1 hour and 27 minutes
Total traffic over the WAN: 7.74 GB

Included in the WAN traffic was 0.08 GB from Active Directory (domain join, GPO), and 0.57 GB from the ConfigMgr MP (ConfigMgr policies, client registration).

Note: An interesting observation was that the extra machine in Chicago peered about 140 GB of the content. The remaining 60 GB GB was peered in between the machines while being deployed.

Test #7: BranchCache with two Peers

BranchCache enabled, and two extra machines in Chicago already having the Windows 10 task sequence packages in their BranchCache cache.

Total Deployment time: 1 hour and 25 minutes
Total traffic over the WAN: 6.52 GB

Included in the WAN traffic was 0.07 GB from Active Directory (domain join, GPO), and 0.58 GB from the ConfigMgr MP (ConfigMgr policies, client registration).

Test #8: BranchCache with three Peers

BranchCache enabled, and three extra machines in Chicago already having the Windows 10 task sequence packages in their BranchCache cache.

Total Deployment time: 1 hour and 23 minutes
Total traffic over the WAN: 6.5 GB

Included in the WAN traffic was 0.07 GB from Active Directory (domain join, GPO), and 0.53 GB from the ConfigMgr MP (ConfigMgr policies, client registration).