Showing results for 
Show  only  | Search instead for 
Did you mean: 

What is mean by Transactions/s in server health



What is mean by Transactions/s in server health Dashboard.

we have run the test in 2 phases. when the first phase runs we have 250 Transactions/s in DT.

In 2nd phase we doubled the load and the transactions/s reach to 14000.

Requests as per Webservers

1st phase : 200 request/sec

2nd phase: 400 request/sec

uploaded the screenshots for your referanse


Hi Mayana,

a "transaction" in this context is a purepath. The metric "Transactions/s" measures how many purepaths the appmon backend server handles each second.

The 14k must be some burst maximum. The appmon server can't sustain 14k paths per second for any longer time. I think that your server is undersized for 400 req/s. Your "PurePath Status" dashlet shows that almost all the paths are getting skipped during the second phase. The screenshots also show a lot of GC time in the second phase. My guess is that the server is undersized for the task of handling 400 of these requests per second.

Could you try this again with a larger sizing? Thanks,

best regards,


Hi Peter,

We have large environment. It can handle 3500T/s.
In first phase we have X(200) req/sec in web server, In DT 250 T/s
In second phase we double the load 2X (400) req/s in webserver, In DT it should be 500 T/s.
But we have 14K+ transaction.

ok. Have you investigated the actual purepaths? Is there maybe some unexpected additional paths that get generated in the 400x scenario? Do you get one path per web request or a multiple?

The 14k could also be an accumulated value. When the appmon server goes into a longer GC, it doesn't book values for quite some time, maybe that's where the 14k burst comes from (i.e. not an actual burst of purepaths but a slightly erroneous accumulated value due to GCs).

Hi peter,

We have only one pura path is associated with web request.

hmm, ok, I don't think we can solve this here in the forum. Please open a support ticket and attach a session, a support archive and a link to this discussion. Thanks, Peter.