What product/components do you use and which version/fix level are you on?
10.5
Is your question related to the free trial, or to a production (customer) instance?
What are you trying to achieve? Please describe it in detail.
Source is sending events at 60 TPS (Transactions per second)
Downstream has enabled spike arrest policy if transactions >50 TPS
To achieve this what should be JMS Message Processing values as we are using Concurrent processing mode assuming we have 6 IS instances in cluster .
Below are our current config
Max execution threads=2
Connection count=1
Do you get any error messages? Please provide a full error message screenshot and log file.
Have you installed all the latest fixes for the products and systems you are using?
Concurrent processing in messaging is used to achieve parallel processing as the name suggests. TPS will mainly depend on your end system response time, as you have 6 IS with 2 threads for each, at max you have 12 processing events (Please note not always 12, because it all depends on how quickly the message is getting processed by the system) and if they are really quick you might process more than 50 transactions.
So basically minimum JMS documents will be picked and processed are 12 and based on processing time from downstream it may increase to multiple of 12 and that count can’t be controlled in webMethods .
Thank you for your quick response .Is there any solution to control the TPS in webMethods ?
Only solution I found is throw exception for retry in case of spike arrest in down stream system but it has disadvantages too .
Product level throttling is only available resource levels like number of threads, connections etc… In my view, the source system is the driver of the requests, that would be the best place to control the TPS rate which they send for the downstream to process.
Our consumers has a facility to suspend the processing, but needs some work to know the processing rate and than suspend and resume processing. But not a good approach to control TPS.