{"id":1413,"date":"2011-04-27T17:52:37","date_gmt":"2011-04-27T17:52:37","guid":{"rendered":"https:\/\/www.wapshere.com\/missmiis\/?p=1413"},"modified":"2011-06-30T14:12:55","modified_gmt":"2011-06-30T14:12:55","slug":"performance-implications-of-a-lot-of-sets","status":"publish","type":"post","link":"https:\/\/www.wapshere.com\/missmiis\/performance-implications-of-a-lot-of-sets","title":{"rendered":"Performance implications of a lot of Sets"},"content":{"rendered":"

I’ve been creating lots of Sets lately. Lots and lots. I created over 400 of them and there are around 40k objects\u00c2\u00a0in the system.<\/p>\n

At TEC I found out that no one else seems to have created quite so many Sets so here are my observations.<\/p>\n

<\/p>\n

The FIMService database grew 10-20%<\/h3>\n

I wish I could give a more accurate figure but I wasn’t looking out for a big growth in the DB. I noticed it had jumped in size\u00c2\u00a0the next time I replicated the DB to my test server and there hadn’t been any other big increase in object numbers.<\/p>\n

The FIM MA really slowed down<\/h3>\n

I was doing around 3500 exports through the FIM MA per hour. Everyone knows the FIM MA is not the fastest, but it slowed down so much it started running into the next hour’s sync cycle.<\/p>\n

Discussing this with David Lundell<\/a> made me understand that each change to an object in the FIM Portal causes a re-evaluation of all possible Sets to see if it has now fallen into the scope of any of them. No wonder it slowed down!<\/p>\n

As it happens the vast majority of those hourly changes were “Last Contact Time” attributes, which it has now been agreed only need updating daily. So I’m back to a low number of hourly exports and the problem, while not solved, is at least side-stepped.<\/p>\n

But there are advantages<\/h3>\n

The reasons I have all these Sets are as follows:<\/p>\n

    \n
  1. I want to be able to delegate very specifically which Administrators can modify which Users, and<\/li>\n
  2. I want to target my MPRs to exact scenarios.<\/li>\n<\/ol>\n

    So for example I end up with a lot of Sets named things like “Paris BPOS Active with forwarding address”.<\/p>\n

    And in fact this part of it is working great. IT Admins only have access to change things under the right circumstances, for the right users, and triggering the right Workflows.<\/p>\n

    Why don’t you use “Relative to Resource”<\/h3>\n

    At TEC I was asked why I didn’t cut down the number of Sets by using “Relative to Resource”. While I’d still need “BPOS Active with forwarding address” perhaps this would reduce the need to have a seperate version of the Set for each delegation zone.<\/p>\n

    Unfortunately I don’t see how it would be possible. Users may be administered by multiple IT admins – including their own local support person\/team, a backup support person\/team from another site, and then the global administrators. All these possible people would have to be stamped on each user object and then kept up to date somehow. I honestly think that would be much harder to work with than using Sets, and would probably lead to performance problems of its own.<\/p>\n

    And how do I keep all these Sets up to date?<\/h3>\n

    See my earlier post: A script to create Sets and MPRs from Templates<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

    I’ve been creating lots of Sets lately. Lots and lots. I created over 400 of them and there are around 40k objects\u00c2\u00a0in the system. At TEC I found out that no one else seems to have created quite so many Sets so here are my observations.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":[]},"categories":[42,53,54],"tags":[],"class_list":["post-1413","post","type-post","status-publish","format-standard","hentry","category-fim-2010","category-performance","category-sets"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pkp1o-mN","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts\/1413","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/comments?post=1413"}],"version-history":[{"count":4,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts\/1413\/revisions"}],"predecessor-version":[{"id":1589,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/posts\/1413\/revisions\/1589"}],"wp:attachment":[{"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/media?parent=1413"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/categories?post=1413"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wapshere.com\/missmiis\/wp-json\/wp\/v2\/tags?post=1413"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}