Re: [Ftpapi] HTTPAPI https question

Have you looked at your DNS configuration? Is the system using internal or external DNS?

If it’s using an external DNS server, any delay in a response will delay your initial call but should be cached for subsequent calls, which could explain the difference in times between the first and subsequent calls..

Beyond that, we need more info about where the delay is happening… is it on the name resolution, connect, authentication, response? If you’re debugging the connection, you should be able to see where the time delay is happening.

Hope this helps.

Doug

From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx <ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx> On Behalf Of Lawrence Loz
Sent: Tuesday, March 10, 2020 12:01 PM
To: FTPAPI/HTTPAPI mailing list <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [Ftpapi] HTTPAPI https question

Hi Bradley,

Thanks for your quick response, but maybe I didnt put enough info in the question.

My timings are taken from the httpapi log from the debug, so I think it is within HTTPAPI in my RPG as thats what it is logging. The webservice that it is consuming is inhouse so I have access to their timings and their timings are consistent, driving me back to conclude that the time lapse is in my rpg containing httpapi.

From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx <ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx> on behalf of B Stone <bvstone@xxxxxxxxx>
Sent: 10 March 2020 15:31
To: FTPAPI/HTTPAPI mailing list <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Ftpapi] HTTPAPI https question

Have you testing calling your web services with POSTman or curl or something else? Most likely it's job startup that is causing the issue, not HTTPAPI.

Bradley V. Stone
www.bvstools.com
MAILTOOL Benefit #5: Easy setup! No confusing or obscure setup instructions, directory entries, SMTP users, aliases or host tables. All you need is TCPIP, a connection to the internet and you're done!

On Tue, Mar 10, 2020 at 9:49 AM Lawrence Loz <loz0707@xxxxxxxxxxxxx> wrote:

Hi,

I’ve been asked to look at a performance issue with some webservice service programs written by another programmer in our company who has now moved on. They are written using HTTPAPI and are calling https urls which in this instance happen to be a website within our company also, but not on the iseries.

The problem is that on the 1^st call the process takes about 10 seconds, but on subsequent calls it only takes about 3 seconds. This seems to be happening on all of webservices written using HTTPAPI, but I am concentrating on one in the hope that, fix that and the others will follow suit.

Is there any way of reducing the overhead on the 1^st call?

The company website calls the iseries using stored procedures, the iseries then does a number of webservice calls and processes, but the website has a 30 second timeout and so the web site often fails on the 1^st call because of timeout even through the iseries is eventually succesful, but is then successful on subsequent calls as the iseries processes these within the timeout limit.

By calling the stored procedure direct, observing the timing of the SQL and also looking at the httpapi.log in debug, I’ve arrived at timings.

If there’s anything you can suggest to alter in the way we are using HTTPAPI, I’d be really grateful.

I’ve copied a section of the RPG code below, to hopefully help.

Thanks,               Lawrence

http_setCCSIDs(1208: 0);

w#logfile =

            '/webservices/'+%subst(#1Library:2:3)+

               '/http_api_log/' + %char(%timestamp:*ISO0)+

               '-CardUnload.txt';

http_debug(*ON:w#logfile);

http_use_cookies(*OFF);

w#tempFile = http_tempfile();

rc = http_post( w#endpoint

              : %addr(SOAP) + VARYINGDATAOFFSET

              : %len(SOAP)

              : %trim(w#tempfile)

              : HTTP_TIMEOUT

              : HTTP_USERAGENT

              : 'text/xml; charset=UTF-8'

              : '""' );

w#fd = open( %trim(w#tempFile)

             : O_CREAT + O_RDWR + O_EXCL

             : S_IRWXU );



if (rc<>1);

………….

//LL01- https_cleanup();            //* we did have this in but have removed it and it doesn’t seem to make any difference either way *//



--
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi

--
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi