Re: IWS REST API performance questions

I agree with the "It depends...." answer but not entirely on board with 
async processing.  If everything can be done on-thread, not sure why add 
complexity.  So it depends on what you want the API to do. 

Sure, move things to batch and respond OK to client if the submission was 
successful.  But if you are returning a response, then you should do it 
on-thread. 

Now as far as help from IBM regarding performance, Lab services can help, 
for a fee.  I am sure the community will help with specific questions. 

Since IWS is based on Java, any performance aspects relating to Java 
affects IWS.  Also ensure you have latest Java 8 64 bit Java group PTF on 
your system in addition to HTTP group. 

But the main thing is memory.  You should have enough memory.  How much? I 
am not an expert so I really cannot say.  Nothing really tied to hardware 
although newer hardware means better performance just due to natural 
advancements hardware technology.



"WEB400" <[email protected]> wrote on 05/10/2021 10:55:58 
AM:

> From: <midrangel-zbO79nAUJZvJTQUaaPvyeQC/[email protected]>
> To: "'Web Enabling the IBM i \(AS/400 and iSeries\)'" 
> <[email protected]>
> Date: 05/10/2021 10:55 AM
> Subject: [EXTERNAL] Re: [WEB400] IWS REST API performance questions
> Sent by: "WEB400" <[email protected]>
> 
> As you might guess the best answer to all your questions is: "It
> depends".....
> 
> Generally we see memory footprint and proper use on shared pools to have 
the
> biggest effect on this type of transaction.  Rarely CPU becomes a 
bottleneck
> if the transactions are complicated, so I suggest you make the REST API 
do
> as little as possible and push the bulk of the processing to asynch 
batch
> (data queue ??) 
> 
> The thing we see most often in these situations are network bottlenecks.
> DNS look ups take too long, firewall rules that cause things to bounce
> around, too slow of an internet connection, poorly configured line
> descriptions, etc.. 
> 
> --
> Jim Oberholtzer
> Agile Technology Architects
> 
> -----Original Message-----
> From: WEB400 <[email protected]> On Behalf Of Kelly 
Cookson
> via WEB400
> Sent: Monday, May 10, 2021 9:56 AM
> To: [email protected]
> Cc: Kelly Cookson <KCookson-EAwJ3jYHSpVWk0Htik3J/[email protected]>
> Subject: [WEB400] IWS REST API performance questions
> 
> We may adopt IWS REST APIs in our shop. However, I have concerns about
> performance. I am *not* concerned that IWS REST APIs cannot perform 
well. I
> have heard from more than one person that shops have achieved good
> performance with IWS APIs at high volumes of requests. I assume it is
> possible to get the kind of performance we want from IWS REST APIs.
> 
> The question is whether or not *our shop* will be able to achieve that 
good
> performance.
> 
> 1. If achieving good performance with IWS REST APIs requires a 
relatively
> big IBM i or additional partitions for conceptual load balancing or
> something else that might involve significant new investments in 
hardware,
> then I would like to know this. This would not necessarily be a
> deal-breaker. But I would like to know what to expect in advance. (I 
know
> this is hard to answer without the specifics of our system. I am looking 
for
> a general description of what size/configuration of an IBMi system is 
needed
> to handle a high volume of REST API requests-defining high volume 
however
> you want-with good performance.)
> 
> 2. I know the "Integrated Web Services Server Administration and 
Programming
> Guide" contains suggestions for performance tuning. However, most of the
> suggestions involve things that are new to us. if we need help to 
optimize
> the various performance tuning options mentioned in the programming 
guide,
> where can we turn to for more detailed help? Can we get help from IBM, 
for
> example?
> 


-- 
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.