This guide aims to help James operators refine their James configuration and set up to achieve better performance.

== Database setup

{backend-name}, OpenSearch, RabbitMQ is a large topic in itself that we do not intend to cover here. Yet, here are some
very basic recommendation that are always beneficial to keep in mind.

We recommend:

* Running {backend-name}, OpenSearch on commodity hardware with attached SSD. SAN disks are known to cause performance
issues for these technologies. HDD disks are to be banned for these performance related applications.
* We recommend getting an Object Storage SaaS offering that suites your needs. Most generalist S3 offers will suite
James needs.
* We do provide a guide on xref:[Database benchmarks] that can help identify and fix issues.

== James configuration

=== JMAP protocol

If you are not using JMAP, disabling it will avoid you the cost of populating related projections and thus is recommended.
Within `jmap.properties`:

....
enabled=false
....

We recommend turning on EmailQueryView as it enables resolution of mailbox listing against {backend-name}, thus unlocking massive
stability / performance gains. Within `jmap.properties`:

....
view.email.query.enabled=true
....

=== IMAP / SMTP

We recommend against resolving client connection DNS names. This behaviour can be disabled via a system property within
`jvm.properties`:

....
james.protocols.mdc.hostname=false
....

Concurrent IMAP request count is the critical setting. In `imapServer.xml`:

....
<concurrentRequests>200</concurrentRequests>
<maxQueueSize>4096</maxQueueSize>
....

Other recommendation includes avoiding unecessary work upon IMAP IDLE, not starting dedicated BOSS threads:

....
<ignoreIDLEUponProcessing>false</ignoreIDLEUponProcessing>
<bossWorkerCount>0</bossWorkerCount>
....

=== Other generic recommendations

* Remove unneeded listeners / mailets
* Reduce duplication of Matchers within mailetcontainer.xml
* Limit usage of "DEBUG" loglevel. INFO should be more than decent in most cases.
* While GC tunning is a science in itself, we had good results with G1GC and a low pause time:

....
-Xlog:gc*:file=/root/gc.log -XX:MaxGCPauseMillis=20 -XX:ParallelGCThreads=2
....

* We recommand tunning bach sizes: `batchsizes.properties`. This allows, limiting parallel S3 reads, while loading many
messages concurrently on {backend-name}, and improves IMAP massive operations support.

....
fetch.metadata=200
fetch.headers=30
fetch.body=30
fetch.full=30

copy=8192

move=8192
....