Option to view "Total Transactions Per Second" for Virtual Services

[Mohammed Javed Ali]

There is a requirement to know if there is an option to view total transactions per second at a given point of time in a day apart from Min, Avg and Max counts. This is something similar to "Total transactions per day" count.

[Koustubh Warty]

If you select the Range of time From midnight  To current time - that should give you what you need at any given time?

[Mohammed Javed Ali]

Thanks for the input Koustubh. I tried that option, but it still breaks down the period for which service was running and divided it into intervals and  shows Min, Avg and Max TPS for each dividing point.

Here the requirement is as follows:

Assume a VS service was running from 14:30:00 to 15:30:00 and processed certain requests during this time. Now I would like to know what was the total transaction per second count at exactly 15:03:00. Can I get this information?

Also would I like know how Min, Avg and Max TPS is calculated for a given point in time as depicted by the points in this graph. As I understand for Min, Avg and Max there was to a time interval under consideration. What is that time interval considered when we show this data on Portal graph.

 

[Surya Anil Kumar Suravarapu]

Hello Javed,

 

          You can make the report more granular by defining the intervals at which metrics are collected. By default, the metrics are collected every 5 mins. If you want the data to be collected at lets say every minute, you can change a property in lisa.properties to that interval. The more granular the data, the more data collection and DB writes for the data collected.

 

# This property controls how often transaction rate and response times are sampled.

lisa.vse.metrics.sample.interval=5m

 

Hope this helps.

Thanks,

Surya.

[Legacy User]

I would add the following to Surya's comment...  I am assuming that this is a performance environment since a functional environment's TPS rate is throttled.  Generally, to maximize performance, we suggest that you turn off or turn down as many things as possible.  Your requirement seems to be moving in the other direction by ratcheting up the facilities. 

 

I would try to determine the business value of knowing the TPS rates at an exact point in time versus the expense of the additional overhead. 

 

Shorter metric time boundaries and higher sample rates cause more overhead. For example, if you are running load and performance runs and your metrics are calculated every 1 minute opposed to 5, you are shifting CPU cycles from performance (i.e., processing requests and responses) to metrics collection and database I/O thus potentially affecting overall TPS throughput. I cannot say with certainty to what degree you might affect performance by shortening the metrics collection time.  You would need to explore the impact of your decision by monitoring the system after making changes.