Disabling Alfresco features

You can disable common product components if you do not require them for your Alfresco instance. This summary gives the example property settings for disabling the main components.

Note: If you are unsure of the effect of disabling a feature, contact Alfresco Support for recommendations.

Add the following property settings to the alfresco-global.properties file.

Property	Description
system.usages.enabled=false	Disables quotas or user usages. Note: When using Enterprise to Cloud Sync, avoid setting this property to true, as the service may be impacted. For example, when a quota is reached and it is no longer possible to push new content to the on-premise Alfresco, you will still be able to push content to the Cloud (new version or new content). The on-premise Alfresco will attempt to pull the modifications locally but will fail because of the quota limit, and this may cause an inconsistency between Cloud and on-premise Alfresco.
replication.enabled=false	Disables content replication.
audit.enabled=false	Specifies a way to globally enable or disable the auditing framework.
cifs.enabled=false	Specifies whether to enable or disable the CIFS server.
ftp.enabled=false	Specifies whether to enable or disable the FTP server.
system.workflow.engine.jbpm.enabled=false	Specifies whether to enable or disable the jBPM workflow engine. The jBPM workflow engine is disabled by default.
system.workflow.engine.activiti.enabled=false	Specifies whether to enable or disable the Activiti workflow engine. The Activiti workflow engine is enabled by default.
transferservice.receiver.enabled=false	Disables the Transfer or Replication Service receiver.
sync.mode=OFF	Use this property to disable synchronization permanently.
lucene.indexer.cacheEnabled=false	Specifies whether to enable or disable index level caching.
lucene.indexer.contentIndexingEnabled=false	Specifies whether or not the content of the document is indexed. If false, content is not indexed.
index.tracking.cronExpression=* * * * * ? 2099	Specifies the scheduled Lucene index tracking for the future. Note: Do not use this property if you are using `index.subsystem.name=lucene`
audit.alfresco-access.enabled=false	To enable generation of audit data that you can view in Explorer or Share, you will need to enable the `audit.alfresco-access.enabled` property.
audit.filter.alfresco-access.default.enabled=false	Disables auditing of Alfresco accesses. Note: Do not use this property if you require auditing.
home.folder.creation.eager=false	Disables the automatic creation of home folder for new users.
db.schema.update=false	Specifies whether the system bootstrap should create or upgrade the database schema automatically.
syncService.mode=OFF	Disables Enterprise to Cloud Sync.
activities.feed.notifier.enabled=false	Disables the Share Activities email notification.
sync.pullJob.enabled=false	Use this Enterprise to Cloud Sync property to disable synchronization temporarily.
sync.pushJob.enabled=false	Use this Enterprise to Cloud Sync property to disable synchronization temporarily.

Default port numbers and services

This summary gives you a list of the port numbers relevant to the services that Alfresco runs, and where to change them.

Tomcat settings and ports

If you are running Alfresco on Tomcat then tomcat itself may be listening on some ports. These ports are configured in the tomcat/conf/server.xml file.

HTTP 8080

HTTPS 8443

Shutdown Port 8005

AJP 8009

This port is configured in the tomcat/bin/catalina.sh file:

JPDA 8000

Alfresco context inside Alfresco configuration

These ports are configured in the <classpathRoot>/alfresco-global.properties file.

alfresco.port=8080

Share context inside Alfresco configuration

This port is configured in the <classpathRoot>/alfresco-global.properties file. If repository ports are changed, you can change the Alfresco Share connection ports in the <web-extension>/share-config-custom.xml file.

share.port=8080

Alfresco SharePoint Protocol

These ports are configured in the <classpathRoot>/alfresco-global.properties file.

vti.server.port=7070

vti.server.external.port=7070

OpenOffice – LibreOffice

This port is configured in the <classpathRoot>/alfresco-global.properties file.

ooo.port=8100

JodConverter

This port is configured in the <classpathRoot>/alfresco-global.properties file.

jodconverter.portNumbers=8100

FTP

This port is configured in the <classpathRoot>/alfresco-global.properties file. It can be mapped to non-privileged ports, then use firewall rules to forward requests from the standard ports.

ftp.port=21

CIFS – SMB shared drive

These ports are configured in the <classpathRoot>/alfresco-global.properties file. Can be mapped to non-privileged ports, then use firewall rules to forward requests from the standard ports.

cifs.tcpipSMB.port=445

cifs.netBIOSSMB.sessionPort=139

cifs.netBIOSSMB.namePort=137

cifs.netBIOSSMB.datagramPort=138

IMAP

This port is configured in the <classpathRoot>/alfresco-global.properties file. Can be mapped to non-privileged ports, then use firewall rules to forward requests from the standard ports.

imap.server.port=143

Inbound Email (SMTP)

This port is configured in the <classpathRoot>/alfresco-global.properties file. Can be mapped to non-privileged ports, then use firewall rules to forward requests from the standard ports.

email.server.port=25

NFS server

These ports are configured in the <classpathRoot>/alfresco-global.properties file. Mount/NFS server ports, 0 will allocate next available port

nfs.mountServerPort=0

nfs.nfsServerPort=2049

RPC registration port

A setting of 0 will allocate next available port. Some portmapper/rpcbind services require a privileged port to be used

nfs.rpcRegisterPort=0

Disable NFS and mount server registering with a portmapper set

These ports are configured in the <classpathRoot>/alfresco-global.properties file.

nfs.portMapperPort to -1

nfs.portMapperPort=111

Cluster with Hazelcast

This port is configured in the <classpathRoot>/alfresco-global.properties file.

alfresco.hazelcast.port=5701

From Solr to Alfresco workspace queries

These ports are configured in the ./alf_data/solr/workspace-SpacesStore/conf/solrcore.properties file.

alfresco.port=8080

alfresco.port.ssl=8443

From Solr to Alfresco archive queries

These ports are configured in the ./alf_data/solr/archive-SpacesStore/conf/solrcore.properties file.

alfresco.port=8080

alfresco.port.ssl=8443

From Alfresco to Solr queries

These ports are configured in the <classpathRoot>/alfresco-global.properties file.

solr.port=8080

solr.port.ssl=8443

RMI service JMX ports

These ports are configured in the <classpathRoot>/alfresco-global.properties file.

alfresco.rmi.services.port=50500

avm.rmi.service.port=0

avmsync.rmi.service.port=0

attribute.rmi.service.port=0

authentication.rmi.service.port=0

repo.rmi.service.port=0

action.rmi.service.port=0

deployment.rmi.service.port=0

Monitoring RMI

This port is configured in the <classpathRoot>/alfresco-global.properties file.

monitor.rmi.service.port=50508

Repository system configuration files

The Alfresco system configuration files are in the application WAR file. When the server starts, the files expand to <configRoot>.

The path for <configRoot> is different depending on your application server. For example:

Tomcat: <TOMCAT_HOME>\webapps\alfresco\WEB-INF
JBoss: <JBOSS_HOME>\server\default\tmp\deploy\tmp*alfresco-exp.war\WEB-INF

The system configuration files are maintained by Alfresco and contained in <configRoot> and <configRoot>\classes\alfresco.

The preferred method of configuring Alfresco is to extend the default files using the global properties file (alfresco-global.properties).

The following files represent the core of the application configuration:

<configRoot>\classes\alfresco\application-context.xml
This file is the starting point of the Spring configurations. This file only performs imports, including a wild card import of all classpath*:alfresco/extension/*-context.xml files.
<configRoot>\classes\alfresco\core-services-context.xml
Core Alfresco beans are defined here, including the importing of properties using the repository-properties bean.
<configRoot>\classes\alfresco\repository.properties
This file is imported by the repository-properties bean. The file defines the core system properties, including:
- dir.root
  
  This folder is where the binary content and indexes are stored. The alf_data folder is where they are stored by default, but you should change this to your own location. The path is relative by default, but it must point to a permanent, absolute, backed-up location for data storage.
- dir.indexes
  This folder contains all Lucene indexes and deltas against those indexes.
  Note: Alfresco recommends that you do not store Lucene indexes on an NFS volume. The indexes must be on a local disk. For best performance, use a separate hardware chain (for example, controller, disk, and so on) to avoid I/O contention with other operations, like storing content and other applications.
  
  When using the Lucene index subsystem, make sure the disk is local to the web application server. Alfresco recommends the use of an SSD drive to store the indexes. When using Solr, the indexes are local to the Solr server. If a disk full error occurs while the system is running, this can lead to indexes corruption. Avoid disk full errors by leaving sufficient free disk on the indexes partition. Index subsystems merge the indexes, so if you use the current amount of disk space used to store your indexes to evaluate future needs in disk space, be sure you multiply this value by 2. If you want to evaluate the disk space needed to store Solr indexes when you switch from Lucene to Solr, also multiply the Lucene index size by 2. In Solr, most of the content is indexed twice: once using the locale of the document, and once using the standard analyzer.
- db.*
  
  These are the default database connection properties.
- db.schema.update
  This property controls whether the system bootstrap should create or upgrade the database schema automatically.

Tuning the JVM

The hardware requirements for the Alfresco repository and Share are variable and depend on the number of concurrent users that access the system. You can tune the memory and garbage collection parameters for the JVM to be appropriate for your situation.

Hardware

Important: This section suggests metrics and estimates, but your system may vary.

Note: In the following sections, the terms concurrent users and casual users are used. Concurrent users are users who are constantly accessing the system through Alfresco with only a small pause between requests (3-10 seconds maximum) with continuous access 24/7. Casual users are users occasionally accessing the system through the Alfresco or WebDAV/CIFS interfaces with a large gap between requests (for example, occasional document access during the working day).

Alfresco degrades gracefully on low-powered hardware, and small installations can run well on any modern server. However, for optimum performance, we recommend the following:

Use 64 bit systems only. Benchmarks show a significant performance gain when using 64 bit hardware and a 64 bit JRE.
Use a system with a clock speed above 2.5 GHz.
Reserve enough RAM for your operating system beyond the memory required for your JVM.
Keep search indexes on your local disk instead of on network storage.

Disk space usage

The size of your Alfresco repository defines how much disk space you will need; it is a very simple calculation. Content in Alfresco is, by default, stored directly on the disk. Therefore, to hold 1000 documents of 1 MB will require 1000 MB of disk space. You should also make sure there is sufficient space overhead for temporary files and versions. Each version of a file (whether in DM or WCM) is stored on disk as a separate copy of that file, so make allowances for that in your disk size calculations (for DM, use versioning judiciously).

Note: The disk space usage calculation above is only for content storing. It does not take into account any indexes (Lucene or Solr).

Use a server class machine with SCSI Raid disk array. The performance of reading/writing content is almost solely dependent on the speed of your network and the speed of your disk array. The overhead of the Alfresco server itself for reading content is very low as content is streamed directly from the disks to the output stream. The overhead of writing content is also low but depending on the indexing options (for example, atomic or background indexing), there may be some additional overhead as the content is indexed or metadata is extracted from the content in each file.

Virtualization

Alfresco runs well when virtualized, but you should expect a reduction in performance. When using the rough sizing requirements below, it may be necessary to allocate twice as many resources for a given number of users when those resources are virtual. Para-virtualization, or virtualized accesses to native host volumes do not require as many resources. Benchmarking your environment is necessary to get a precise understanding of what resources are required.

JVM memory and CPU hardware for multiple users

The repository L2 Cache, plus initial VM overhead, plus basic Alfresco system memory, is setup with a default installation to require a maximum of approximately 1024MB.

This means that you can run the Alfresco repository and web client with many users accessing the system with a basic single CPU server and only 1024MB of memory assigned to the Alfresco JVM. However, you must add additional memory as your user base grows, and add CPUs depending on the complexity of the tasks you expect your users to perform, and how many concurrent users are accessing the client.

Note: Note that for these metrics, N concurrent users is considered equivalent to 10xN casual users that the server could support.

Number of users	Recommended memory / CPU settings per server
For 50 concurrent or up to 500 casual users	2 GB JVM RAM 2x server CPU (or 1xDual-core)
For 100 concurrent users or up to 1000 casual users	4 GB JVM RAM 4x server CPU (or 2xDual-core)
For 200 concurrent users or up to 2000 casual users	8 GB JVM RAM 8x server CPU (or 4xDual-core)

Note: For full performance tuning, contact Alfresco Support or Alfresco Consulting.

Calculate the memory needed for Solr nodes

Solr can have high memory requirements. You can use a formula to calculate the memory needed for the Alfresco internal data structures used in Solr for PATH queries and read permission enforcement.

By default, there are two cores in Solr: WorkspaceSpacesStore and ArchiveSpacesStore. Normally, each core has one searcher but can have a maximum of two searchers.

In the calculation:

N = refers to the number of nodes in the store. Each core's value is calculated separately. If there are more than two cores, you will need to add additional queries to calculate the value for that core (as shown in the example code block).
T = refers to the number of transactions in the repository and this is same for each core
A = refers to the number of ACLs in the repository and this is same for each core
X = refers to the number of ACL transactions in the repository and this is same for each core

The values for N, T, A and X come from the database. Use the following commands to derive these values:

select * from
(select count( * ) N_Alfresco from alf_node where store_id = (select id from alf_store where protocol = 'workspace' and identifier = 'SpacesStore')) as N1 ,
(select count( * ) N_Archive from alf_node where store_id = (select id from alf_store where protocol = 'archive' and identifier = 'SpacesStore')) as N2 ,
(select count( * ) T from alf_transaction ) as T,
(select count( * ) A from alf_access_control_list ) as A,
(select count( * ) X from alf_acl_change_set) as X;

For example, if there are three cores, include additional queries to calculate the value for that core, as shown:

select * from
(select count( * ) N_Alfresco from alf_node where store_id = (select id from alf_store where protocol = 'workspace' and identifier = 'SpacesStore')) as N1 ,
(select count( * ) N_Archive from alf_node where store_id = (select id from alf_store where protocol = 'archive' and identifier = 'SpacesStore')) as N2 ,
(select count( * ) N_Version2 from alf_node where store_id = (select id from alf_store where protocol = 'workspace' and identifier = 'version2Store'))as N3 , 
(select count( * ) T from alf_transaction ) as T,
(select count( * ) A from alf_access_control_list ) as A,
(select count( * ) X from alf_acl_change_set) as X;

Memory calculation for the Alfresco data structures associated with one searcher

For a store containing 100M nodes, 100M transactions, 100M ACLs and 100M ACL transactions, 20.1 GB of memory is needed. Assuming there are not many ACLs or ACL changes, for 100M nodes, you will need 12 GB to 16 GB of memory depending on the number of transactions. This calculation is based on the following formula: 120N + 32(T + A + X) bytes.

Memory calculation for the Solr caches associated with one searcher

The Solr cache will use up to (2N + T + A + X)/8 bytes for an entry in any cache.

The formula to calculate the total memory needed for the caches for a single core is: (solr.filterCache.size + solr.queryResultCache.size + solr.authorityCache.size + solr.pathCache.size) * (2N + T + A + X)/8 bytes

So, for 100M documents and 100M transactions, 150 GB of memory is needed using the out of box configuration.

(512 + 1024 + 512 + 512)(500M)/8 = 150 GB

The default cache values needs to change to accommodate a large repository. So, for 100M documents, 100M transactions and reduced cache size, 19 GB of memory is needed.

(64 + 128 + 64 + 64)(500M)/8 = 19 GB

Important: The Solr memory requirement can increase exponentially depending on the search/sort being performed. The memory needed rapidly adds up in the following situations:

Sorting a large result set
Long running queries
Queries with many terms
Running multiple queries simultaneously

Solr memory planning

For the Alfresco JVM, the most important parameter is -Xmx, which controls the heap. The specified formula helps to evaluate the memory required by Solr and for capacity planning. Solr memory requirements increase with the size of the repository but also with the amount of memory you allocate to the Solr caches. Decreasing the Solr cache parameters can dramatically lower the memory requirements, with the drawback of hitting the disk more often. You can set these parameters to different values for the each of the stores.

solr.filterCache.size
solr.queryResultCache.size
solr.authorityCache.size
solr.pathCache.size

Overall Solr memory use

This example is based on the data provided above.

For WorkspaceStore: Assuming that there are 100M docs, 100M TXs, 1M ACLs and ACL TXs, cache size of 64 entries each for FilterCache, AuthorityCache and QCache, and 128 entries for PathCache, between 12 GB to 20 GB of memory is needed per searcher. Normally, there is one searcher live but around commit time there can be two searchers. So, approximately 34 GB to 50 GB of memory will be needed in total.

For Archivestore: Assuming that there are 100M transactions, 10M docs and all caches are tuned down, between 4.4 GB to 5.3 GB of memory is needed per searcher. Total memory needed for both the searchers will be between 9 GB to 11 GB.

So, the total memory requirement for both the cores is between 43 GB to 61 GB.

The following diagram shows the overall memory use for a Solr node as explained in the example:

Minimize the memory requirements for Solr nodes

Reduce the cache sizes and check the cache hit rate.
Disable ACL checks using alfresco.doPermissionChecks=false
Disable archive indexing, if you are not using it.
Check the number of empty transactions. If there are many empty transactions, purge the transactions from Alfresco using the action=FIX action.
Find the exact number of nodes in the store (N), exact number of transactions in the repository (T), number of ACLs (A) and related ACL transactions in the repository (X).
Since everything scales to the number of documents in the index, add the Index control aspect to the documents you do not want in the index.

Advanced database configuration properties

As an administrator, you need to edit some advanced properties to customize your database configuration. Many properties, however, do not need to be edited.

Alfresco Enterprise supports Oracle, Microsoft SQL Server, DB2, as well as MySQL and PostgreSQL.

The advanced database configuration properties are categorized into two groups based on their relevance:

properties that you SHOULD edit
properties that you COULD edit

The following table describes the properties that you SHOULD edit:

Property name	Description	Default value
`db.txn.isolation`	The JDBC code number for the transaction isolation level, corresponding to those in the `java.sql.Connection` class. The value of -1 indicates that the database's default transaction isolation level should be used. For the Microsoft SQL Server JDBC driver, the special value of 4096 should be used to enable snapshot isolation.	`-1`
`db.pool.initial`	The number of connections opened when the pool is initialized.	`10`
`db.pool.validate.query`	The SQL query that will be used to ensure that your connections are still alive. This is useful if your database closes long-running connections after periods of inactivity.	For Oracle database, use `select 1 from dual` For MySQL database, use `select 1` For SQL Server database, use `select 1` For PostgreSQL database, use `select 1`

Property name

Description

Default value

db.txn.isolation

The JDBC code number for the transaction isolation level, corresponding to those in the java.sql.Connection class. The value of -1 indicates that the database's default transaction isolation level should be used. For the Microsoft SQL Server JDBC driver, the special value of 4096 should be used to enable snapshot isolation.

-1

db.pool.initial

The number of connections opened when the pool is initialized.

10

db.pool.validate.query

The SQL query that will be used to ensure that your connections are still alive. This is useful if your database closes long-running connections after periods of inactivity.

For Oracle database, use select 1 from dual

For MySQL database, use select 1

For SQL Server database, use select 1

For PostgreSQL database, use select 1

The following table describes the properties that you COULD edit:

Property name	Description	Default value
`db.pool.statements.enable`	A Boolean property. When set to `true` it indicates that all pre-compiled statements used on a connection will be kept open and cached for reuse.	`true`
`db.pool.statements.max`	The maximum number of pre-compiled statements to cache for each connection. The Alfresco default is 40. Note that Oracle does not allow more that 50 by default.	`40`
`db.pool.idle`	The maximum number of connections that are not in use kept open.	`-1`
`db.pool.max`	The maximum number of connections in the pool. See the Note below for more information on this property.	`275`
`db.pool.min`	The minimum number of connections in the pool.	`0`
`db.pool.wait.max`	Time (in milliseconds) to wait for a connection to be returned before generating an exception when connections are unavailable. A value of 0 or -1 indicates that the exception should not be generated.	`-1`
`db.pool.validate.borrow`	A Boolean property. When set to `true` it indicates that connections will be validated before being borrowed from the pool.	`true`
`db.pool.validate.return`	A Boolean property. When set to `true` it indicates that connections will be validated before being returned to the pool.	`false`
`db.pool.evict.interval`	Indicates the interval (in milliseconds) between eviction runs. If the value of this property is zero or less, idle objects will not be evicted in the background.	`-1`
`db.pool.evict.idle.min`	The minimum number of milliseconds that a connection may remain idle before it is eligible for eviction.	`1800000`
`db.pool.evict.validate`	A Boolean property. When set to `true` it indicates that the idle connections will be validated during eviction runs.	`false`
`db.pool.abandoned.detect`	A Boolean property. When set to `true` it indicates that a connection is considered abandoned and eligible for removal if it has been idle longer than the `db.pool.abandoned.time`.	`false`
`db.pool.abandoned.time`	The time in seconds before an abandoned connection can be removed.	`300`

The db.pool.max property is the most important. By default, each Alfresco instance is configured to use up to a maximum of 40. All operations in Alfresco require a database connection, which places a hard upper limit on the amount of concurrent requests a single Alfresco instance can service (that is, 40), from all protocols, by default.

Most Java application servers have higher default settings for concurrent access (Tomcat allows up to 200 concurrent HTTP requests by default). Coupled with other threads in Alfresco (non-HTTP protocol threads, background jobs, and so on) this can quickly result in excessive contention for database connections within Alfresco, manifesting as poor performance for users.

If you are using Alfresco in anything other than a single-user evaluation mode, increase the maximum size of the database connection pool to at least the following setting.

[number of application server worker threads] + 75.

For a Tomcat default HTTP worker thread configuration, and with all other Alfresco thread pools left at the defaults, this means this property should be set to at least 275.

To increase the database connection pool, add the db.pool.max property to the alfresco.global.properties file and set it to the recommended value of 275, for example:

db.pool.max=275

For clarity, add this property immediately after the other database properties.

Important: After increasing the size of the Alfresco database connection pools, you must also increase the number of concurrent connections your database can handle to at least the size of the cumulative Alfresco connection pools. In a cluster, each node has its own independent database connection pool. You must configure sufficient database connections for all of the Alfresco cluster nodes to be able to connect simultaneously. Alfresco recommends that you configure at least 10 more connections to the database than are configured cumulatively across all of the Alfresco connection pools to ensure that you can still connect to the database even if Alfresco saturates its own connection pools. Remember to factor in cluster nodes (which can each use up to 275 database connections) as well as connections required by other applications that are using the same database server as Alfresco.

The precise mechanism for reconfiguring your database's connection limit depends on the relational database product you are using; contact your DBA for configuration details.

Modifying the global properties file

This section describes the steps for modifying the alfresco-global.properties file.

Important: For edits to the alfresco-global.properties file, when specifying paths for Windows systems, you must replace the Windows path separator characters with either the \\ separator or the forward slash / Unix path separator. Also, when using folder names like User Homes, you must manually escape the space. For example, change the value to User_x0020_Homes.

Browse to the <classpathRoot> directory.
For example, for Tomcat, browse to the $TOMCAT_HOME/shared/classes/ directory.
Open the alfresco-global.properties.sample file.
This file contains sample configuration settings for Alfresco. To enable or modify a setting, ensure that you remove the comment (#) character.
Ensure that the dir.root= property points to a root location for the storage of content binaries and index files.
For example, dir.root=/var/data/alfresco/alf_data.

Note: It is strongly recommended that you always set this value to an absolute file system path as shown above. This ensures that no matter how the Alfresco instance is started, it will always find the directories where content has previously been written.

Set the database connection properties.

Property	Description
`db.username=alfresco`	Specifies the name of the main Alfresco database user. This name is used to authenticate with the database.
`db.password=alfresco`	Specifies the password for the Alfresco database user. This password is used to authenticate with the database.

Additional database properties may be set for further configuration. Refer to the Configuring databases [16] for more information.

Specify the locations of the following external software:

Property	Description
`ooo.exe=`	Specifies the location of the LibreOffice installation.
`ooo.enabled=`	Specifies whether to use the Direct LibreOffice subsystem.
`jodconverter.officeHome=`	Specifies the location of the LibreOffice installation for JODConverter transformations. To use the JODConverter, uncomment the `ooo.enabled=false` and `jodconverter.enabled=true` properties.
`jodconverter.portNumbers=`	Specifies the port numbers used by each JODConverter processing thread. The number of process will match the number of ports.
`jodconverter.enabled=`	Specifies whether to use the JODConverter. Set the property to `jodconverter.enabled=true`.
`img.root=`	Specifies the location of the ImageMagick installation.
`swf.exe=`	Specifies the location of the SWF tools installation.

Configure your supported database for use with Alfresco. See Configuring databases [16].
Select a JDBC driver used with each connection type.
Add your global custom configurations.
Save your file without the .sample extension.

You need to restart the Alfresco server for the configuration changes to take effect.

What to do next:

Go to Parent topic: Modifying Alfresco applications [17]

Next: Solr configuration files [18]

Day Zero configuration

Disabling Alfresco features

Default port numbers and services

Repository system configuration files

Tuning the JVM

Hardware

Disk space usage

Virtualization

JVM memory and CPU hardware for multiple users

Calculate the memory needed for Solr nodes

Memory calculation for the Alfresco data structures associated with one searcher

Memory calculation for the Solr caches associated with one searcher

Solr memory planning

Overall Solr memory use

Minimize the memory requirements for Solr nodes

Advanced database configuration properties

Modifying the global properties file