All 1 entries tagged OSCache

No other Warwick Blogs use the tag OSCache on entries | View entries tagged OSCache at Technorati | There are no images tagged OSCache on this blog

May 09, 2006

OSCache and SSO

I am responsible for the Web Sign On system at Warwick. Between development and lives services, we have 80 registered services (quite a few duplicates because Blogs for instance is registered on my machine, a test server and the live server) that are allowed to talk to SSO.

SSO is responsible for authenticating users to the web apps and finding and sending attributes about users to those applications. The most heavily hit part of the system is the web service that allows an application to get the details for a usercode. It looks something like this:

https://sso…./userinfo?user=xxxxx

The response is a simple bit of plain text with name/value pairs such as name, email, department, etc… This system has been kept simple for legacy reasons and does not use the complex transport that our Shibboleth/SAML based new SSO uses.

Last time I checked the stats, we had about 40,000 checks for users a day. Each application then caches these requests internally within our Userlookup API. This system has worked quite well for a long time, but recently we have had some reliability problems with NDS so if an application needs to get the names/emails for 100 users for some user listings and those users are not in the applications local cache, they then have 100 web requests to make which are suddenly taking a second or two each when they usually take 200ms each.

Even if SSO is running at full speed, requesting a lot of users at 200ms a time can still add up. With this in mind, we've now added a server side cache at the SSO end of things. OSCache to the rescue. Having never used this before, I wasn't sure how easy it would be, but it was simplicity itself: (approximate code)

try {
_results = (Map) _userByIdCache.getFromCache(getUser(), CACHE_TIMEOUT_SECS);
} catch (NeedsRefreshException nre) {
_userByIdProcessor.process();
_results = _userByIdProcessor.getResults();
_userByIdCache.putInCache(getUser(), _results, new String[] { "all"});
}

I put a wrapper around the existing controller that published the results of the lookup that simply tries to get the results from the cache, if they are not there or have expired, it populates the cache. Simple. A bit of Spring config wires it all in, including a really simple binding of the Cache into the JMX console so I can easily monitor and clear the cache.

The outcome is that we now have a cache that gets quicky populated for the benefit of all client applications because if application A requests user USERA and it takes 200ms, when application B also requests user USERA, it now takes 5ms rather than the previous 200ms.


August 2019

Mo Tu We Th Fr Sa Su
Jul |  Today  |
         1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31   

Tags

Search this blog

Most recent comments

  • One thing that was glossed over is that if you use Spring, there is a filter you can put in your XML… by Mathew Mannion on this entry
  • You are my hero. by Mathew Mannion on this entry
  • And may all your chickens come home to roost – in a nice fluffy organic, non–supermarket farmed kind… by Julie Moreton on this entry
  • Good luck I hope that you enjoy the new job! by on this entry
  • Good luck Kieran. :) by on this entry

Galleries

Not signed in
Sign in

Powered by BlogBuilder
© MMXIX