As the Citrix Architect of Application Streaming AND Architect of Citrix Profile Manager, you might infer that I’m interested in leveraging one technology to help the other.
Background on roaming profiles and Citrix Profile Manager
First, background on Windows “roaming profiles” and similar. Consider that when a user logs onto a machine, the logon activity must “roam” or “copy” the network stored version of the user’s profile onto the execution machine. In the general sense, everything on disk beneath %USERPROFILE% or C:\Users\usename, will be copied onto the execution machine at logon and then copied back to central store at logoff.
During logon, this is a “large” consumer of logon time where it consumes perhaps the largest portion of the overall logon clock. With roaming profiles, this full copy happens every time, but with efficient systems such as Citrix Profile Manager, the “copy” is actually a “sync”, so the copy happens really fast and the copy back is limited to only the files that changed. While this also speeds logoff time, let’s stick with the value of logon time because … nobody cares how long it takes to logoff.
Where all of this stuff gets more interesting is when you consider a user logging on to XenApp hosted session or logging onto a hosted XenDesktop session where a common disk image is used for the base operating system. Notice that in each of these hosted cases, the user’s profile on the execution machine is initially “empty” and it will be initially “empty” on every logon. This means that the glorious logon sync that the Citrix Profile Manager does at logon will actually be a “full copy” and here, it starts to behave with the same inefficiency as the base operating system profile solution because it will be a full copy at EVERY logon. We like to do better than this.
For a more detailed introduction to Citrix Profile Manager, consult this Sepago white paper. Recall that Citrix Profile Manager is based upon the Sepago Profile technology that Citrix acquired some time back.
Use “streaming” to solve profile population
Logical move: Instead of copying stuff onto the machine at logon, use isolation technology to LIE to the system to tell it everything is copied local when it is really still on the central store. Eventually, when the system or an application references stuff in the user profile, go fetch it and make it present. This is “just in time” population and it has the promise to greatly improve logon time in a hosted environment.
For JUST IN TIME population, the bet goes, some large portion of the user profile will never be referenced, so you save big on the logon speed and you save big on the runtime because much of what exists in the user profile will NEVER be copied to/from the central store. This means that using a just in time profile solution will save LOTS of time for logon, and this is a great benefit!
Great – How much quicker?
The answer: LOTS QUICKER!
Yes, but do you have a number?
I’d like quote: Just in time Profile Manager speeds XenApp logon by 100%
My gut says that the number is closer to 40% – 50%, but I don’t have any hard evidence and thus the premise of this blog post…
Getting a “number” is harder because the answer is that “it depends”. Marketing people and customers prefer hard integers. The integer number is hard to dream up because the answer depends on the size of the user’s profile and the efficiency of network activity to/from the central profile store to the execution physical machine or virtual machine. The BIGGER the profile, the more efficient. If the profile is zero size, then JIT doesn’t do anything and if the profile size if infinite the the JIT logon benefit is also without limit.
So, the answer for the logon value of just in time is is somewhere between a 100% benefit and 0%. This doesn’t help.
Let’s go with an example: The profile on my primary computer is 11GB, yes Gigabytes. I could be a rare case. This is pretty close to “infinite” so I will save plenty in an average logon.
It turns out that 10 GB of my 11 GB profile is a TrueCrypt encrypted hard disk container. I’m sure glad I’m not copying that down from a central store on each logon! In a hosted VDI, I would be. Technically, I’d store stuff differently, but in concept I’d be copying this down. In a hosted XenApp execution with just in time, I would never copy down this file so Joe’s benefit of just in time will be either 0% or 100% and nothing in the middle. This still isn’t helping me come up with a number.
For my normal machine, I am not connected to profile manager or roaming solution or even to a domain so my system may not be the perfect example. As XenDesktop becomes more and more prevelant though, the strange things that users do to populate their user profile will make examples of users doing stupid things like placing 10GB files into the user profile more and more common.
If you are using the same profile for the primary hosted desktop as well as numerous XenApp server based app executions, you experience the victory! Only ONE of them will be accessing that really big file.
In my case, the primary machine will access the really big file, but all the “vacation request” and similar applications that I run will run on another computer, where the really big file will never be referenced. Using just in time population of the user profile, the majority of my logons and I’ll say that ALL of my quick in/out sessions will have a HUGE benefit to not copying down that 10GB file! This will make my logon time benefit near 100% on these other sesions and near 0% on the machine where I do access that single file that is 90% of my user profile!
It is much better to quote percentages on something like this, so the time saved will be some percentage of the overall logon time and the LARGER the user profile, the HIGHER the savings! Okay, we’re getting closer.
Right – what’s the number to quote?
Let’s start with a formula:
- TimeSaved = TotalTimeWithouJIT – TotalTimeWithJIT;
- PercentFaster = (TimeSaved / TotalTimeWithoutJIT) * 100%;
How to calculate “TotalTime”? This number will be the sum of the entire logon, nobody cares how much more efficient the roaming profile copy is, they want to know how many SECONDS this will save on logon time and how much of a percentage faster the logon time is.
This requires breaking down the logon time of a “NORMAL” logon. What is a “normal” logon?
Need to have: Computers that are representative of a “normal IT shop”. Need networks that are also representative of “normal world” and network servers and end user machiens that are “normal”. Must simulate some kind of load on these machines or just take it as a given that the load during the test will be similar to all the other stuff going on with the test network at the time of the measurement.
The key ingredients are:
- Size of the user profile.
- Speed of the network.
- Overall logon time
- Logon time used to copy the full user profile
Given the above, we tigger the measurement to figure out how much time is profile population and poof! Take the total logon time, subtract out the portion spent copying the user profile without JIT and … We have a number!
What’s that number again?
What is the SIZE of an “average” user profile? What is the average file size? How many files are “normal”.
Do normal users have giant files inside their user profile? Yes, they do! If you have have you ever copied a .MPG file or .MP3 onto your desktop, then you’re as guilty as I am. The PROFILE WILL GROW and will be large.
We need to exclude some files. What about the files that will NEVER copy onto the execution machine even ignoring just in time. Some stuff like “My Documents” will not be roamed, but will instead be accessed straight off the network via folder redirection. This is “standard procedure” for setting up profile environments and here, “just in time” doesn’t have any effect.
Let’s get to statistcs.
Start with the initial 11GB and take out that 10GB file that is an anomaly and I’m left with 390MB. The missing 610 MB is round off error.
Administrators usually redirect “My Documents”. Take out Joe’s “My Documents” = 208,055,865 bytes and I’m left with 182,450,081 bytes.
Okay, I wonder what I have inside my USERPROFILE that could possibly constitute 182MB? Dig deeper. I have 24 MB of pictures! While I am sure that they are lovely – I am also sure that I haven’t looked at them in months. If I were “server side” my admin would probably redirect “My Pictures” too. Now I’m down to 158MB.
Keep looking…. BING BING BING BING BING!! We have a winner. I have 149MB of “Downloads”.
First – before anyone starts, “Downloads” have ZERO relation to the 24 MB of pictures!
Something is wrong here because after you subtract all this out and I’m down to 9MB of stuff that wouldn’t normally be “redirected” and I KNOW that NTUSER.DAT on my machine is 8.9 MB. This leaves me with 100KB of stuff that is candidate for JIT value. There’s a number breakdown here someplace, but let’s keep it going.
Pretty soon it’s obvious that I don’t have ANYTHING in the user profile that matters. I store it all in that huge the container file and in “other places” on the hard disk. In a hosted case, these “others places” would find their way into the user profile, so all my utilities would be a plus for the profile. Go looking…
What are “other places”.
Utilities. I have lots of them and store them off the root. In a hosted desktop model, they will be in the user profile. Add in 137 MB. I have 77 MB of sound .wav files left over from my days of writing audio device drivers. These would almost never be accessed, but they would live in my user profile. Batch files. They are kept separate from executable utilities, so add in another 9 MB and utilities and 33 MB of Windows SYMBOL files for debugging stuff. 137 + 9 + 77 + 33 = 256 MB of additional stuff for the user profile.
I love it when numbers come out to a power of 2!
One number: “Average” user profile size is 256MB!
Yes, I left the 10GB file out of this mix. That quantity of storage just has to kind of go away from the calculation. I hear numbers of 20-30 seconds of XenApp logon time being required for copying down user profile content? If we can make this number be “zero”, then there can be real value in just in time profile solutions.
Add in some stuff that would be moved from my container file onto the user profile and I propose that the real size could easily double.
Joe’s proposal: The Average size of user profile is 512MB!
If any of this math makes sense, then I have an example number set that can be used to construct a measurement. Is 256MB the right number? Is 512MB the right number? How about 1GB?
Real world statistics are the elusive number. If you happen to have a couple hundred profiles representing a years worth of regular hosted desktop usage and wouldn’t mind sharing, please send me an email or comment below.
Product Architect of Application Streaming, Profile Manager and a few side projects
Citrix Systems – Fort Lauderdale, FL