OK, so it means that you don't have to program in a stateless way. However, if I have stuff that does already work in a stateless way, can I still use the IceBreak "model" to which you allude? Do my programs have to run in this isolated job or can they be called directly. If the former, are there any special considerations with regard to the way it gets called?
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Bent Rønne
Sent: 31 December 2010 10:16
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] IceBreak as an alternative to Apache?
Hi Kevin
"task switch feature"! This feature is a feature which is special in IceBreak. It is a feature that keeps track of your browser session and sends request on to an isolated job native under OS/400. This means that your programs can remain open with file pointers, variables etc. It also means that you might use the QTEMP to something practical - again. Further, you can work with the job through normal OS/400 interface such as WRKACTJOB. It also means that with this technique can debug programs without having to think about other jobs and sessions.
Regards,
Bent
-----Oprindelig meddelelse-----
Fra: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] På vegne af Kevin Turner
Sendt: 31. december 2010 00:33
Til: Web Enabling the AS400 / iSeries
Cc: Web Enabling the AS400 / iSeries
Emne: Re: [WEB400] IceBreak as an alternative to Apache?
"As you know, apache/CGI has no task-switching, so basically all requests hits the same RPG program ( with a twist) - so you need to build you own kind of task switch feature into your CGI program, which also can be error prone when we talk about isolation."
You've lost me there. What is a "task switch feature"? I don't remember coding one of those :-)
My original question is gonna get buried soon!
On 30 Dec 2010, at 23:26, "Niels Liisberg" <liisberg@xxxxxxxxxxxxx<mailto:liisberg@xxxxxxxxxxxxx>> wrote:
Hi Scott;
My answer in your mail:
Den 30/12/2010 kl. 23.38 skrev Scott Klement:
Hmmmm....
I'm sure that the CGI approach adds some overhead that IceBreak doesn't
have. But... 10 times?! Sorry, I can't believe that.
People just say 10 times faster. however it is more like 10 times "lighter" - ( read my previous post - it was stuck in the mailbox :( ) ...
If you just try to have apache/CGI and lets say 10 concurrent users. I doubt you will be able to measure the difference. The big deal is when you try to scale the application, the you can feel the difference.
As you know, apache/CGI has no task-switching, so basically all requests hits the same RPG program ( with a twist) - so you need to build you own kind of task switch feature into your CGI program, which also can be error prone when we talk about isolation.
.. again how does 1000 user on a 170 ver 5.1 sounds to you ? it works with icebreak. ( .. not fantastic but it works .. )
You say that STDIN/STDOUT is connected to the browser, and is a file.
That simply isn't true. The STDIN/STDOUT is actually a connection
between Apache and your CGI program -- the browser isn't involved. And
it's not done with *files*, it's done with *pipes*.
.. I think the Bent should write "file-handles" ... not "files"...
Pipes are
communication objects, they don't force the data to be written to disk
-- they are very similar to sockets, like the TCP channel (that *does*
connect the browser to Apache) but optimized for local
program-to-program communications.
amen brother .. we just love unix, pipes and threads and POSIX otherwise we were not able to make IceBreak in the first place :) ....
They are *vastly* faster than the TCP communications, because they are
internal to your computer, so there's no issue of network speed, or
breaking the data into packets, or any of that sort of thing. So I can't
imagine the stdin/stdout is a bottleneck on the process?!
.. you are right - the stack is the problem here ...
So while it may add a little overhead, the overhead isn't major. The
main cause of CGI performance issues (on other platforms) is actually
the overhead of starting a new process -- which isn't done on IBM i.
Yep !! and this is the core problem. Now - icebreak starts one process for each session - and keeps it; now successive request for any request in that particular browser session it the routed to that process. This vital - no process invocation is required for each browser-TCP/IP disconnect
Regards
Niels
On 12/30/2010 2:38 PM, Bent Rønne wrote:
Hi Keven
It is true that is IceBreak probably at least 10 times as fast as
Appache and the reason is very simple. IceBreak uses the direct way
to read the request from the browser and write the response back
again. Opposite if you use appache, your programs use the stdin&
stdout to communicate with the browser. Stdin& stdout are files that
must be handled and here you have the problem with performance and
Appache. Therefore it will not help if IceBreak could do the same as
Appache. However, it would probably not require a big job to rewrite
the programs to IceBreak.
In IceBreak there is a number of Build in Functions (BIF) which makes
the approach to request& response very simple. E.g. you can move
data from the URLs parameters with the function Qrystr (Alfanumeric)
or Qrystrnum (Numeric)
Sample:
From your browsers url:
http://myserver:8080/myrpgpgm.rpgle?custno=1234
RPG:
/free
...
Custno = qrystrnum('custno');
Chain custno customer;
...
When it comes to the form fields from the browser, there is BIF's to read them as well.
The HTML file:
<html>
<form action=" myrpgpgm.rpgle " method="post" name="form1">
Enter Customer name, and press enter:
<input type="text" name=" CustName">
</form>
</html>
The RPG program
...
CustName = form('CustName':CustName);
Update customer;
...
And when you need to send information back to the browser you can
simply use BIF's like "ResponseWrite"
ResponseWrite('<html>The customer name is: ' + custName + '..');
I hope this can help you further in your search for the perfect
solution. By the way you should invest some time investigating the
BIF's in IceBreak.
Check out for example the BIF like SQL_Execute! With this function
you can build a request object directly to the browser using SQL. The
function takes three parameters; 1. The result set data format, 2. A
SQL command, and 3. The maximum number of records to return. If you
look at my sample from earlier today, you will see that I'm using a
format called "I_EXTJSMETA". This means that the result set will be
returned directly in extJS format including metadata - yes you heard
right - with just one line of code you can build an entire list of
data from a database file directly in extJS.
Regards
Bent
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: <mailto:WEB400@xxxxxxxxxxxx> WEB400@xxxxxxxxxxxx<mailto:WEB400@xxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit: <
http://lists.midrange.com/mailman/listinfo/web400>
http://lists.midrange.com/mailman/listinfo/web400
or email: <mailto:WEB400-request@xxxxxxxxxxxx> WEB400-request@xxxxxxxxxxxx<mailto:WEB400-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/web400.
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: <mailto:WEB400@xxxxxxxxxxxx> WEB400@xxxxxxxxxxxx<mailto:WEB400@xxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit: <
http://lists.midrange.com/mailman/listinfo/web400>
http://lists.midrange.com/mailman/listinfo/web400
or email: <mailto:WEB400-request@xxxxxxxxxxxx> WEB400-request@xxxxxxxxxxxx<mailto:WEB400-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/web400.
________________________________
NOTICE: The information in this electronic mail transmission is intended by CoralTree Systems Ltd for the use of the named individuals or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected.
--------------------------------------------------------------------------------
CoralTree Systems Limited
25 Barnes Wallis Road
Segensworth East, Fareham
PO15 5TT
Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton, UK
SO15 2EA
VAT Registration Number 834 1020 74.
--
This is the Web Enabling the AS400 / 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.
--
This is the Web Enabling the AS400 / 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.
NOTICE: The information in this electronic mail transmission is intended by CoralTree Systems Ltd for the use of the named individuals or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected.
--------------------------------------------------------------------------------
CoralTree Systems Limited
25 Barnes Wallis Road
Segensworth East, Fareham
PO15 5TT
Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton, UK
SO15 2EA
VAT Registration Number 834 1020 74.
midrange.com
