Stressing out TransactionManager

[A Haris Kurniawan]

Hi All,

i'm currently playing with the transaction manager,
pushing it to the limit if i may say,

my last test was hitting the transaction manager using plain java client,
looping infinitely..

the server cpu hit was only around 30-40%...
i leave the test running all night and in the morning i see the OutstandingTransactions around 19.000

in my understanding, the Outstanding Transaction is like the waiting list, right?

so i dig up the source code for transaction manager
then discover sessions and max-sessions,
previously i only set the max-sessions,
then i discover that set the sessions was forcing the transaction manager to spawn initial thread according to the session value,
instead of only set the max-session to 100, it's also a good thing to set the session let say 30,
that way 30 participant can initally work on the transaction. so it will speed up things

ok so i wonder what if i push the session number to... 2000 or even 5000, will that mean there's going to be 5000 participant working immediately?

on the source code stated:
public static final long    MAX_PARTICIPANTS = 1000;

MAX_PARTICIPANTS is being called in the prepare method, but i dont understand what it means

so i tried to set the session to 1000, which failed because of number of threads limit on the OS,
i tweak the OS (linux) using ulimit -u 4000, and i'm able to set session to 1000
the JVM thread limit itself at around 32000

anyway my hardware(4core i7 laptop) cant really push the transaction manager to use 2000 session
but
the question remains, is it safe to set the session value at a high number, i mean 2000 to 5000.

[Mark Salter]

On 08/03/17 05:52, A Haris Kurniawan wrote:

> i'm currently playing with the transaction manager,
> pushing it to the limit if i may say,

What are you trying to achieve?

Have you searched this mailing list for previous discussions?

Have you read articles like :-

http://www.andyorrock.com/2007/02/the_three_most_.html
or
http://www.andyorrock.com/2010/05/introducing-the-transactionmanager-monitor.html

There was also another sensible one from Alejandro (that I can't
currently find) describing the pitfalls and perhaps the problems of
aiming unrealistically high with performance targets whilst using the
wrong hardware and environment.

Currently you are only stressing you laptop - poor thing.

The good news is that jPOS will scale in line with your hardware
environment.
The throughput is limited by your platform - not the framework into
which you put your code :-)


The primary limit you will face is the rate of requests into your
system; do you really truly expect to have to deal with more than a few
hundred simultaneous transactions?

So, again, what is it you are trying to achieve?

--
Mark

[Victor Salaman]

Hi:

What are you trying to achieve? 

What is your expected target limit for the Transaction Manager?

.V

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+unsubscribe@googlegroups.com.
To post to this group, send email to jpos-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/e3e9c665-a795-409b-a614-7f1f4da7145e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[A Haris Kurniawan]

@mark:

i'm trying to achieve...
1. push down the number of OutstandingTransaction, i've read somewhere that Andy Orrock said that on a normal transaction the OutstandingTransaction should only be 2digits, since the cpu only got hit under 50% and 5digits OutstandingTransaction would definitely say that something is not right.

2. the number of session that's suitable for a given hardware, i'm trying to find a session number that will bump the cpu and memory to near 100%. so i can conclude "jpos can give you tps up to xxxx for complex transaction if you place it on a hardware such as these..."

i've search this mailing list and found couple of valuable resource, one of it is JVM setup from alejandro

i also understand profile and debug on the transaction manager, the head should be near with the tail and using profiler.checkpoint() to exacly figure how long each codes is running.

each participant only takes less than 400msec to complete it's job

so it's either the OS or the way i set up the q2 that is not optimal

@Victor,

that is exactly what i'm wondering, is there a limit on the transaction manager, other than constraints from OS, JVM, setup.

the question rises because at first i can't set the number of session to 1000, and then apparently i could after alter the max users processes on the OS , that is why i ask, is it safe to set the session number to a high value

anyway thanks for the reply guys

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CALK1SyxfL%2B%2Baw%2B8BWaYEnOkDLb4QGOPr3GXw--6%3Dh8H%3DVXnx7w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Best regards,
A. Haris Kurniawan

[Victor Salaman]

Hi:

I think you are going about this the wrong way. You configure your hardware around an estimated workload relative to your application. CPU usage is  a poor metric on how much stress your system is capable of handling. Your hardware, OS tuning and JVM tuning all play their part in performance, but in reality does it really matter? I'm going to let you in a little secret, in most REAL jPOS based applications, the system spends most of its time waiting for someone else (database, another host, tokenizers,  HSMs, vaults, etc). About scaling, with enough hardware I could scale unlimitedly - now why is the question!

Now answering your question, your test rig might be flawed, you might be testing incorrectly, or not generating enough work (you're using a single client). You want to kill the box, setup 10 machines with 50 threads each, hitting your poor notebook: mission accomplished. Now what does this prove? Absolutely nothing other than you killed your box :) Another hint: the largest acquirers/processors in the world, only reach numbers above 800 TPS during peak times (holidays). Most banks driving thousands of ATMs and POS machines never go past 25! So why suddenly everyone wants to ensure they can meet 10,000 TPS?   

You might want to post your test code on Github so the community might examine it and give you pointers.

/V

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAL8bJ0GgkWjogkX2THLqGYQ-wODy5MTk-XtO24%3DnVMXbwnpezA%40mail.gmail.com.

[Mark Salter]

On Wednesday, March 8, 2017 at 8:13:35 AM UTC, Victor Salaman wrote:

...with enough hardware I could scale unlimitedly - now why is the question!

 Do you know, I could see you as a Lobsang (Long Earth) a SykNet (Terminator ) or indeed the MCP (Tron).

:-)

I am also slightly worried that this might be a threat, not just an observation :-D

--
Mark

[Alejandro Revilla]

Haris, 

This book is worth reading: http://a.co/a6Tgldd (Java Performance by Charlie Hunt). It will explain in great detail how the number of threads you use in Java have to have some relation with your hardware.

The MAX_PARTICIPANTS=1000 thing is intended to detect infinite participant loops while using group selectors. We believe 1000 participants is enough for any reasonable transaction.

--

@apr

[Victor Salaman]

Haha Skynet!!!

Sent from my iPhone

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To post to this group, send email to jpos-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3DkZbyR2WOM5RQ3nWrYhX2RZ6Hp_jgE9rUju%2BMraATY6FQ%40mail.gmail.com.