Enduro/X Master/​doc/​benchmark.adoc	Source navigation Diff markup Identifier search General search
	Latest: Master Revert   Change

 Enduro/X benchmarks
 ===================
 :doctype: book
 
 Overview
 --------
 This document generally contains Enduro/X benchmark overview, performed on different platforms.
 Different aspects are being tested and performance results are analyzed. Testing will cover
 fundamental message exchange between client and server, synchronous and asynchronous aspects are tested.
 Document also covers persistent storage benchmarks.
 
 == Preparation
 
 This section gives some notes how to prepare for benchmark. What packages are required to
 be installed. This assumes that standard Enduro/X build installation is performed.
 
 === Preparing on Ubuntu/Debian like system
 
 ---------------------------------------------------------------------
 
 $ sudo apt-get install r-base
 
 ---------------------------------------------------------------------
 
 Asynchronous tpacall()
 ---------------------
 This tests uses one way calls to the server process. At the end of the calls it is ensured that
 all messages are processed by server. Only then results are plotted.
 
 image:benchmark/04_tpacall.png[caption="Figure 1: ", title="tpacall() benchmark", alt="tpacallbench"]
 
 
 Local tpcall()
 --------------
 This test includes locally running ATMI client and ATMI server. The interprocess comunication happens
 with help of kernel queues (kq) or shared memory (shm). The polling mechanisms are either epoll() (works
  on linux, most efficient way) and usual poll() for which event chain is bit longer.
 
 image:benchmark/01_tpcall.png[caption="Figure 2: ", title="tpcall() benchmark", alt="tpcallbench"]
 
 From the results can be seen that performance mostly stays stable at different data size loads.
 
 Networked tpcall()
 ------------------
 At this test basically same works is done as for above, but instead two instances of application servers
 are started and they are interconnected with network.
 
 image:benchmark/02_tpcall_network.png[caption="Figure 3: ", title="tpcall() network benchmark", alt="tpcall_network"]
 
 Here we see that network performance slightly fluctuate. That could be related with fact now bridge is involved to transfer
 the message over the network, and process count is bigger than CPU core count. Thus scheduler comes in work.
 
 Multi-process/multi-thread tpcall()
 -----------------------------------
 This test cases employs five ATMI servers, and one ATMI client which inside have 5x threads,
 sending massages to the servers
 
 image:benchmark/03_tpcall_threads.png[caption="Figure 4: ", title="tpcall() multiproc", alt="multiprocessing"]
 
 Persisted storage benchmark, tpenqueue()
 ----------------------------------------
 This test gets much lower results, because all messages are being saved to disk. 
 Also note that internally Enduro/X uses distributed transaction manager to 
 coordinate the save of the message, thus processing of XA transaction takes 
 some disk resources too. This benchmark uses default Enduro/X setting for data
 flushing to disk which is fflush() Unix system call. Fflush() does not guarantee data
 consistence at power outage event. For fully guaranteed data consistence, 
 flags (FSYNC/FDATASYNC/DSYNC) can be set for XA resource. However expect much 
 lower TPS performance.
 
 image:benchmark/05_persistent_storage.png[caption="Figure 5: ", title="Persistent storage", alt="persistent_storage"]
 
 
 Single-threaded tpcall() on cached service
 ------------------------------------------
 This tests performs benchmark over the service for which results are cached. For
 best results cache database is stored on RAM driver (on Linux system).
 
 image:benchmark/06_tpcache.png[caption="Figure 6: ", title="Cache performance", alt="review on cache performance"]
 
 
 Running the benchmarks
 ----------------------
 It is possible to run benchmarks on your own system. Note that for chart plotting R language is used. If R will not
 be installed, then charts will not be generated. But results still can be read from data files. Benchmark script is
 located in 'doc/benchmark' folder, named 'build.sh <configuration name>'. The configuration name is arbitrary description
 of your system on which you perform the tests. Shall not contain spaces. Results are plotted into text files located
 in same directory.
 
 NOTE: That you must enable the Q message size up till 56000 bytes. On Linux system that would mean that '/etc/rc.local' needs to be set to:
 
 ---------------------------------------------------------------------
 ...
 echo 56000 > /proc/sys/fs/mqueue/msgsize_max
 ...
 ---------------------------------------------------------------------
 
 And in 'setndrx' we shall also enable that message size:
 
 ---------------------------------------------------------------------
 ...
 # Max message size (in bytes)
 export NDRX_MSGSIZEMAX=56000
 ...
 ---------------------------------------------------------------------
 
 For our sample user (user1), then running could look like:
 
 ---------------------------------------------------------------------
 $ cd /home/user1/endurox/doc/benchmark
 $ ./build.sh my_system,linux,ssd
 $ ls -1
 01_tpcall.png
 01_tpcall.txt
 02_tpcall_dom.txt
 02_tpcall_network.png
 03_tpcall_threads.png
 03_tpcall_threads.txt
 04_tpacall.png
 04_tpacall.txt
 05_persistent_storage.png
 05_persistent_storage.txt
 build.sh
 genchart.r
 ---------------------------------------------------------------------
 
 
 ////////////////////////////////////////////////////////////////
 The index is normally left completely empty, it's contents being
 generated automatically by the DocBook toolchain.
 ////////////////////////////////////////////////////////////////

This page was automatically generated by the 2.1.0 LXR engine. The LXR team