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? - Does Chronicle Map/Chronicle Queue work by using Memory Mapped Files?
- Is there a difference in performance between Linux and Windows systems?
- Will Chronicle Map work in Docker environments?
- What are the performance benefits of Disk vs RAM?
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?
The stateless client is not supported in ChronicleMap 3.x. For more information, please contact sales@chronicle.software.
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. |
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.
Will Chronicle Map work in Docker environments “out-of-the-box”. For example, two java programs running on dockers?
Yes, Chronicle Map works in Docker containers. If you wish to share maps between docker containers and/or the host, you should ensure that:
-
containers share IPC namespace (run with
--ipc="host") -
queues are mounted on bind-mounted folders from the host (i.e.
-v /host/dir/1/:/container/dir)
Alternatively, you could replicate the data between containers using Chronicle Map Enterprise.
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:
If the rate of data that you are writing exceeds the disk write speed. In most applications this is unlikely to occur.
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.
I am trying to compile in IntelliJ 2020.x and the compiler is blowing up with some strange annotation-processing related errors.