[JBoss JIRA] (ISPN-10255) Documentation about Near cache eviction
by Donald Naro (Jira)
[ https://issues.jboss.org/browse/ISPN-10255?page=com.atlassian.jira.plugin... ]
Donald Naro updated ISPN-10255:
-------------------------------
Status: Open (was: New)
> Documentation about Near cache eviction
> ---------------------------------------
>
> Key: ISPN-10255
> URL: https://issues.jboss.org/browse/ISPN-10255
> Project: Infinispan
> Issue Type: Bug
> Components: Documentation-Core
> Affects Versions: 9.4.14.Final
> Reporter: Gustavo Lira e Silva
> Assignee: Donald Naro
> Priority: Trivial
>
> The following section is not 100% right:
> When the maximum is reached, near cached entries are evicted using a least-recently-used (LRU) algorithm
> Since JDG 7.2 eviction algorithm use TinyLFU via Caffeine. Maybe this section could be removed because this information is totally irrelevant for the user.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (ISPN-6494) Investigate bundler performance
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/ISPN-6494?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on ISPN-6494 at 8/12/19 6:33 AM:
---------------------------------------------------------
[~johnou] No updates. I want to complete the last JIRA(s) in 4.1.3, then release it and get back to 5.0 work. After that release, I'm willing to tackle this.
{{no-bundler}} has _never_ shown up as top performer in _any_ of my perftests! {{transfer-queue}} has always been near the top, and the lockless- and ringbuffer-based bundlers have been the fastest bundlers around.
If you send many messages (ie. in seperate threads) to the same destinations (including {{null}}), then bundling/batching will get you much better performance, as fewer resources such as threads and locks will be used. Even for OOB messages, which have a different thread dispatching policy, handling a batch of 10 is much more efficient than handling 10 separate messages.
Without knowing your specific access patterns, I venture to say that batching will greatly increase your perf.
Of course, this depends on
* How many threads are sending messages
* To which destinations
* OOB or regular messages
* Configured message processing policy
* Delivery at the application (blocking versus non-blocking delivery) and processing time
Do you have a specific perftest mimicking your application? That would be best to tune perf.
On the JGroups side, we have UPerf and MPerf as part of JGroups (plus IspnPerfTest as separate project on GH).
was (Author: belaban):
[~johnou] No updates. I want to complete the last JIRA(s) in 4.1.3, then release it and get back to 5.0 work. After that release, I'm willing to tackle this.
{{no-bundler}} has _never_ shown up as top performer in _any_ of my perftests! {{transfer-queue}} has always been near the top, and the lockless- and ringbuffer-based bundler have been the fastest bundlers around.
If you send many messages (ie. in seperate threads) to the same destinations (including {{null}}), then bundling/batching will get you much better performance, as fewer resources such as threads and locks will be used. Even for OOB messages, which have a different thread dispatching policy, handling a batch of 10 is much more efficient than handling 10 separate messages.
Without knowing your specific access patterns, I venture to say that batching will greatly increase your perf.
Of course, this depends on
* How many threads are sending messages
* To which destinations
* OOB or regular messages
* Configured message processing policy
* Delivery at the application (blocking versus non-blocking delivery) and processing time
Do you have a specific perftest mimicking your application? That would be best to tune perf.
On the JGroups side, we have UPerf and MPerf as part of JGroups (plus IspnPerfTest as separate project on GH).
> Investigate bundler performance
> -------------------------------
>
> Key: ISPN-6494
> URL: https://issues.jboss.org/browse/ISPN-6494
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> For ISPN-6027 we changed the default JGroups bundler to {{sender-sends-with-timer}}, because it was faster in some of the performance tests. However, IspnPerfTest shows {{transfer-queue-bundler}} to be consistently better, so we need to investigate the bundler choice again.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (ISPN-6494) Investigate bundler performance
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/ISPN-6494?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on ISPN-6494:
--------------------------------
[~johnou] No updates. I want to complete the last JIRA(s) in 4.1.3, then release it and get back to 5.0 work. After that release, I'm willing to tackle this.
{{no-bundler}} has _never_ shown up as top performer in _any_ of my perftests! {{transfer-queue}} has always been near the top, and the lockless- and ringbuffer-based bundler have been the fastest bundlers around.
If you send many messages (ie. in seperate threads) to the same destinations (including {{null}}), then bundling/batching will get you much better performance, as fewer resources such as threads and locks will be used. Even for OOB messages, which have a different thread dispatching policy, handling a batch of 10 is much more efficient than handling 10 separate messages.
Without knowing your specific access patterns, I venture to say that batching will greatly increase your perf.
Of course, this depends on
* How many threads are sending messages
* To which destinations
* OOB or regular messages
* Configured message processing policy
* Delivery at the application (blocking versus non-blocking delivery) and processing time
Do you have a specific perftest mimicking your application? That would be best to tune perf.
On the JGroups side, we have UPerf and MPerf as part of JGroups (plus IspnPerfTest as separate project on GH).
> Investigate bundler performance
> -------------------------------
>
> Key: ISPN-6494
> URL: https://issues.jboss.org/browse/ISPN-6494
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> For ISPN-6027 we changed the default JGroups bundler to {{sender-sends-with-timer}}, because it was faster in some of the performance tests. However, IspnPerfTest shows {{transfer-queue-bundler}} to be consistently better, so we need to investigate the bundler choice again.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (ISPN-10473) Interceptor chain is null for hibernate collection caches
by Moritz Becker (Jira)
[ https://issues.jboss.org/browse/ISPN-10473?page=com.atlassian.jira.plugin... ]
Moritz Becker commented on ISPN-10473:
--------------------------------------
Workaround is to set {{simple-cache="false"}} in infinispan config XML. I copied the default XML config for local hibernate L2 cache and changed it accordingly:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<!--
~ Hibernate, Relational Persistence for Idiomatic Java
~
~ License: GNU Lesser General Public License (LGPL), version 2.1 or later.
~ See the lgpl.txt file in the root directory or <http://www.gnu.org/licenses/lgpl-2.1.html>.
-->
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:9.4 http://www.infinispan.org/schemas/infinispan-config-9.4.xsd"
xmlns="urn:infinispan:config:9.4">
<!-- This configuration is suitable for non-clustered environments, where only single instance accesses the DB -->
<cache-container name="SampleCacheManager" statistics="false" default-cache="the-default-cache" shutdown-hook="DEFAULT">
<jmx duplicate-domains="true"/>
<local-cache-configuration name="the-default-cache" statistics="false" />
<!-- Default configuration is appropriate for entity/collection caching. -->
<local-cache-configuration name="entity" simple-cache="false" statistics="false" statistics-available="false">
<transaction mode="NONE" />
<expiration max-idle="100000" interval="5000"/>
<memory>
<object size="10000" strategy="LRU" />
</memory>
</local-cache-configuration>
<!-- A config appropriate for query caching. Does not replicate queries. -->
<local-cache-configuration name="local-query" simple-cache="false" statistics="false" statistics-available="false">
<transaction mode="NONE"/>
<expiration max-idle="100000" interval="5000"/>
<memory>
<object size="10000" strategy="LRU" />
</memory>
</local-cache-configuration>
<local-cache-configuration name="timestamps" simple-cache="false" statistics="false" statistics-available="false">
<locking concurrency-level="1000" acquire-timeout="15000"/>
<!-- Explicitly non transactional -->
<transaction mode="NONE"/>
<expiration interval="0"/>
<!-- Don't ever evict modification timestamps -->
<memory>
<object strategy="NONE"/>
</memory>
</local-cache-configuration>
<!-- When providing custom configuration, always make this cache local and non-transactional.
To avoid possible leaks, use expiration (max idle time). Optimize for speed.-->
<local-cache-configuration name="pending-puts" simple-cache="false" statistics="false" statistics-available="false">
<transaction mode="NONE"/>
<expiration max-idle="60000" />
</local-cache-configuration>
</cache-container>
</infinispan>
{code}
> Interceptor chain is null for hibernate collection caches
> ---------------------------------------------------------
>
> Key: ISPN-10473
> URL: https://issues.jboss.org/browse/ISPN-10473
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.4.16.Final
> Reporter: Moritz Becker
> Priority: Major
>
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.infinispan.functional.impl.AbstractFunctionalMap.invokeAsync(AbstractFunctionalMap.java:127) ~[infinispan-core-9.4.15.Final.jar:9.4.15.Final]
> at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56) ~[infinispan-core-9.4.15.Final.jar:9.4.15.Final]
> at org.infinispan.hibernate.cache.commons.access.NonStrictAccessDelegate.putFromLoad(NonStrictAccessDelegate.java:118) ~[infinispan-hibernate-cache-commons-9.4.15.Final.jar:9.4.15.Final]
> at org.infinispan.hibernate.cache.v53.impl.CollectionDataAccessImpl.putFromLoad(CollectionDataAccessImpl.java:30) ~[infinispan-hibernate-cache-v53-9.4.15.Final.jar:9.4.15.Final]
> at org.hibernate.engine.loading.internal.CollectionLoadContext.addCollectionToCache(CollectionLoadContext.java:390) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.engine.loading.internal.CollectionLoadContext.endLoadingCollection(CollectionLoadContext.java:295) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.engine.loading.internal.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:223) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.engine.loading.internal.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:196) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.endCollectionLoad(Loader.java:1198) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1162) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:1010) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:948) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2689) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2672) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2506) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2501) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:504) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:395) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:220) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1508) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.query.internal.AbstractProducedQuery.doList(AbstractProducedQuery.java:1537) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1505) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> at org.hibernate.query.Query.getResultList(Query.java:135) ~[hibernate-core-5.3.7.Final-ordami.jar:5.3.7.Final]
> {noformat}
> This is because the collection cache is defined as simple cache and {{org.infinispan.factories.InterceptorChainFactory#construct}} returns null if {{configuration.simpleCache()}} is true. As far as I can see, this behavior has changed in 10.x, commit 55682f391d0f6e28dd6be4ab780cb9e62a639fbd where {{EmptyAsyncInterceptorChain.INSTANCE}} is returned in this case.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (ISPN-6494) Investigate bundler performance
by Johno Crawford (Jira)
[ https://issues.jboss.org/browse/ISPN-6494?page=com.atlassian.jira.plugin.... ]
Johno Crawford commented on ISPN-6494:
--------------------------------------
[~belaban] any updates on this? The default infinispan configurations still reference no-bundler which we currently have configured for our application.
Our application is a little special in the sense that we hijack a fork channel from the infinispan jgroups stack and use that for internal cluster communication and infinispan for various distributed / replicated caches.
I have observed that the message rate is so high that the executor starts rejecting tasks and creating fire and forget threads which really hurts performance.
We would like to investigate bundlers / batching as opposed to increasing thread count to see if that resolves our performance issues.
> Investigate bundler performance
> -------------------------------
>
> Key: ISPN-6494
> URL: https://issues.jboss.org/browse/ISPN-6494
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> For ISPN-6027 we changed the default JGroups bundler to {{sender-sends-with-timer}}, because it was faster in some of the performance tests. However, IspnPerfTest shows {{transfer-queue-bundler}} to be consistently better, so we need to investigate the bundler choice again.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months