RE: http_post consumer API calls in a mass volume situation

Hope you have a quick and complete recovery.

Assume you're living life face down for some time?



-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Brad Stone
Sent: Tuesday, March 11, 2025 10:48 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: http_post consumer API calls in a mass volume situation

I don't think that's an option. I've never seen anything where it caches
the connection so the handshake isn't repeated with "familiar" clients, but
then again... I haven't really dug into it that much. The only way I
could see that happening is if the connection is left open and the other
end allows it (some do, some don't. GETURI allows you to keep it open, but
in most cases it won't work unless you're communicating with something like
an FTP, SMTP, etc server.. not just HTTP requests).

Sorry, I shouldn't have even called it a "fight". :) Just using it as
reference to bottlenecking that we'd all understand.

Now, as for a REAL fight, you should see what I look like after having
retinal detachment surgery on Friday. They beat me up good! haha.. but I'm
on the mend.

On Tue, Mar 11, 2025 at 12:42 PM Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

please don't remind me of that fight Brad. :)

So, what about ssl handshake retention?

Ever noticed anything in that area?

thanks

Jay

On Tue, Mar 11, 2025 at 1:28 PM Brad Stone <bvstone@xxxxxxxxx> wrote:

Even if your system CPU and network is up to snuff, you will notice a

huge

difference in speed vs native i/o. But, in most cases I've found it's

the

other side that is the bottleneck, not the IBM i with sufficient CPU and
networking.

It's still "fast enough" in most cases. But I have worked with customers
where when the other end gets hit by more than 100 requests at a time it
just chokes... most of the time they are server farms, Amazon shared
services, etc... never in house systems.

Think of the Tyson fight on Netflix. They were VERY underpowered and
underestimated the bandwidth and CPU that would be required. And they

paid

the price. It wasn't the fault of the viewers, it was the foresight of
Netflix and how many resources they thought they'd need.


On Tue, Mar 11, 2025 at 12:06 PM Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

Let me start with just a pretty generic question and scenario.

If you had a need to send a large volume of http API consumer requests
from your native applications (and db2)... is it correct to think that
http_post may not exactly be the best choice as it is real time
synchronous...
If so, what are some other good options?

Or am I wrong? Could you expect http_post to hold up.

Pretty speculative scenario I realize - but imagine a level of volume

that

you may consider moderate to high even for your native applications to

go

after db2 data locally - but instead, those "i/o"s are considering to

be

replaced with http_post to another system.
As a change occurs in the application, that change is pushed over off
platform via http via the http_post...

can it work?
what are the considerations?
Also this would be with https (ssl authentication in play)

tia

jay
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.