On Sun, May 3, 2009 at 11:28 AM, Les Mikesell <[email protected]> wrote:
> > Pallab Bhattacharya wrote: > >> On Sun, May 3, 2009 at 7:31 AM, Syed Ali <[email protected]> wrote: >> >> How much memory are you giving to it? And how big are your objects? >>> >>> It could be that they get evicted to make space for new ones....and >>> therefore you dont find them in cache >>> >> >> >> it appears from his description that he uses the same key - so when it >> is paced - there is a cache-hit because the first request would have >> populated the cache with the key. >> >> when he tries to race - obviously all threads face the same truth - the >> looked up object is absent - so they all try to replenish the missing >> object hence goes to db simultaneously, >> > > So it is probably the concurrent activity at the db that slows it down and > makes the problem visible. That seems like it might be a common problem is a common problem in caching if not developed carefully - > for sites where new items appear that might be very popular as soon as the > link becomes visible. Is priming the cache as these items are generated the > best way to avoid this yes you can do that - but in real life - simultaneous hit on the same key would happen slowly/rarely - or does it really just show up in automated testing? this is possible - if you use unique keys in both paced and raced test - they should show same behavior for a "given key" (unless of course there is eviction going for whatever reason) -regards -palalb > > > -- > Les Mikesell > [email protected] > >
