Ignite Cache Write Behind Test

In a simple write-through mode, each put and remove operation involves a corresponding request to the persistent store; therefore, the overall duration of the update operation might be relatively long. Additionally, an intensive cache update rate can cause an extremely high storage load. For such cases, you can enable the write-behind mode, in which update operations are performed asynchronously. The key concept of this approach is to accumulate updates and asynchronously flush them to the underlying database as a bulk operation.

Write Behind is s key capability as it ensures that write operations are lightening fast, at the same time it is absolutely required to know that write behind is working properly because any glitch in it's operation can cause loss of data. That's the reason it is important to always monitor this process so that if there is an issue in it's operation, it can be fixed before the cache is flushed.

This test monitors the write behind operations and gather key metrics like frequency, overflow, errors etc. which can provide valuable insights into the process efficiency and health.

Target of the test : Apache Ignite Server

Agent deploying the test : An internal or external agent

Outputs of the test : One set of results for each Apache Ignite Server

Configurable parameters for the test

Parameter	Description
Test period	How often should the test be executed.
Host	Enter the IP address of the Apache Ignite cluster.
Port	Enter the port number on which JMX connector listens to incoming connections requests.
JMX Remote Port	In this text box, enter the name of a virtual warehouse that needs to be monitored. The JMX connector listens on 8686 by default. If it listens on different port in your environment then specify the same.
JMX User	Specify the credentials of the user who is authorized to use JMX.
JMX Password	Specify the password for the authorized user.
Confirm Password	Confirm the password by retyping it here.

Measurements made by the test

Measurement	Description	Measurement Unit	Interpretation
Cache entries waiting to be flushed	Indicates the total count of cache entries which are not yet saved down to disk database.	Number	If the number is too high the write behind operation can get kicked off too frequently which can cause high load on node processor.
Write behind critical overflow count	Indicates the total number of cache overflow events recorded since the write-behind cache has been turned on.	Number	If there are too many cache overflow events, means the cache size is less than needed for application performance.
Write behind error retry count	Indicates the total number of cache entries which are currently in retry mode.	Number	If there are too many errors resulting in retries it could be a problem with database which needs to be investigated.
Write behind flush frequency	Indicates the time period after which write behind operations is invoked.	Seconds	Frequency and batch size should be set to an optimal value, it should not too high that too much data is being accumulated and no too low that there is no value.
Maximum size of the write-behind cache	Indicates the size of internal buffer that triggers write behind operation even before it is due.	MB
Number of threads perform cache flushing	Indicates the number of threads employed in write behind operation.	Number	There should be optimal number of threads performing the operation, in case the operation is taking more time than required, you might have to think about adding more threads.
Write behind store batch size	Indicates the maximum size of batch for write behind operation.	MB	Batch size should be set to an optimal value
Write behind total critical overflow count	Indicates the total number of cache overflow events recorded since the write-behind cache has been turned on.	Number	If there are too many cache overflow events, means the cache size is less than needed for application performance.