× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Since http_string() is returning a decent sized varchar(100000) without
using the new(-ish) RTNPARM keyword, there could be a performance hit if
you're actually returning smaller strings.

From the RTNPARM docs

The performance improvement is most apparent when the prototyped return
value is a large varying length
string, and the actual returned value is relatively small; for example, the
prototype defines the return
value as a one million byte varying length character string, and the value
'abc' is returned.


So http_req() is likely the performance winner...but any gains you might
see could easily be lost if you're mishandling the variable you've passed
in for ResultStr afterward

Lastly, if you're making HTTP calls in a tight enough loop for the
differences between http_req() and http_string() to matter...

Then you should be looking at using a persistent connection
http_persist_open()
http_persist_req()
http_persist_get()
http_persist_post()

Opening an HTTP connection is time consuming...and an SSL/TLS is really
time consuming (800ms+).

http_req() and http_string() both open/send/close.

Lastly, just realize that a persistent connection only helps if you're
sending requests to a single server from within a job.

So for example, if you've got 10,000 interactive users whose jobs make
repeated requests to 3 different web services...
- it's unlikely that an individual job would be making requests, to the
same endpoint, fast enough to leave a persistent connection open
- HTTP API only supports 1 connection at a time
---- the later can be worked around via activation groups (HTTP API runs
in *CALLER)

If you change those programs to place a request on a data queue and have a
set of batch jobs actually doing the HTTP request..
- same issues apply!

What you really need is a seperate data queue and set of jobs for each HTTP
endpoint.
- now you can use a persistent connection to efficiently stream requests to
an endpoint..

I've got just such an architecture that will send over 100,000 requests
during the business day with an average HTTPS call time of 0.078 seconds.

Charles

On Thu, Oct 1, 2020 at 11:07 PM Suren K <suren7437@xxxxxxxxx> wrote:

Hi Everyone,

I am exploring Scott Klement's HTTPAPI for making outbound HTTP requests
from IBMi.

I could see http_req() is the function used for making all types of HTTP
requests. Also i could see the HTTP_string() function for making all types
of HTTP requests for shorter strings (which in turn used http_req() for
processing).

I am planning to use http_req() directly for all types of requests (shorter
and also longer strings), will it create any performance delay or using
http_req() directly will execute any additional steps?

Could you please give me your suggestions in it?

Regards,
Surender K
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.