Take it easy Brad and look after yourself!
   We all know our bodies send us messages, actually attending to the
   message, now, is the bit we are not good at.
   I am getting older and I have started listening ... not an easy thing to
   learn.
   Cheers
   Don
    
   Don Brown
   Senior Consultant
    
   [1]OneTeam IT Pty Ltd
   P: 1300 088 400
   -----Original Message-----
   From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Brad
   Stone
   Sent: Wednesday, 12 March 2025 10:39 PM
   To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
   Subject: Re: http_post consumer API calls in a mass volume situation
   Face down time was only 2 days, but I did 4 just to be "safe". They said I
   had 3 detachments and a fold (not sure what that means) and other things
   and that it must have been happening for months.
   I Just have to sleep on the opposite side for at least 30 days, maybe
   more. Not fun but lets say it wouldn't have been as bad if I had been
   stronger in insisting the changes I saw in my eye need attention.
   So, my advice.. never ignore any changes in your vision. Abd be your own
   advocate. And ignore my typos for a while. haha.
   On Tue, Mar 11, 2025 at 6:28 PM Roger Harman <roger.harman@xxxxxxxxxxx>
   wrote:
   > 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: [2]
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
   > > > > [3]
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: [4]
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
   > > > [5]
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: [6]
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
   > > [7]
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: [8]
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
   > [9]
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: [10]
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
   > [11]
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: [12]
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
   [13]
https://archive.midrange.com/midrange-l.
   Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
   questions.
   --
   Message protected by MailGuard: e-mail anti-virus, anti-spam and content
   filtering.
   [14]
https://www.mailguard.com.au
References
   Visible links
   1. 
https://www.oneteamit.com.au/
   2. 
https://lists.midrange.com/mailman/listinfo/midrange-l
   3. 
https://archive.midrange.com/midrange-l.
   4. 
https://lists.midrange.com/mailman/listinfo/midrange-l
   5. 
https://archive.midrange.com/midrange-l.
   6. 
https://lists.midrange.com/mailman/listinfo/midrange-l
   7. 
https://archive.midrange.com/midrange-l.
   8. 
https://lists.midrange.com/mailman/listinfo/midrange-l
   9. 
https://archive.midrange.com/midrange-l.
  10. 
https://lists.midrange.com/mailman/listinfo/midrange-l
  11. 
https://archive.midrange.com/midrange-l.
  12. 
https://lists.midrange.com/mailman/listinfo/midrange-l
  13. 
https://archive.midrange.com/midrange-l.
  14. 
https://www.mailguard.com.au/
 
As an Amazon Associate we earn from qualifying purchases.