Chronicle-Map/docs/CM_FAQs.adoc

= Chronicle Map Frequently Asked Questions
Neil Clifford, Peter Lawrey, Rob Austin, Jerry Shea
:toc: manual
:toclevels: 1
:css-signature: demo
:toc-placement: preamble
:icons: font

This document provides information for some common tasks within Chronicle Map.

== Can I use Chronicle Map as a  replacement of `Redis`, with concurrency in mind?

=== Question

I am investigating Chronicle Map as a potential replacement of `Redis`; with concurrency in mind.

In our architecture, we would be looking to replace a "large" `Redis` instance that currently has multiple clients connecting to it, causing latency pileups due to ``Redis``'s blocking nature.

The issue is that we need to make requests in random batches of ~1000. With `Redis` we are able to make a single request via a `Lua` script (or multi-get / multi-set commands) and receive a single response. In the documentation on Chronicle Map`s stateless client, I see that the remote calls are blocking, and can be made only one key at a time; so for us the solution is not obvious.

While I am considering passing off each individual key task to a threadpool running `x` blocking threads at a time, I wonder if there might be a better solution, that could take advantage of doing RPC in batches, and perhaps work asynchronously. As I do not see this available currently, my question is whether this is an enhancement that you might consider, or if you could perhaps point me to if/how we could write our own solution for doing this?

Also, is there a reason these `1000` `gets` have be done serially in one thread? Why not submit `1000 get()` tasks to a pool of say `20` threads. Wouldn't this improve throughput and reduce latency?

=== Answer

The stateless client has been replaced with Chronicle Datagrid. The stateless client is not supported in ChronicleMap 3.x.  For  more information, please refer to Chronicle Datagrid FAQ's.

For `get()s`, parallelizing will reduce costs. For `put()s`, if you have concurrency requirements, that is, multi-key lock before updating all of them, it should be in one thread.

You would not gain a performance benefit by using batches, unless you are compressing the batch of data. All the data will have to be sent via TCP, even if it is in a batch.

NOTE: Under high load, the Chronicle Map stateless client consolidates many small TCP requests into a single request when run with a number of threads.

== Does Chronicle Map/Chronicle Queue work by using Memory Mapped Files?

=== Question
Does Chronicle Map work by using Memory Mapped Files?

=== Answer
Yes;  Chronicle Map uses memory mapped files see https://en.wikipedia.org/wiki/Memory-mapped_file. This works the same way on both Linux and Windows.

== Is there a difference in performance between Linux and Windows systems?

=== Question
Is there a difference in performance between Linux and Windows systems?

=== Answer
The same code is run on both Windows and Linux. However, we encourage all our clients to use Linux, as it has improved handling of memory mapped files over Windows. 

== Will Chronicle Map work in *Docker* environments?

=== Question
Will Chronicle Map work in *Docker* environments “out-of-the-box”. For example, two java programs running on dockers?

=== Answer
While Chronicle Map has not been tested with *Docker*, we are not aware of any reason why it would not if you use Chronicle Map for IPC (https://en.wikipedia.org/wiki/Inter-process_communication). In other words, if you  distribute data between two or more instances of the same map, then the same memory mapped file which holds your map data would have to be available to all the instances of Chronicle Map. We assume this would have to be in the same docker. Alternatively, you could replicate the data between your maps using Chronicle Map Enterprise.

== What are the performance benefits of Disk vs RAM?

=== Question

Should we specify faster RAM or a faster disk to Chronicle improve read/write performance.

=== Answer

Chronicle recommends lots of high-speed RAM. This is because Chronicle uses the page cache and RAM is in effect a cache to the disk. 

There are two cases where having a high-speed disk will give you a real benefit:

==== 1. Data rate
If the rate of data that you are writing exceeds the disk write speed. In most applications this is unlikely to occur.

==== 2. Page cache misses
When you get a page cache miss. For Chronicle queues which write and read messages lineally across memory, we mitigate this situation with the use of the Chronicle pre-toucher. The pre-toucher ensures that the page is loaded into the page cache before being written into the queue. 

For Chronicle Map, it is somewhat more complicated because Chronicle Map reads and writes your entries with random access across both the memory and disk. In this situation, if the entire map can be held within the page cache, then a read, or write, to the map will not have to access the disk. The operating system will work in the background ensuring that entries written to the page cache are propagated to the disk, but this is done via the operating system and is not on the critical path. 

It follows that if you have quite a few maps, especially large maps, and your page cache is not large enough to hold all of these maps, then a read, or write, to a random entry may cause a cache miss. This in turn would cause a disk read or write. If you were going to install high-speed SSDs, Chronicle recommends that you use them to store the Chronicle maps and leave the slower cheap disks for the Chronicle queues. In addition, you should avoid using network attached storage, as this usually offers significantly less performance than local disks.

=== Question

I am trying to compile in IntelliJ 2020.x and the compiler is blowing up with some strange annotation-processing
related errors.

=== Answer

link:https://www.jetbrains.com/help/idea/delegate-build-and-run-actions-to-maven.html#delegate_to_maven[Configure IntelliJ to use maven to build the project]

'''
<<../ReadMe.adoc#,Back to ReadMe>>