Post to Twitter |
Comments (11) |
Views (1279) |
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.
How 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.
THANKS.
Joe Nord
Product Architect of Application Streaming, Profile Manager and a few side projects
Citrix Systems - Fort Lauderdale, FL
Comments (11)
Nov 13
Jim Moyle says:
Joe, First off my local profile is 7.5GB, so you might be a bit low with 512 MB...Joe,
First off my local profile is 7.5GB, so you might be a bit low with 512 MB
.
Secondly, your assertion that no-one cares about log off time is incorrect. For instance we have a large financial customer who employs hotdesking, and the combination of logoff and logon times is a key issue for them as the user can't work at that time. As members of staff are public facing they cannot be seen to be sitting there 'doing nothing'. So although logoff time is a much smaller issue in general than logon time, you can't ignore it.
Nov 13
Joseph Nord says:
Good point on people do care about logoff time. I should instead say...Good point on people do care about logoff time. I should instead say that logoff processing isn't helped by just in time. For faster logoff, the Citrix Profile Manager code in the field now will sync back only the stuff written during the session, which is much faster than whole copy roaming profiles. If the large financial customer isn't using UPM, they might want to look into it.
Nov 13
Anonymous says:
Interesting. So in effect Citrix Profile Manager is quite unintresting, while RT...Interesting. So in effect Citrix Profile Manager is quite unintresting, while RTO Virtual Profiles is what, in effect, you're argumenting for. Are you saing that Citrix will license Virtual Profiles, or are you saing that Citrix Profile Manager will morph into a model like Virtual Profiles?
Please enlight.
Nov 13
Ross Smith says:
Well considering windows restricts roaming profiles to 30MB, they really shouldn...Well considering windows restricts roaming profiles to 30MB, they really shouldn't be this large. We specifically redirect people's desktop, my documents and application folders to the network so their profiles are just the core elements and logons are nice and fast.
The biggest problem we have is the registry, it's around 10MB on average, and 20-25MB on the more heavily abused machines, with no real way to shrink that down.
Anything that can reduce logon time is still good news as far as I'm concerned though.
Nov 14
Alastair Cunningham says:
Interesting post Joe. As far as I'm aware Citrix User Profile manager does not c...Interesting post Joe. As far as I'm aware Citrix User Profile manager does not currently implement JIT copying of user data - it simply performs a delta copy of the users profile data and HCKU at logon and logoff - is this correct?
Obviously with many profiles containing a significant amount of data that may not be accessed by a user during a typical session, the JIT model would provide significant improvements to logon times, and reduce IO load on XenApp farms (especially during those 8-9AM logon storms) and reduce the amount of data that ends up in the write cache (for PVS delivered hosts). This would be a welcome improvement.
Is there any possibility of this functionality being implemented in the UPM in a future release? Code to copy files locally on-demand already exists in Citrix Application Streaming, and as you're in the advantages position of being across both products it shouldn't be too hard to reuse some of this code in the UPM to implement just-in-time profile management right? Perhaps you could even reuse the filesystem filter driver used by application streaming?
Bear in mind I'm a naive non programmer. I'm sure the real word complexities are far greater than just porting some modules - but I do hope this functionality finds its way into the Citrix UPM solution at some point in the near future.
Nov 15
Rob Beekmans says:
Joe, Good article, but I have to agree with some others that I'm in the underst...Joe,
Good article, but I have to agree with some others that I'm in the understanding that only RTO has JIT in their profile solution, correct me if I'm wrong.
It would certainly be an enhancement to UPM in profile management.
The logon times are important but no project ever failed for long logoff times, requirements always state the seconds for logon.
greetings
Rob
Nov 16
Niraj Patel says:
Interesting article, but I am surprised organizations heavily invested in XenApp...Interesting article, but I am surprised organizations heavily invested in XenApp (and now XenDesktop) would still be using Windows Roaming Profiles... It's obvious that a larger profile is going to constitute a longer login time using traditional Windows Roaming Profiles. The primary reason Citrix UPM and other third party "flex" profile solutions cut down on the login time is because an administrator has defined what settings they would like to have roamed. This is tedious, but the investment pays off in smaller profiles, faster login times and smaller chance of any type of corruption in which the entire user profile needs to be re-created. Personally, I don't prefer the UPM. (I feel other "flex" profile methods are better and more robust), but it obviously leaps and bounds over traditional Windows Roaming Profiles. I guess it is also "free" if you own XenApp/XenDesktop Enterprise or Platinum.
Most "profiles" in organizations I have worked with have profiles between 5-15 MB after implementing flex profiles.
-Niraj
Nov 18
Anonymous says:
Joe, Where do I get JIT profiles? I didn't think UPM did it. I see ...Joe,
Where do I get JIT profiles? I didn't think UPM did it. I see several post asking this question and I don't see an answer. I read the blog going where can I get this and I didn't hear the answer.
Thanks
Nick F
Nov 18
Joseph Nord says:
> I didn't think UPM did it. Hi Nick. You are correct and I am being v...> I didn't think UPM did it.
Hi Nick. You are correct and I am being vague, on purpose.
For now, I just need to get some information on how much of a benefit customers COULD expect to see and unfortunately, the good information I've pulled down in this post has both helped me pick a number and then confirmed that profile size is highly variable. I am going to go with 512MB for study. If the profile is small, the benefit will not be large, but here, the user's won't care anyway because the logon is already fast. What we really care about is nn% savings of profiles of xx size.
As for flex: One of the pluses of using Flex is the small quantity of stuff that has to be synced to/from and this leads to fast logons. The downside of Flex is that the administrator must have deep knowledge of the applications which is something we have worked to avoid with Citrix Profile Manager.
Consider that with JIT and Citrix Profile Manager, you end up with small data transfers + minimal app knowledge required. Would this be a good scenario? Yes, it would.
Joe Nord
Citrix Product Architect of Application Streaming *AND* User Profile Manager
Nov 18
Anonymous says:
Thanks Joe, I was looking for this in the Citrix Profile Manager. I looke...Thanks Joe,
I was looking for this in the Citrix Profile Manager. I looked at Flex a few years ago and it seemed like a lot of work for me the administrator. Every new app requires a lot of work. I really like the idea of streaming it. If anyone could make the streaming work it would be Citrix with Application Streaming and Provisioning Services.
I really like the idea that no matter how large the profile the logon time will be the same.
Here are some numbers for you from my environment.
about 2 hours ago
Anonymous says:
Hi Joe, I think you get the picture....build it. We have a need for JIT with UP...Hi Joe,
I think you get the picture....build it.
We have a need for JIT with UPM.
The only solution that does JIT doesn't support 64bits platforms.
If you can get it in, Citrix will make a large step forward in being THE profile solution for centralized environments.
greetings
Add Comment