I measured the performance of the in-memory data grid Apache Ignite using Yardstick.

Introduction

A benchmark called "Yardstick Apache Ignite (yardstick-ignite)" is provided for measuring the performance of Ignite. This benchmark is written on top of the Yardstick Framework. Yardstick is a framework for writing benchmarks and is used to create benchmarks for clustered systems and other distributed systems.

Let's measure the performance of Ignite using Yardstick.

I refer to the following.

https://apacheignite.readme.io/docs/perfomance-benchmarking

environment

The following 3 servers were built on VirtualBox. Each server is CentOS 7, with 1 core and 3 GB of memory.

igniteserver1: Server for Ignite cluster (192.168.10.71) igniteserver2: Ignite cluster server (192.168.10.72) igniteserver3: Server for Yardstick (192.168.10.73)

Ignite is already installed in each environment. Since Yardstick uses the one included in Ignite, there is no environment construction.

Please refer to the following article for how to install Apache Ignite.

Getting Started with In-Memory Data Grid Apache Ignite (Java)

Benchmarks available

There are 24 benchmarks provided as standard for Ignite. This time, I will try 2 to 5 benchmarks.

There are 2 types of Atomic and transaction x 2 types of put / put + get = 4 types to be executed.

  1. GetBenchmark - benchmarks atomic distributed cache get operation.
  2. PutBenchmark - benchmarks atomic distributed cache put operation.
  3. PutGetBenchmark - benchmarks atomic distributed cache put and get operations together.
  4. PutTxBenchmark - benchmarks transactional distributed cache put operation.
  5. PutGetTxBenchmark - benchmarks transactional distributed cache put and get operations together.
  6. SqlQueryBenchmark - benchmarks distributed SQL query over cached data.
  7. SqlQueryJoinBenchmark - benchmarks distributed SQL query with a Join over cached data.
  8. SqlQueryPutBenchmark - benchmarks distributed SQL query with simultaneous cache updates.
  9. AffinityCallBenchmark - benchmarks affinity call operation.
  10. ApplyBenchmark - benchmarks apply operation.
  11. BroadcastBenchmark - benchmarks broadcast operations.
  12. ExecuteBenchmark - benchmarks execute operations.
  13. RunBenchmark - benchmarks running task operations.
  14. PutGetOffHeapBenchmark - benchmarks atomic distributed cache put and get operations together off-heap.
  15. PutGetOffHeapValuesBenchmark - benchmarks atomic distributed cache put value operations off-heap.
  16. PutOffHeapBenchmark - benchmarks atomic distributed cache put operations off-heap.
  17. PutOffHeapValuesBenchmark - benchmarks atomic distributed cache get value operations off-heap.
  18. PutTxOffHeapBenchmark - benchmarks transactional distributed cache put operation off-heap.
  19. PutTxOffHeapValuesBenchmark - benchmarks transactional distributed cache put value operation off-heap.
  20. SqlQueryOffHeapBenchmark -benchmarks distributed SQL query over cached data off-heap.
  21. SqlQueryJoinOffHeapBenchmark - benchmarks distributed SQL query with a Join over cached data off-heap.
  22. SqlQueryPutOffHeapBenchmark - benchmarks distributed SQL query with simultaneous cache updates off-heap.
  23. PutAllBenchmark - benchmarks atomic distributed cache batch put operation.
  24. PutAllTxBenchmark - benchmarks transactional distributed cache batch put operation.

Yardstick settings

If you installed Ignite in "/ opt / apache-ignite", the Yardstick is in "/ opt / apache-ignite / benchmarks".

The Ignite cluster is automatically started from Yardstick and does not need to be started.

Change the setting in "ignite-remote-config.xml" to connect to the Ignite cluster remotely and run the benchmark.

cd /opt/apache-ignite/benchmarks/config
vi ignite-remote-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
    Ignite Spring configuration file to startup grid.
-->
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
    <import resource="ignite-base-config.xml"/>

    <bean id="grid.cfg" class="org.apache.ignite.configuration.IgniteConfiguration" parent="base-ignite.cfg">

        <property name="discoverySpi">
            <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
                <property name="ipFinder">
                    <bean
                        class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
                        <property name="addresses">
                            <list>
                                <!-- In distributed environment, replace with actual hosts IP addresses. -->
                                <value>192.168.10.71:47500</value>
                                <value>192.168.10.72:47500</value>
                            </list>
                        </property>
                    </bean>
                </property>
            </bean>
        </property>
    </bean>
</beans>

Then change the benchmark settings. There is a sample file called "benchmark-remote-sample.properties", so copy it to create a configuration file.

cp -p benchmark-remote-sample.properties benchmark-remote-test.properties
vi benchmark-remote-test.properties

Enter the IP address of the Ignite node in the SERVER_HOSTS field of the properties file.

SERVER_HOSTS=192.168.10.71,192.168.10.72

Add a benchmark to run. Create by referring to "benchmark.properties".

# Run configuration.
# Note that each benchmark is set to run for 300 seconds (5 min) with warm-up set to 60 seconds (1 minute).
CONFIGS="\
-cfg ${SCRIPT_DIR}/../config/ignite-remote-config.xml -nn ${nodesNum} -b ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -dn IgnitePutBenchmark -sn IgniteNode -ds ${ver}atomic-put-${b}-backup,\
-cfg ${SCRIPT_DIR}/../config/ignite-remote-config.xml -nn ${nodesNum} -b ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -dn IgnitePutGetBenchmark -sn IgniteNode -ds ${ver}atomic-put-get-${b}-backup,\
-cfg ${SCRIPT_DIR}/../config/ignite-remote-config.xml -nn ${nodesNum} -b ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -dn IgnitePutTxBenchmark -sn IgniteNode -ds ${ver}tx-put-${b}-backup,\
-cfg ${SCRIPT_DIR}/../config/ignite-remote-config.xml -nn ${nodesNum} -b ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -dn IgniteGetAndPutTxBenchmark -sn IgniteNode -ds ${ver}tx-getAndPut-${b}-backup,\
"

Allows you to SSH into each Ignore node from the server that runs Yardstick (it seems to be called a Driver).

# ssh-keygen -t rsa
(Do not enter passphrase)

# ssh-copy-id [email protected]
# ssh-copy-id [email protected]

# ssh [email protected]
# ssh [email protected]

Start the benchmark with "benchmark-run-all.sh".

[root@igniteserver3 config]#  ../bin/benchmark-run-all.sh ./benchmark-remote-test.properties
<02:20:00><yardstick> Creating output directory
../bin/benchmark-run-all.sh: line 73: ifconfig: command not found
<02:20:00><yardstick> Copying yardstick to the host 192.168.10.71
Warning: Permanently added '192.168.10.71' (ECDSA) to the list of known hosts.

When I run the benchmark, I get angry without ifconfig as above, so install net-tools.

# yum install -y net-tools

If you kill it with Ctrl-C, the Ignore node stays up. If you re-run the benchmark in that state, the remaining Ignore nodes will also join the cluster, so if you force termination, you need to stop the Ignore nodes individually.

Looking at Visor, it seems that three servers are running. I thought one would be the Client, but it doesn't seem to be the case.

visor> top
Hosts: 3
+============================================================================================================================+
| Int./Ext. IPs |   Node ID8(@)    | Node Type |                  OS                   | CPUs |       MACs        | CPU Load |
+============================================================================================================================+
| 10.0.2.15     | 1: 0908F8F4(@n0) | Server    | Linux amd64 3.10.0-693.2.2.el7.x86_64 | 1    | 02:42:4A:05:5B:CD | 55.00 %  |
| 127.0.0.1     |                  |           |                                       |      | 08:00:27:76:F3:CF |          |
| 172.17.0.1    |                  |           |                                       |      | 08:00:27:E3:4A:44 |          |
| 192.168.10.71 |                  |           |                                       |      |                   |          |
+---------------+------------------+-----------+---------------------------------------+------+-------------------+----------+
| 10.0.2.15     | 1: 02A9366F(@n1) | Server    | Linux amd64 3.10.0-693.2.2.el7.x86_64 | 1    | 08:00:27:76:F3:CF | 51.33 %  |
| 127.0.0.1     |                  |           |                                       |      | 08:00:27:7F:64:16 |          |
| 192.168.10.72 |                  |           |                                       |      |                   |          |
+---------------+------------------+-----------+---------------------------------------+------+-------------------+----------+
| 10.0.2.15     | 1: 97EFB660(@n2) | Server    | Linux amd64 3.10.0-693.2.2.el7.x86_64 | 1    | 08:00:27:64:78:7A | 90.33 %  |
| 127.0.0.1     |                  |           |                                       |      | 08:00:27:76:F3:CF |          |
| 192.168.10.73 |                  |           |                                       |      |                   |          |
+----------------------------------------------------------------------------------------------------------------------------+

Summary:
+--------------------------------------+
| Active         | true                |
| Total hosts    | 3                   |
| Total nodes    | 3                   |
| Total CPUs     | 3                   |
| Avg. CPU load  | 65.56 %             |
| Avg. free heap | 83.00 %             |
| Avg. Up time   | 00:03:58            |
| Snapshot time  | 2018-08-25 02:48:02 |
+--------------------------------------+

Looking at "cache -a", the cache is stored on all three servers as shown below. This means that the Driver server is also in the Ignore cluster and seems to be the target of performance measurement.

Cache 'atomic(@c0)':
+-----------------------------------------------------------+
| Name(@)                     | atomic(@c0)                 |
| Nodes                       | 3                           |
| Total size Min/Avg/Max      | 305670 / 333334.33 / 350590 |
|   Heap size Min/Avg/Max     | 0 / 1.00 / 3                |
|   Off-heap size Min/Avg/Max | 305670 / 333333.33 / 350587 |
+-----------------------------------------------------------+

Nodes for: atomic(@c0)
+============================================================================================================+
|     Node ID8(@), IP      | CPUs | Heap Used | CPU Load |   Up Time    |         Size         | Hi/Mi/Rd/Wr |
+============================================================================================================+
| 02A9366F(@n1), 10.0.2.15 | 1    | 29.76 %   | 40.33 %  | 00:06:43.146 | Total: 305670        | Hi: 0       |
|                          |      |           |          |              |   Heap: 0            | Mi: 0       |
|                          |      |           |          |              |   Off-Heap: 305670   | Rd: 0       |
|                          |      |           |          |              |   Off-Heap Memory: 0 | Wr: 0       |
+--------------------------+------+-----------+----------+--------------+----------------------+-------------+
| 0908F8F4(@n0), 10.0.2.15 | 1    | 24.59 %   | 45.00 %  | 00:06:43.395 | Total: 343743        | Hi: 0       |
|                          |      |           |          |              |   Heap: 0            | Mi: 0       |
|                          |      |           |          |              |   Off-Heap: 343743   | Rd: 0       |
|                          |      |           |          |              |   Off-Heap Memory: 0 | Wr: 0       |
+--------------------------+------+-----------+----------+--------------+----------------------+-------------+
| 927AB38D(@n2), 10.0.2.15 | 1    | 20.24 %   | 88.00 %  | 00:00:34.269 | Total: 350590        | Hi: 0       |
|                          |      |           |          |              |   Heap: 3            | Mi: 0       |
|                          |      |           |          |              |   Off-Heap: 350587   | Rd: 0       |
|                          |      |           |          |              |   Off-Heap Memory: 0 | Wr: 0       |
+------------------------------------------------------------------------------------------------------------+


When the benchmark execution is completed, the result will be automatically output as a graph.

<03:08:51><yardstick> Driver is stopped on localhost
<03:08:51><yardstick> Server is stopped on 192.168.10.71
<03:08:51><yardstick> Server is stopped on 192.168.10.72
<03:08:52><yardstick> Collecting results from the host 192.168.10.71
<03:08:53><yardstick> Collecting results from the host 192.168.10.72
<03:08:54><yardstick> Creating charts
Moving chart directory to the /opt/apache-ignite/benchmarks/output/results-20180825-024401 directory.

It is output as an HTML file and is displayed as shown below.

image.png image.png image.png

With Put, the average is 38,000 operations (blue), but when transactions are enabled, it drops to about 11,000 (red) on average. Since the benchmark is included from the beginning, it was easy to measure the performance. This time I ran it with the default parameters, but in the future I would like to make various changes and check the changes in performance.

YCSB (Yahoo Cloud Serving Benchmark)

YCSB (Yahoo Cloud Serving Benchmark) also seems to support Ignite.

The results of the benchmark using YCSB are posted below. Apache® Ignite™ and Apache® Cassandra™ Benchmarks: The Power of In-Memory Computing https://www.gridgain.com/resources/blog/apacher-ignitetm-and-apacher-cassandratm-benchmarks-power-in-memory-computing

Recommended Posts

I measured the performance of the in-memory data grid Apache Ignite using Yardstick.
Access the in-memory data grid Apache Ignite from a Java client
I tried using the profiler of IntelliJ IDEA
I tried using the Server Push function of Servlet 4.0
Rails6: Input the initial data of ActionText using seed
[Enum] Let's improve the readability of data by using rails enum
[Apache Tomcat] The story of using Apache OpenWebBeans to enable CDI
Data processing using Apache Flink
I tried using Apache Wicket
I tried using the cache function of Application Container Cloud Service
Try using the two-point measurement function of Firebase Performance Monitoring. [Android]