[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: HTTPAPI Performance Issue

From: "Pat Kennedy (IT)" <patrken@xxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: HTTPAPI Performance Issue
Date: Mon, 22 Jul 2013 19:00:29 +0000
Thanks for the response.

The program is a standalone and can be called by RPG or RPGLE programs. I also control my LR by passing a parameter that will set on LR only if requested by the calling program. I also run the program in a named activation group.

Pat
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Julius Kaj
Sent: Monday, July 22, 2013 1:45 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: HTTPAPI Performance Issue

Pat,

"The program is getting the request from a calling program ...no data queues are involved."

I read this sentence to mean that you have two separate programs that interact by passing information back and forth using call parameters, i.e. you have a top-level program that passes some data to the web service client program, which then use these data to form an XML request for the .NET web service, call the web service, parses the XML response data, puts the parsed XML values into some other parameter values that are then passed back to the calling program to be processed there.


Is the web service client a stand-alone program (created using CRTBNDRPG)? If not, you can skip the rest -- otherwise please consider...

To call the web service client from another program using either the old CALL/PARM or the newer CALLP/prototype EXTPGM type of call mechanism is not very efficient. If you use this type of call-mechanism, try to either:

1) Combine the two programs into one.
2) Change the web service client program into a "stay initialized/in memory" type of program by inserting a Return statement before the *InLR = *On;

The options are ranked by efficiency. If the web service is called often the difference in execution time may add up and become significant.
Option two is the easiest to implement, but has some issues. Since all variables will only be automatically initialized once, on the first call, you had best make sure to initialize work fields etc. yourself or you may end up with with strange results. At the very least it needs thorough testing. The allocated memory will not be freed until the job is ended (or the resources reclaimed).


Other considerations:
Do not ever use ACTGRP(*NEW) -- this will force a new activation group to be created on every call. Very inefficient!! Use a named activation group instead.



-----Oprindelig meddelelse-----
Fra: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] På vegne af Pat Kennedy (IT)
Sendt: 22. juli 2013 14:15
Til: HTTPAPI and FTPAPI Projects
Emne: RE: HTTPAPI Performance Issue

Mike,

Is the process running via HTTPAPI not fast enough or just slower than the JADE? The new process is slower than JADE.

Are you running with debug turned on? If yes, turn it off. Debug is off.

When making the comparison, are you comparing the same thing? I'm comparing response time using same requests.
What is your program doing? The program is passed parameters and building a SOAP message then calling HTTPAPI. Very small amount of data is returned.

Does it write to the data queue or it is actually doing the rest of the work? The program is getting the request from a calling program ...no data queues are involved.

Are you using Expat or something else to consume the service? I'm not using anything else to consume the service.

Are you writing to file, user space or other for consuming the web service? No file, user space, etc.

Is the program running one and done or looping for content? How often does it run? One and done.

Pat

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mike Krebs
Sent: Friday, July 19, 2013 5:27 PM
To: HTTPAPI and FTPAPI Projects
Subject: RE: HTTPAPI Performance Issue

Before I could finish my thoughts, I see a few others have chimed in...

A few thought questions...

Is the process running via HTTPAPI not fast enough or just slower than the JADE?

Are you running with debug turned on? If yes, turn it off.

When making the comparison, are you comparing the same thing?
What is your program doing?
Does it write to the data queue or it is actually doing the rest of the work?

Are you using Expat or something else to consume the service?

Are you writing to file, user space or other for consuming the web service?

Is the program running one and done or looping for content? How often does it run?

Scott suggested timestamps...Here is what I would do:
   - One way to do this (an overkill method) is to go into HTTPUTILR4 and add a timestamp in the http_dmsg procedure by altering this line:
     c                   eval      wwMsg = %trimr(peMsgTxt) + x'0d25'

     c                   eval      wwMsg = %char(%timestamp()) + ' ' +
     c                                     %trimr(peMsgTxt) + x'0d25'
   - Run the Install program again and you will get timestamps at certain points in the debug listing.
   - If you are using XML parsing in your program, add something like this to the start of the procedure or at other times in your program.
       http_dmsg('Incoming!');
  - Now you know how long each section is taking.

Check your connection from the IBMi to your webservice server. Our IBMi often pings twice as long as my PC to outside services (inside services are the same speed). Should be minor difference in downloading a file but might make a difference if you're doing significant downloads. For us, I believe this is a function of how we get through our firewall but because I don't care about the milliseconds/seconds for what we do, I have not investigated or tried to optimize that part. But if the download portion is taking any significant time, you might want to tracert from the Jade box and the IBMi and see if there are any significant differences.



-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Pat Kennedy (IT)
Sent: Friday, July 19, 2013 8:04 AM
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: HTTPAPI Performance Issue

Scott,

Are there any tuning requirements on the iSeries to use the HTTPAPI API? I'm looking to replace a JADE process that consumes .NET web service and have been running performance tests comparing the HTTPAPI called from RPGLE versus the JADE approach. The JADE process has been tuned for optimal performance and outperforms my new process using HTTPAPI. I trying to justify going with this approach but have been running into performance issues.

My prototype process uses HTTPAPI to consume the .NET web service directly from an RPGLE program as opposed to the JADE process that uses a series of data queues to communicate between RPGLE and a Java process that consumes a .Net web service. My company would like to retire JADE and is looking at either migrating the JADE process to WAS8 or directly consuming the web service via an RPGLE program using your HTTPAPI API.

Your  assistance in this matter would be greatly appreciated.

Thank You.

Patrick
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com ______________________________________________________________________
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
References:
- HTTPAPI Performance Issue
  - From: Pat Kennedy (IT)
- RE: HTTPAPI Performance Issue
  - From: Mike Krebs
- RE: HTTPAPI Performance Issue
  - From: Pat Kennedy (IT)
- Re: HTTPAPI Performance Issue
  - From: Julius Kaj
Prev by Date: Re: HTTPAPI Performance Issue
Next by Date: New To HTTPAPI - XML Request
Previous by thread: Re: HTTPAPI Performance Issue
Next by thread: New To HTTPAPI - XML Request
Index(es):
- Date
- Thread