You are looking at documentation for an older release. Not what you want? See the current release documentation.
This section will show you possible ways of improving JCR.
It is intended for eXo Platform administrators and those who want to use JCR features.
You can use maxThreads parameter to
increase maximum amount of threads that can be launched in AS instance.
This can improve performance if you need a high level of concurrency.
Also, you can use the -XX:+UseParallelGC java directory to use
parallel garbage collector.
Beware of setting maxThreads too big,
this can cause OutOfMemoryError. There is maxThreads=1250 on the machine:
7.5 GB memory
4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each)
850 GB instance storage (2×420 GB plus 10 GB root partition)
64-bit platform
I/O Performance: High
API name: m1.large
java -Xmx 4g
Cache size: The JCR-cluster implementation is built using JBoss Cache as distributed, replicated cache. But there is one particularity related to remove action in it. Speed of this operation depends on the actual size of cache. Because there are currently many nodes in cache, it will take you much time to remove any specific node (subtree) from the cache.
Eviction: Manipulations with eviction wakeUpInterval
value does not affect performance. Performance results with values
from 500 up to 3000 are approximately equal.
Transaction Timeout: Using short timeout for long transactions, such as Export/Import,
removing huge subtree defined timeout, may cause TransactionTimeoutException.
For performance, it is better to have loadbalancer, the database server, and
shared NFS on different computers. If one node gets more load than others, you can decrease this load by using the load
value in the load balancer.
JGroups configuration: It is recommended that you use the "multiplexer stack" feature available in JGroups. This feature is set by default in eXo JCR that offers higher performance in cluster and reduces the network connections. If there are two or more clusters in your network, check that they use different ports and different cluster names.
Also, the thread pool configurations can be tuned to prevent ReplicationTimeoutException, like below:
thread_pool.min_threads="10" thread_pool.max_threads="1000" thread_pool.queue_max_size="1000" oob_thread_pool.min_threads="5" oob_thread_pool.max_threads="1000" oob_thread_pool.queue_max_size="1000"
Write performance in cluster: The eXo JCR implementation uses Lucene indexing engine to provide search capabilities. However, Lucene causes some limitations for write opertation, for example, it can perform indexing only in one thread. That is why the write performance in cluster is not higher than that in a singleton environment. Data is indexed on coordinator node, so increasing write-load on cluster may lead to ReplicationTimeout exception. It occurs because writing threads queue in the indexer and under high load timeout for replication to coordinator will be exceeded.
It is recommended to exceed the
replTimeout
value in cache configurations in case
of high write-load.
Replication timeout: Some operations may take too much time. So if you get
ReplicationTimeoutException, try
increasing the replication timeout:
<clustering mode="replication" clusterName="${jbosscache-cluster-name}">
...
<sync replTimeout="60000" />
</clustering>
The value is set in miliseconds.
PermGen space size: If you intend to use Infinispan, you will have to increase the PermGen size to at least 256 Mo due to the latest versions of JGroups that are needed by Infinispan (please note that Infinspan is only dedicated to the community for now, no support will be provided). In case you intend to use JBoss Cache, you can keep using JGroups 2.6.13.GA which means that you do not need to increase the PermGen size.
Some databases support hints to increase query performance (like Oracle, MySQL, and more). eXo JCR have separate Complex Query implementation for Orcale dialect, that uses query hints to increase performance for few important queries.
To enable this option, put next configuration property:
<workspace name="ws" auto-init-root-nodetype="nt:unstructured">
<container class="org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer">
<properties>
<property name="dialect" value="oracle"/>
<property name="force.query.hints" value="true" />
......
The Query hints are enabled by default.
eXo JCR uses query hints only for Complex Query Oracle dialect. For all other dialects, this parameter is ignored.