WebService connect

Posted by Jens Dahlin on 26-Jan-2011 05:24

Hi,

I've tried to crack this problem via PSDN before without luck but I thought I would give it a last shot. I want to call a webservice, the problem is that performance is slow, the connect-statement alone takes several seconds.

The .wsdl and .xsd data is quite big (around 3.5Mb) but they are not in my control.

This is the code (I'm not calling any web service at all in this example, just connecting and disconnecting). Test data is below.

DEFINE VARIABLE ghWebService           AS HANDLE      NO-UNDO.
DEFINE VARIABLE ghAmadeusWebServicesPT AS HANDLE      NO-UNDO.
DEFINE VARIABLE gcWsdlFile             AS CHARACTER   NO-UNDO.
DEFINE VARIABLE deTime                 AS DECIMAL     NO-UNDO EXTENT 6.

/* These are both local locations */

&IF OPSYS="UNIX" &THEN
gcWsdlFile = "/export/home/wrk10/wsdl/amad-prod-5/1ASIWIBEAIT_PRD_28April10.wsdl".
&ELSE
gcWsdlFile = "c:\temp\amad-prod-5\1ASIWIBEAIT_PRD_28April10.wsdl".
&ENDIF

ETIME(YES).

CREATE SERVER ghWebService.
deTime[1] = ETIME.

ghWebService:CONNECT(" -WSDL '" + gcWsdlFile + "'").
deTime[2] = ETIME.

RUN AmadeusWebServicesPT SET ghAmadeusWebServicesPT ON ghWebService.
deTime[3] = ETIME.

/* Here I should run a webService but I wont for testing purposes! */

IF VALID-HANDLE(ghWebService) AND ghWebService:CONNECTED() THEN
ghWebService:DISCONNECT().
deTime[4] = ETIME.

IF VALID-HANDLE(ghWebService) THEN
DELETE OBJECT ghWebService NO-ERROR.
deTime[5] = ETIME.

IF VALID-HANDLE(ghAmadeusWebServicesPT) THEN
DELETE OBJECT ghAmadeusWebServicesPT NO-ERROR.
deTime[6] = ETIME.

DISP deTime
WITH FRAME x1 1 COLUMNS SIDE-LABELS.

Running this code produces very different results.

On my desktop (Intel Core i7, 2.8GHz, 4GB RAM):

Oe102b

       deTime[1]: 0.00
       deTime[2]: 558.00   <-- Connect statement takes ~ half a second
       deTime[3]: 558.00
       deTime[4]: 600.00
       deTime[5]: 600.00
       deTime[6]: 600.00

Running this code on Server 1 (Solaris 10, no load, 2x1,27 GHz UltraSparc-IIIi, 8 GB Ram) :

oe101c

       deTime[1]: 0.00
       deTime[2]: 3,053.00 <-- Connect ~3 seconds (varies +/- 0.5 seconds from time to time)
       deTime[3]: 3,054.00
       deTime[4]: 3,413.00
       deTime[5]: 3,413.00
       deTime[6]: 3,413.00

oe102b

       deTime[1]: 0.00
       deTime[2]: 2,540.00 <-- Connect ~2.5 seconds (varies +/- 0.5 seconds from time to time)
       deTime[3]: 2,540.00
       deTime[4]: 2,904.00
       deTime[5]: 2,904.00
       deTime[6]: 2,904.00

Server2 (Solaris 10, "a little" load, multi threaded 1,2 GHz UltraSparc-T2+, 8GB Ram)

Production Server (this is where the calls are supposed to be running)

      deTime[1]: 0.00
      deTime[2]: 6,793.00 <-- Almost 7 seconds!!
      deTime[3]: 6,794.00
      deTime[4]: 7,589.00

deTime[5]: 7,589.00
deTime[6]: 7,589.00

Of course run time vary a bit from time to time.

Earlier I got a hint that disk speed was the issue but testing disk speed as well as disk specifications show that the server is faster.

So, what is really happening in the CONNECT-statment? Are there any ways of speeding this up?

OpenEdge Development - Forum

All Replies

Posted by mresnick on 26-Jan-2011 10:14

Jens,

Every time the CONNECT is executed, the WSDL and XML Schema documents are loaded and parsed.

The only way around this is to avoid executing the DISCONNECT.

Given the connectionless nature of web services, the use of CONNECT and DISCONNECT in ABL is more of a way to dynamically identify the WDSL at runtime, than to actually create a network connection. It also makes a web service look more like an AppServer connection.

Consider performing only one CONNECT at the start of the program and not each time you actually need to gain access to the web service. Then perform one RUN…ON statement to set the Port Type handle.

After that, reuse the port type handle for RUN…IN statements, as necessary, for web service invocations.

Only at the end of the entire program run the DISCONNECT.

In this way, the WSDL and XML Schema information stays in memory and does not need to be re-fetch and parsed.

Michael

Posted by Jens Dahlin on 28-Jan-2011 01:33

Thanks,

I've considered that solution myself and as far as I can see it's the only option. I will probably take the web service calling out of the inital program itself and have a back ground process being constantly connected and wait for calls. Still I think that it's very strange that parsing and loading the wsdl-files takes ~7 seconds. That's a lot of processing time. Our unix technician used wget or similar to invoke the same web service from the same machine and it was almost instantaneous. I've also considered using that kind of 3rd party options but then I must rely on updates and such and this call is really crucial to our business.

Best regards

Jens

This thread is closed