The overhead is absolutely minimal - it's generally around 2-5 milliseconds. And worst I've ever seen is around 50 milliseconds (remember that's still only 5/100s of a second). This includes doing a join of data.Are Symlabs, Radiant Logic and other vendors seeing the same results? Perhaps, a skilled SI may want to chime in? If so, then why does anyone use a persistent cache? Anyone?
Also, Blink Technologies put the following comment on my previous post:
I thought the whole point of the cache is to lighten the load against the system as a whole. It's a compromise of data freshness for performance. Plus the entire point of a cache is to "cache" frequently used data, of course depending on the algorithm used (LRU, MRU, etc.). I also assume that the cache is adjustable and can have specific timeouts for freshness. I think for a highly trafficked directory this is a great trade-off.
Posts
6 comments:
Ash, my 2 cents here:
http://360tek.blogspot.com/2009/02/weighing-in-on-persistent-cache.html
Ash, I think you make some good points and its worth looking at further to clarify what we are really talking about...
http://identityinfrastructure.blogspot.com/2009/02/why-cache-and-virtual-directories.html
The great thing about virtual directories is the flexibility. In some cases you may not need to cache, but in other situations those types of capabilities can be useful. There are many ways to use caching in the world of virtual directories. A simple example is as follows:
* Company A is made up of 10 divisions that are overseen by a parent company
* The parent company is located in Chicago while the divisions are scattered across the country
* Historically each division has hosted their own identity infrastructure
* The parent company processes all contracts and has the master repository for customer entitlement information - this repository is in a database that is only located in Chicago and can not be easily replicated
* Company A has a long term vision that they will one day be able to consolidate their identity infrastructure all within the parent company but that is years away
* Branch 1 has several customer facing applications that authenticate users against a local LDAP directory
* Branch 1 has a new customer facing application that requires the ability to restrict access to information based upon the products the customer has purchased
There are probably many ways to solve this problem, but since we are talking about virtual directories... By setting up an instance of the virtual directory at Branch 1 I can then:
* Create a cached view of the information from the database in Chicago
* Set up a proxied view of the users in the local LDAP directory
* Join the user information proxied from the local LDAP with the cached information from the database
This provides the additional information that the new application requires without the application needing to change anything except perhaps an IP address. At the same time delivers the benefit of not traversing the WAN repeatedly for authorization information.
So, it is a benefit to have options like this.
Todd
Ash, Symlabs comments can be found here
http://blog.symlabs.com/identity-matters-journal/2009/2/17/virtual-directory-servers-and-cache.html
cheap wow power leveling buy wow gold cheapest wow power leveling CHEAP wow gold BUY power leveling CHEAPEST wow powerleveling
wow goldwow goldwow goldwow goldweiwei
We usually like to use persistent caching in instances where the performance/availability on some of our backend data stores housing universally interesting information is spotty.
We could spend money and upgrade that data store's servers or spend even more money to create a real metadirectory solution and replicate the data off somewhere else. Spending that money is pretty hard to justify, though, when persistent caching is (relatively) cheap.
Post a Comment