ILM 2 Beta - Changing the Portal Configuration Refresh Timeout

One of the more frustrating things about testing things that involve a cache is that you're either waiting for the cache to timeout to see your changes take effect or you're constantly forcing the cache to reinitialize so you can see the changes right away. It's this impatience that drives us to find better ways to do better - we want instant gratification after all! With ILM 2 we have just such a situation where you will find yourself running IISRESET to see your changes enacted. Here is why - the portal refreshes its configuration every 10 minutes (600 seconds) by default. Can you change this you might ask, why certainly! Here is how you go about it:

• In the Administration Settings page (you get here by clicking one of the Administration link headers) you'll see a link for Portal Configuration, click it
• There is only one object of type PortalUIConfiguration and this link takes you directly there, click the Extended Attributes tab

There are three cache values you can tweak here:

Attribute	Default	Description
Cache Time	600	This value controls how often the portal configuration is refreshed
Count Cache Time	60	This value controls how often the count elements (My Approvals (2)) are refreshed
User Cache Time	600	This value controls how long the UI user data will stay on the cache before it expires

Setting Cache Time to say, 15 or 30 seconds would speed up how often the configuration object refreshes and absolve you from having to do a full IISRESET every time you make a configuration change! I'm honestly not certain what the User Cache Time setting does as it is a bit ambiguous.

Now, since Beta 3 doesn't involve AJAX or Silverlight, you will have to manually refresh the page, but you will not need to do the reset. I sincerely hope that the Product Group takes our advice (and the advice of others) and implements AJAX at least on these pages to remove the unattractive page refreshes necessary. I would also like to point out that it is far too early to tell what long term performance impacts changing these setting might have, so I would restrict making this change to your DEV and QA environment only; leave Production at the default to play it safe.