pub.soap.utils:getBody - Taking over one tenth of a second

,
1

Using the web service connector I have added debug statements that indicate the start of each of the built in steps within the Web Service connector generated service. You can see that GetSOAPBody step is taking over a tenth of a second. I have attached the small 6k response it is processing. We are looking to improve the performance of some our high volume requests like address verification as a whole. Since applications originally used local installed instances of these type applications and API based integration they are now seeing a setback in performance with SOA. To give you context this request orginated from CICS > Data Direct Shadow WSC > webMethods IS > Group One CDQ Web Service interface and back in .25 seconds total. Over a third of the elapse time occurred in the GetSOAPBody. Every little bit helps.

Anyone have a suggestion?

[76735]2009-01-21 15:56:39 CST [ISP.0090.0003C] 03:56:39:912-GroupOneCallEndSOAPResponseMapped
[76734]2009-01-21 15:56:39 CST [ISP.0090.0003C] 03:56:39:912-GroupOneCallStartSOAPResponseXMLNodeToDocument
[76733]2009-01-21 15:56:39 CST [ISP.0090.0003C] 03:56:39:803-GroupOneCallStartSOAPResponseGetSOAPBody
[76732]2009-01-21 15:56:39 CST [ISP.0090.0003C] 03:56:39:803-GroupOneCallEnd

2

Not sure how you are using the debug capture but be careful with the Flow debug statement especially if IS is logging output to console as this can introduce some serialisation of output which does slow things down (doesn’t look as though you are given the lines in the server log but worth confirming). If possible, capture the times directly and report at the end, may be more reliable.

You can also change your log date/time format using hh:mm:ss:SSS where the ‘SSS’ will give you milliseconds, at least to the level that your JVM will report it (some JVMs used to have a granularity of 16ms). I do this and drop the ‘Z’ for time zone from the default setting which is normally useless overhead.

Not sure which version you are using but a patch released early last year for v7.1 allowed the IS to make better use of multi-core processors which might help in XML parsing (it’s in v7.1.2 as standard, not sure if it was back-ported to v6.5 at all). Not sure if it helps your latency issue though.

Most of that is just about measuring I know, but it might help confirm where time is spent. I haven’t looked at tuning the SOAP parsing myself.