[JBoss JIRA] Created: (ISPN-663) Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0
by Paul Nardone (JIRA)
Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0
--------------------------------------------------------------------------------
Key: ISPN-663
URL: https://jira.jboss.org/browse/ISPN-663
Project: Infinispan
Issue Type: Bug
Components: Eviction, Loaders and Stores
Affects Versions: 4.1.0.Final
Environment: Win32 JRE 1.6.0_21
Reporter: Paul Nardone
Assignee: Manik Surtani
Attachments: InfinispanPassivationTest.java
Eviction with passivation enabled using the JdbmCacheStore appears to be significantly slower in 4.1.0.FINAL vs 4.0.0.FINAL.
The degredation in performance is so signficant to make it impossible to use
The performance issue seems to due as the JdbmCacheStore synching the filesystem via FileDescriptor.sync() or similar which occurs during every object passivation and each passivation occurs as a new object is added beyond the EvictionMaxEntries capacity.
The attached test inserts 1000 values into two caches
Both caches use a JdbmCacheStore and LRU
PASSIVATIONLRU10 runs with cache with EvictionMaxEntries 10
PASSIVATIONLRU1000 runs with cache with EvictionMaxEntries 1000
4.1.0.FINAL
PASSIVATIONLRU10 Time Taken : 51704
PASSIVATIONLRU1000 Time Taken : 4484
4.0.0.FINAL
PASSIVATIONLRU10 Time Taken : 281
PASSIVATIONLRU1000 Time Taken : 141
4.2.0.ALPHA2
PASSIVATIONLRU10 Time Taken : 51047
PASSIVATIONLRU1000 Time Taken : 5156
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (ISPN-360) create NodeJoined event
by Mircea Markus (JIRA)
create NodeJoined event
-----------------------
Key: ISPN-360
URL: https://jira.jboss.org/jira/browse/ISPN-360
Project: Infinispan
Issue Type: Feature Request
Components: Listeners, State transfer
Reporter: Mircea Markus
Assignee: Manik Surtani
In relation to http://community.jboss.org/message/529547#529547
It's an well known scenario to start a cluster, and only after the ENTIRE cluster is started to start and do work. Right now, we have CacheStarted and ViewChanged notifications. First only tells us that the local node is started but other nodes might still be in the process of starting. Second one tells us that the view has changed, but not that the cluster has started, i.e. the cache might be in the process of rebalancing state etc.
A possible solution would be to have an NodeJoined event, that would be called whenever a new node finished joining the cluster. Finished joining means state transfer happened and that node is started.
For a possible workaround to this feature see the forum post.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] Created: (ISPN-530) Hot Rod client should load balance between different owners for a key
by Galder Zamarreno (JIRA)
Hot Rod client should load balance between different owners for a key
---------------------------------------------------------------------
Key: ISPN-530
URL: https://jira.jboss.org/browse/ISPN-530
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Reporter: Galder Zamarreno
Assignee: Mircea Markus
Fix For: 5.0.0.BETA1
While doing the demo for JUDCon, I realised that smart routing on the client side always choses the same node for the same key.
IOW, assume you have k1 stored in nodes A, B and the cluster is formed of nodes A, B and C. Now, when the client figures out that the owner is A, any further requests on k1 will be sent to A. This has the possibility of overloading A.
I think the client should, from the given list of owners of a key, do round robin between them for requests on the same key.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] Created: (ISPN-792) Migrate to David's JBoss Logging
by Galder Zamarreño (JIRA)
Migrate to David's JBoss Logging
--------------------------------
Key: ISPN-792
URL: https://jira.jboss.org/browse/ISPN-792
Project: Infinispan
Issue Type: Feature Request
Reporter: Galder Zamarreño
Assignee: Manik Surtani
Based on what David Lloyd said in the AS7 podcast, it performs much better than log4j and in particular, when it comes to log level checks (it apparently uses volatile int checks).
This could have a direct impact on the Infinispan performance since we do a fair few level checks.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months