You can start with this: https://pdn.pega.com/sites/pdn.pega.com/files/help_v719/procomhelpmain.htm#howto/howto2/monitorlengthyservices.htm

There is also SOAPService class debug log you can turn on to identify the timeline. If you issue is robust, this should give clues what is responsible.

Can you check on the overall network connectivity?

you may want to review below article as well:

https://pdn.pega.com/sites/pdn.pega.com/files/help_v719/procomhelpmain.htm#rule-/rule-parse-/rule-parse-xml/related.htm

Hi Hareen,

Do you know the rate of incoming SERVICE calls being made ? I mean : how many requests per minute ?

What are the settings for your Requestor Pool ? I'm not sure: whether the PEGA0011 include or exclude 'waiting time' here or not: but assuming for the moment that they do: perhaps your incoming requests are spending time waiting for a free Requestor to be made available in the Pool ?

You can use SMA to monitor the Requestor Pools: to see if this is a possiblity - you can also check your logs for any evidence of any explicit timeouts ('Timed Out Waiting for Requestor' I think the message is).

I would NOT just increase your Requestor Pool setting without first monitoring them - because you have to consider the trade-off between time waiting and resources (memory mostly) used.

Cheers

John

Did you changed the default threshold for alerts?

If so you can restore the original values or even decrease them just for the test period.

Then you may want use your preferred testing tool (SoapUI or whatever) to load test your service in order to compare performances observed from the outside with the ones collected from the inside.