Whenever a named user spawns a second CGI job, it seems like the first job is abandoned, and I've always wondered whether it would spawn a third job if the second was busy. Good to know that it would try to go back to the first job.
-----Original Message-----
From: Henrik Rützou [mailto:hr@xxxxxxxxxxxx]
Sent: Friday, December 30, 2016 8:04 PM
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] In-house authentication & authorization
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.
--
Regards,
Henrik Rützou
http://powerEXT.com <
http://powerext.com/>
midrange.com
