Brad, you've posed some good questions. In regards to the Node event loop,
I have to admit that it's intriguing in a geeky sort of way. Now back to
business...
What would you call a "broadly scoped application" and how would CGI not do
better than x, y or z (you fill those in).
In regards to broadly-scoped applications, I'm referring to ERP class
systems. In regards to x, y, or z... just about every mainstream web
application environment is based on CGI, or patterned after it, and has
similar attributes and constraints.
Actually, most non-IBM i environments are more resource intensive because
requests are dispatched to processes which host virtual machine
environments, language environments, and web application frameworks. IBM i
CGI just makes ILE program calls.
Thousands of concurrent users? You need to know how to set up sessions
that are not server dependent (ie, session cookies, etc). If it's the
resources, the Apache server when set up properly can handle thousands of
connections (I think you even mentioned this in a LI thread a few days
back). Maybe that's not what you're referring to here.
You may be referring to my earlier comment in this thread - one of our
clients running 3,500+ threads in a single Apache instance. However, if
you're running that many threads which correspondingly connect to an equal
number of CGI processes, and you're not using persistent CGI, then over
time all of your CGI programs become activated in all the Jobs, as the HTTP
threads dispatch requests indiscriminately to whatever CGI job which might
be available. A built-in memory leak.
What other interface doesn't require different environments for test, devo
and live? (Well, no interfaces "requires" this, but it's standard
practice).
Good point, most mainstream web application environments require separate
LPARS for this.
Hosting many tenants on a single server? What does that have to do with
CGI?
In most cases, each tenant needs their own environment (i.e. LPAR or
subsystems, HTTP server instance, App Server Instance, etc.) I think your
point is that x,y, and z are impacted by this too, so the question is what
architecture handles this most efficiently and is more easily managed?
By "server" do you mean a single web instance or a physical machine,
because it's very easy to set up multiple servers on multiple IPs on the
IBM i.
In regards to a single server, I was referring to a single IBM i server,
which of course can run multiple HTTP server instances, etc.
One solution to this problem is to stop running application frameworks and
applications in HTTP server jobs. Relegate the HTTP server to
communications. Use some form of inter-process communications to forward
client requests to essentially independent outside jobs for processing,
then returning responses to HTTP clients.
Yes.
Interesting. Can you provide a real world example for this? I'd like to
see if the added complexity would be worth it for this.
In regards to real-world examples, yes we provide a multi-tenant
cloud-based service for K-12 school districts which is based on this
architecture and we have a few clients who have deployed similar workloads
- one of which has supported up to 50 million requests for dynamic content
per day.
You would obviously need to send some type of session id from the HTTP
server to this outside job so that it can return a response to the
requester if I'm reading this correctly.
Actually, don't you mean sending some sort of session ID to clients? That's
what we do.
How would a "timeout" (ie MSGW, infinite loop, etc) work in this case since
the HTTP server would only be returning a simple "I received your request..
it's being processed" type of response, and the "real" response would be
coming from this outside job.
Under our system, both a response timeout, and an inactivity timeout can be
configured per "application", which refers to one JOB instance. HTTP sever
threads wait for the response timeout and if the no response is provided,
then the HTTP server module returns an HTML page which can be specific to
that application.
If a job has reached an inactivity timeout, we have a "supervisor" send it
a message requesting that it "end" itself. If a client tries to connect to
it after that, then a formatted message is returned to the client saying
that it's session has ended - the client is redirected to the menu.
HTH,
Nathan.
midrange.com
