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 infinispan 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.
Remote timeout: In SYNC mode, the timeout used to wait for an acknowledgment when making a remote call, after which the call is aborted and an exception is thrown.
<clustering mode="replication">
...
<sync replTimeout="20000"/>
</clustering>
The value of remote-timeout is set in miliseconds.
Acquire timeout: The maximum time to attempt a particular lock acquisition.
<locking isolation="READ_COMMITTED" concurrency-level="500" striping="false" write-skew="false" acquire-timeout="${exo.cache.lockacquisitiontimeout:180000}"/>
The value is also set in miliseconds.
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.