back to the AppSense blog

7 Comments

  1. AppSensePros June 1, 2012 4:56 am Reply

    A Friend, do you have the title of the specific scalability document that you believe is contradicting this post? I’d like to look into that. Thanks!

  2. Landon Winburn June 1, 2012 5:19 am Reply

    The scalability document says that grouping applications can cause application caches to become large. This is due to MULTIPLE applications all saving settings to the same cache. Take for instance Office. This group would have settings for Word, Excel, Outlook, etc. If you created a group for mstsc.exe it would only have the terminal server client keys in it. This group would be WAY smaller. Since the settings get downloaded on process start and uploaded on process stop this can affect application launch times. If you only have on application in the group you still only have one applications worth of settings in the cache! This will not affect launch times negatively until the need arises where you may need to group the applications that were once personalized as stand-alone.

    The document also goes on to list cache sizes and number of users per server over a given period of time. This has nothing to do with grouping and more about what you are including and excluding from your cache.

    Landon.

  3. Darren June 1, 2012 8:49 am Reply

    Landonn, you mean if all these applications use cache all together at the same time?

  4. Landon Winburn June 1, 2012 3:42 pm Reply

    My point is the scalabiltiy testing was done on cache sizes and the grouping section within it only says that groups CAN cause large application caches if you put multiple apps in it like office. It then goes on to show different cache sizes and number of users obtained on a given spec server. No where in the document does it say not to group!

    Let me put it this way… The baskets in this case carry no weight but the eggs do. If you put all your eggs in one basket you'd need a fork lift to move it. If you put a single egg in each basket a child could carry it. But maybe your needs change. Maybe you need all the white eggs in one basket. This is by need so you have no choice. While you might not need a forklift to move it the child definately can't carry it but at least you didn't have to throw away one of the baskets. One egg in is still just one egg regardless whether you use a basket or not!

    One app in a group is still just one app and the cache sizes would be identical. The grouping only comes into play if you decided to put all your apps in one cache. Not good! Be sensable with your groups and only group applications when necessary. Point is creating a group for a single app allows you to retain your basket if needed!

  5. Not a friend now June 1, 2012 4:52 pm Reply

    Thank you for the detailed explanation, I didn’t realize that you were in the egg farming business too, but I believe that you have completely missed the point that I was making, let me explain!

    The organization that I work for has thousands of eggs, we have white, mid brown, darker brown, pale brown, light brown, blew green and even pink one’s.

    Being new to egg distribution we were struggling to sort them into baskets. We decided to check the basket vendors website, there best practice documentation, went to their college and then engaged their professional egg distribution team. (Which cost us thousands of dollars)

    All of the above told us “Avoid grouping” and “Complex Configurations” as it will lower the scalability of the egg conveyor. Now the basket vendor is saying, “It’s all about the bubble. Why grouping applications is so brilliant”

    Maybe we should look for a refund on the professional egg distributors charges or the basket vendor should have a single message.

    FYI – from what we are seeing in our setup then the baskets do carry a weight, on the EMP servers CPU when config.aspx is called and on the Personalization database when the stored procedures build the configuration.xml file, but hey its ok “a child could move it”

  6. Landon Winburn June 1, 2012 5:57 pm Reply

    Have a look at your scalabilty document again. It mentions the config handler and the fact that group memberships affect scalability of the config handler. Specifically mentions a 3:1 hit if you use complex group memberships. This explains the huge hit for the config call. Snipit below…

    Personalization configuration
    EM has capability to manage the personalization of applications based on assigned rules like user names, IP address etc. An end point contacts the PS, every 10 min by default, which processes the request based on the Admin assigned rules. The more complex these rules the more time the PS spends delegating I/O calls to services like Active directory, which will reduce the number of supported users at peak time.
    In our internal testing the difference in scalability between a deployment with a default configuration and one with many membership/group rules is approx. 3:1. That is scalability of many rules is a 1/3 of that with no rules.

  7. AppSensePros June 1, 2012 11:56 pm Reply

    Frustrated Friend, your point is well taken. In this case, I can see how you might think we are doing an about-face on this issue. I believe the confusion is because we wrote this blog post with the focus of simplicity and retention of settings while neglecting to address the possible scalability caveats within that same article. Scalability is very important and should have been mentioned. The real goal here is to give you, as the customer, as much information as possible to make the best decision for your organization. While there may be a scalability cost in using grouping for applications, many customers have agreed that the benefits mentioned in this article outweigh those concerns. The problem seems to be that you ended up getting only part of the message. One way or the other, it is our responsibility to correct that and make sure you get one clear message. Our apologies for any confusion and if you’d like further clarification or discussion with us on this please shoot us an email at appsensepros@appsense.com. Thanks!

Post a Comment

Your email address will not be published. Required fields are marked *

*

Copyright ©2011-2012 AppSense
^ Back to Top