[jboss-user] [JBossCache] - Re: JBC 2 performance

[aditsu]

"manik.surtani at jboss.com" wrote : 
  | I don't bother protecting/synchronizing the maps [...] as I assume that any locking happens on a higher level
  | 

Oh, I see. So it should work with the raw HashMap's then, since the locks take care of the synchronization.

"manik.surtani at jboss.com" wrote : 
  | Performance not great, in relation to 1.4.1?  Or in an absolute sense?  What's your setup, how is your cluster configured, do you use cache loaders, eviction?
  | 

In an absolute sense. Just trying to see how many transactions/s I can get, and where the bottleneck is. It's not bad actually.
I'm running everything on localhost for now, with one cache instance; settings are: REPL_SYNC, READ_COMMITTED, DummyTransactionManagerLookup, no cache loader and no eviction. I'm manually preloading all the "working data" from a db and inserting into the cache, and then using a listener for writing back the changes in an async manner (in batches).

There are lots of elements in the equation, JBC is just one of them. I have changed much of the app code along the way, it's actually not stressing JBC so much anymore (e.g. I used to have indexes stored in the cache but I moved them out). Btw, I should probably try stressing it again to verify that the bug is really fixed.

My impression is that the cache is doing OK now; still, I'm doing some ugly stuff with it that could probably be improved, such as explicit locking/unlocking (across transactions) using "marker" nodes, avoiding deadlock-timeouts using random waits, and even using a listener instead of a cache loader. I mentioned them in other threads, and you already gave some suggestions & fixed bugs, I'll just have to try them out.

Thanks
Adrian

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069083#4069083

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069083