Kelly - Excuse me,



We are talking stateless here so you will never have 20.000 routing steps
to handle at the same time unless you have millions of users where 20.000
happens to send in a request to the server at the exact same time.


Don't ever compare a web environment with a 5250 environment unless of
couse you go after a stateful environment like RPGOA.

On Wed, Oct 14, 2015 at 2:21 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

Nathan,

2,500 * 8 = 20,000 routing steps

That's probably an overshoot. While many of our DSPFs do have multiple
record formats, many have only one record format--and those that have more
than one record format almost never have 8 (more like 2-5).

But your point is well-taken.

I think there are some ways to break things up using the methods in the
original post of this thread. The fact that our developer teams are
organized along lines of business may help us in this regard. Each team is
responsible for end-to-end software development for the lines of business
they support. So we can divide apps along lines of business, then along
meaningful divides within lines of business. For example:

1. We could use multiple web servers to reverse proxy. Our development
teams are organized by lines of business. Different lines of business could
have their own web servers to serve as reverse proxies for the node apps
they use.

2. Some of our green screens contain options to run a set of related
interactive programs. For example, we have a green screen that lets
employees take options to run six interactive programs for managing
prepayments on orders. We could turn these six interactive programs into
sub-apps or modules of a single "prepayment" app. The "prepayment" app
would only have one port number and one reverse proxy route. The rest would
be handled by routing inside the "prepayment" app.

3. Some of our green screens are only used to enter parameters to run
reports. Sets of these green screens could be set up as single web pages
inside a single "run reports" app. The "run reports" app would only have
one port number and one reverse proxy route. The rest would be handled by
routing inside the "run reports" app.

My concern is how to make the best use out of such ideas. Is one of the
ideas mentioned above going to be a pain point or major limitation as we
accumulate more apps? When we want to scale up an app? When we try to
implement fail-over and load balancing? Is there a combination of the above
ideas that would be better? Or worse? Am I missing any major strategies for
hosting large numbers of node apps?

Thanks,

Kelly Cookson
IT Project Leader
Dot Foods, Inc.
1.217.773.4486 ext. 12676
kcookson@xxxxxxxxxxxx


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





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.