Re: http_post consumer API calls in a mass volume situation

[Brad Stone <bvstone@xxxxxxxxx>]

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.