× 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.



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" <web400-bounces@xxxxxxxxxxxxxxxxxx> wrote on 05/10/2021 10:55:58
AM:

From: <midrangel@xxxxxxxxxxxxxxxxx>
To: "'Web Enabling the IBM i \(AS/400 and iSeries\)'"
<web400@xxxxxxxxxxxxxxxxxx>
Date: 05/10/2021 10:55 AM
Subject: [EXTERNAL] Re: [WEB400] IWS REST API performance questions
Sent by: "WEB400" <web400-bounces@xxxxxxxxxxxxxxxxxx>

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 <web400-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Kelly
Cookson
via WEB400
Sent: Monday, May 10, 2021 9:56 AM
To: web400@xxxxxxxxxxxxxxxxxx
Cc: Kelly Cookson <KCookson@xxxxxxxxxxxx>
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?




As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.