In our application we pull data from an external web service. This takes a little time (ie 20 to 30 seconds). During this time the working agent of course stays busy, but also at least accoring to top, it does use quite a lot of cpu.
The actual creating of request & reading of response is quick even though the answer sometimes is up to 500k of xml.
Are there any ways to tune web services?
What we do isn't very fancy:
/*
Took away code for connecting - we use a local copy of the wsdl file
*/
phPort:SET-CALLBACK-PROCEDURE( "REQUEST-HEADER", "setRequestSessionHeader" ).
phPort:SET-CALLBACK-PROCEDURE( "RESPONSE-HEADER", "" ).
/* Creates xml-query */
RUN createXml(OUTPUT glcRequest).
RUN webservice IN phPort
( INPUT glcRequest
, OUTPUT glcResponse ) .
/* Reads xml-response */
RUN walkXml(INPUT glcResponse).
/* Took away code for cleaning up handles & disconnecting */
If the call of webService is executed into a appServer session we can grow the
JRE memory usage. In the appServer configuration add the variable:
jvmArgs=-Xms128m
Ok, but if the call isnt inside an appServer but just locally in the webspeed session? Can I increase memory or other parameters then?
You could increase the memory availble to the WebSpeed agent (-mmax), but I don't think that'll help.
Can you tell us how you know that it's actually the Web Service call that's slow? (Did you perhaps run the profiler?) Is the Web Service call fast from other clients (eg. a web browser)?
It would seem to me that if the Web Service is actually what's taking the time, the client should not be using much CPU while waiting for the response. Are you sure that it's the same process?
Jens,
What OpenEdge version are you using?
Without more information this would sound like a bug, I'd suggest reporting the issue to Tech Support.
Regards
Salvador
10.1C
This may be a different one then. 10.1C included a fix for a similar issue. Go ahead with Tech Support. They'll help you.
Regards
Salvador