I'm afraid most have misunderstood how Apache handles QZSRCGI jobs because
it doesn’t switch user-profiles at any time other than when the QZSRHTTP
running under the OS user QTMHHTTP starts the QZSRCGI job.
QZSRCGI jobs are started under either the servers userprofile (QTMHTTP1 or
Apache ServerUserID) or if user access to the CGI directory/library are
validated under the OS under the OS user Id that makes the request.
In the latter scenario one OS user may own several QZSRCGI jobs witch is
normally seen if AJAX is heavily used due to AJAX’s asynchrony nature
(several requests may run concurrent from the same browser session).
If an OS user requests a QZSRCGI job Apache looks for an already allocated
idle job owned by the user in the server stack, if not found or busy a new
QZSRCGI job is started until the threshold for the Apache servers QZSRCGI
job is reached.
When this happens Apache will look for another user’s idle QZSRCGI job and
close it down and start a new QZSRCGI job for the requesting OS user. If
all is busy Apache will queue the request until it can start the new job.
This is a very time consuming process and must not be considered as
persistence CGI because it’s not.
Running CGI jobs under QTMHTTP1 is actually also a bad idea since the
QZSRCGI job and any underlying programs and object must give access to
QTMHTTP1. Running Apache under its own generic ServerUserID removes many
problems that may occur with QTMHTTP1 since the programmer controls the OS
Profile. This scenario gives the best performance on Apache since 3-5
QZSRCGI jobs may service hundreds of concurrent users depending on the
overall load - but it runs non-persistence which means that the QZSRCGI
jobs is left ‘as is’ from the previous requester and there are no guarantee
that consecutive requests from a single browser session is processed by the
same QZSRCGI job that may be busy processing a request done by another
browser.
The use of non-persistence Apache also requires some ‘home brewed’ security
in front of every program in the CGI program library because there are no
such thing as a CGI program or in other words – any program that are placed
in the CGI program library becomes automatically a CGI program if it has no
mandatory *PLIST parameters that will require another program to call it
and any browser may access programs in the CGI program library unless the
is a security frontend that controls granted sessions and user access to
specific programs in the CGI program library.
On Fri, Dec 30, 2016 at 10:34 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
Job start is an expensive operation. How do you maintain an acceptable
response time, or do your menu clicks just take a very long time. Some
web
sites do, I am just wondering.
Job startup plus displaying an initial screen consumes about 20
milliseconds of CPU time. Even with the latency of the Internet, the
response is often sub-second.
After initial startup, subsequent requests typically consume 1 to 5
milliseconds of CPU time. Requests like generating PDF documents require
more time.
This architecture is supporting up to 50 million requests for dynamic
content per day in a production environment on a single IBM i server.
--
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.
midrange.com
