Load Test enabling and performance testing at 1TPS and 100TPS
Posted on 20th Jul 2018 9544 views
Hello and welcome to this demo of the neaPay simulator. The scope is to start with the simulator in functional mode and then switch to performance testing. In the end we will test at 100 TPS, screenshot above. Below is a screenshot of the simulator file structure and the system use resources.
Follow this video on how to get started.
What we are doing in the video is the standard sequence to switch from functional to load mode and back.
For the purpose of this demo, we will remove the auto-generated cache file.
In the Acquirer, we set the transactions-per-second rate to 1 TPS.
We disable issuer stress enablement so the Issuer simulator runs in functional mode, so it shows all messages it is processing.
We disable acquirer stress mode so it also shows all functional details of testing.
We disable tracing because it affects performance, given that it has to render heavily, a lot of information on a java user interface.
We run the test in functional mode and we notice there is no stress cache file generated. This is because the cache is only generated and used in Load Mode.
Then we enable acquirer stress mode. This enables the creation of cached transactions when running functional tests.
When running tests, responses no longer displayed, because in stress mode the Acquirer no longer displays the responses it is processing.
We can see the stress file gets created and it is accumulating transactions. The more tests we run, the more transactions the cache is accumulating. This will be used for achieving the diversification and granulation we need.
Then we just run in load mode at 1 TPS so we can see it is functionally running correct. We can see that the card numbers are automatically and dynamically changed for each transaction.
We can check sleep time per second (time unused per second), roughly our simulator sleeps 0.999 of a second when running at 1 TPS
We have learned how to enable Load /Stress test in neaPay simulator and how fast it is at 100 TPS, with Acquirer and Issuer processing, and screen recording. The image below shows the simulator sleep times, it needs about 0.03% of a second to send the required TPS rate, 100.
The test was done on a very basic travel laptop, my own, a Toshiba Portege Z930, which has an i5 average CPU with only 4GB or RAM, no dedicated video card. We ca easily see the CPU is not really used, as it just sits at 3% and there is literally no difference in RAM usage when running it. A small increase in RAM happens when the cache is loaded, but that is directly dependent to the size of the cache file, we can estimate a consumption of about 1kB per transaction, which means you will use about 1MB per a cache of 1000 transactions. The simulator itself loads about 3 MB.
The neaPay ISO8583 simulator improves automated testing with full capabilities for scheduling minutely message exchanges, duration tests, nightly or w ...
Deploy then neaPay Payments switch router to easily route transactions based on BIN/prefix, amount, merchant, originating or destination insytitution, ...
When you need to customize your own test case, you need to follow some simple steps all the time.In order to obtain this, you need to alter test data ...
The neaPay Payments simulator is designed from the start to follow the life of a project, and therefore, after all testing has been completed, we need ...
Step by step guide to enable and disable fingerprint reading, enrollment and verification with the neapay Simulator is pretty straight forward and ass ...
Enabling traces in the ISO8583 Payments Simulator, just like the ISO8583 message converter and the ISO8583 Host, is a call to the system core to write ...