Impact of Multiple Layers Attached at Logon
Now these timings all show individual layers and how they individually affect login times. If you have multiple layers, it is not additive. For example, if you have two apps that individually take 4 seconds to mount, it does not take 8 seconds to mount both layers.
The reason for this is that there are several tasks of the logon which are done simultaneously. For example, layers are mounted simultaneously, the JSON files are read once at user logon, services are started simultaneously, and so on.
Disk IO and Network Impact
The next set of data to review was taken from the server hosting the Elastic Layer share. Windows perfmon was used to show both the disk IO and Bytes sent over the network
Per the ulayersvc log , the attach and composition process takes a total of 4 seconds. The layer is read from for an extra 12 seconds beyond that. The extra time can be seen in the perfmon graphs (Figures 1 – 3) below. The interesting point to note is that the extra time taken does not affect login times. For example, a user login does not take an extra 12 seconds due to the data being read in from the layer. Once the layer is attached, the rest is done in parallel with the login process.
The initial spike in the graphs corresponds to the layering service on the host mounting the disk and compositing the file system and registry (4 seconds). The disk IO and information sent over the network is extremely low and has a minimal impact on the disk and network itself.
Tests were also done to see the impact during usage (Figure 4). Specifically, Word was used to measure the impact on IO. The test was a simple typing test but it is interesting to note that there is constant, if minimal, activity during this time. This is due to the spell check, grammar check, etc that is all happening in the background during typing. As an interesting counterpoint, PowerPoint was run (not shown) while displaying a presentation and it generated almost no activity at all. It had an initial spike to read the required files into memory and then didn’t touch the disk afterwards.
Firefox & Chrome
Looking at Firefox, the figures below (Figures 5 – 7) show the same spike in the mount process and data read in after. It is all minimal activity during this time though.
In fact, usage tests were done with Firefox (not shown) as well. A small spike as the Elastic Layer was read for required files and then nothing after that during usage. Once the executable and required files were in memory, there was no need to go back to the disk.
Looking at WinRAR, the figures below (Figures 8 – 10) show the same spike in the mount process and data read in after. It is all minimal activity during this time though.
In fact, usage tests were done with WinRAR (not shown) as well. A small spike as the Elastic Layer was read for required files and then nothing after that during usage. Once the executable and required files were in memory, there was no need to go back to the disk.
In conclusion, Elastic Layering does not change the IO pattern of applications. It simply shifts the read IO from the VM to the file share. As your environment is configured, you will want to take that into effect when deciding what share or shares to use for elastic layering.
IO & Timings
The following charts help to define the load on storage and network for several elastic applications. Note the black line in each chart shows the defined metric.