Re: IceBreak as an alternative to Apache?

[Niels Liisberg <liisberg@xxxxxxxxxxxxx>]

My answer in your mail:

Den 31/12/2010 kl. 01.35 skrev Kevin Turner:

> OK that is useful info thanks.

My pleasure..

> Just to clarify, I am not looking to replace Apache.

Actually, we also use Apache to "frontend" icebreak apps, just for the reason that apache have some cool rewrite and reroute features....   

> I am happy to stick with it for Renaissance. But if I can also get it to work with different HTTP servers (that may have other things to offer) then I want to try. If I don't try I won't ever know.
Exactly , and if it ain't broke - don't fix it... The IceBreak team just hate the concept "one size fits all"  that many other solution out there provides. IceBreak works just fine in combination with PHP, apache/CGI, WebSphere/tomcat. We just try to provide a solution that is easy to configure, comprehend and get products to market quickly.     

> With the environment variables, I am not looking to set them programmatically. I want to be able to set them permanently (by server) in a configuration file in the same way that I might in an Apache config file. Attributes of the server that are stored whether it is running or not if yo see what I mean.

If you are happy with "setenvvar" why not just use that within icebreak it works just fine - IMHO a little clumsy however but again - if it ain't broke - don't fix it.  

> -----Original Message-----
> From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Niels Liisberg
> Sent: 30 December 2010 23:50
> To: Web Enabling the AS400 / iSeries
> Subject: Re: [WEB400] IceBreak as an alternative to Apache?
>
> Hi Kevin
>
> Your original question is not buried - I was trying to answer on behalf of Bent. First your questions .. then my answers:
>
>
>
> > > Hi Kevin - Let me help Bent here .. my answers in your mail ...
> > >
> > >
> > > > Bent
> > > >
> > > > What if I want it to be more generic than that?  In other words, I don't know (or care) what the variables are on the query string - I just want to get the entire query string. Is there a BIF for that?  I don't want it translated to EBCDIC either - I just want it in its raw form (i.e. UTF-8).
> > >
> > > simply:
> > >
> > > myQryStr = getServerVar('REQUEST_RAW'); // this will be in the CCSID of your job
> > > myQryStr = getServerVar('REQUEST_RAW_BIN'); // this will be url-encoded ascii stuff
> > >
> > >
> > >
> > > > I would also need the equivalent of "ResponseWrite" which will accept a pointer to data that will include the HTTP header and that will not translate from EBCDIC (the data will already be in UTF-8). Is there a BIF for that?
> > > > If it cannot accept a pointer then one that can be called in a loop will do, so the response can be sent in chunks.
> > >
> > > 1)
> > > if you want to send in chunks. IceBreak supports automatically "Chunked Transfer encoding" (rfc 2616)
> > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html
> > >
> > > just call :
> > >
> > > setChunked(1024) ;   // where 1024 is the chunk threshold
> > >
> > > 2)
> > > The header is controlled much like on tomcat or IIS
> > >
> > > setHeader("cachetimeout" : "1234");
> > >
> > >
> > > 3)
> > > the loop:
> > >
> > > you can just iterate arroud a response write:
> > >
> > > for i = 1 to 100;
> > >    responseWrite("Hello " + %char(i) );
> > > endFor;
> > >
> > >
> > > 4)
> > > and pointers - we have an feature ILOB - Internal Large Objects ( like CLOB / BLOB in db/2) which is pointer (to i.e. a userspace)
> > >
> > > setResponseObject(myPacePointer);
> > >
> > > then:
> > >
> > > responseWrite("Mystuff");
> > > responseWrite("more stuff");
> > > responseWrite("Mystuff");
> > > responseWrite("Mystuff");
> > >
> > > ... goes to the ILOB ( the userspace)
> > >
> > > and finally :
> > >
> > > setResponseObject(*NULL);            // Now output goes to the browser again
> > > responseWriteIlob(myPacePointer); // and we send the ilob ( the userspace to the client)
> > >
> > >
> > >
> > >
> > > > If so, then it would be very easy for me to run a Renaissance application (or a CGIDEV2 application) behind an IceBreak server rather than an Apache server - I can therefore compare and contrast the performance differences under load. I am very interested in having an alternative to Apache that also scale up to a minimum of 1000 concurrent sessions.
> > >
> > > remember that IceBreak handles the "task switching" for you so you don't have to relocate resource if a new session kicks in  ( you dont need all the SETLL with the new session)  .. you will ( or can ) have a session mapped to a OS/400 job  which again is purged so you can relly on OS/400 to do the workload balance which it does brilliantly with these tiny IceBreak jobs.
> > >
> > >
> > > > Also, is it possible to configure the equivalent of environment variables for the server in a similar way to being able to do so with Apache?  For example (in Apache):
> > > > SetEnv  <name>  <value>
> > > > So I can retrieve these bespoke config values as well as other usual suspects (like SERVER_SOFTWARE, REQUEST_METHOD, HTTP_USER_AGENT etc etc).
> > >
> > > 1)
> > > we have the equivalent to PHP:
> > >
> > > ie:
> > > if getServerVar('REQUEST_METHOD') = "POST";
> > >  doPostStuff();
> > > endif;
> > >
> > > 2)
> > > set env:
> > >
> > > we have system wide settings:
> > >
> > >     getGlobal() and setGlobal()
> > >
> > > and for the session:
> > >
> > >    getSessionVar() and setSessionVar()
> > >
> > > which remains even if you jobs times out and/or have to be reloaded
> > >
> > >
> > > > I already have the all the goodies I need in Renaissance (like SQL_Execute) so it is really the start and end-point that I would like to concentrate my enthusiasm on :-)
> > >
> > > Actually we are trying to combine the webserver, the applicationserver, the toolbox/utilities like SQL_Execute , httpRequest , xmlParseFile (for x-path) etc. to give you a solid foundation, and not only a framework.
> > >
> > > But if it works in Renaissance with appache, why change it... if you look at i.e. PowerExt, it runs both apache/CGI and IceBreak at the same time. apache/CGI for basic extJs stuff and IceBreak for running old 5250 (IceCap'ed) apps in extJs.
> > >
> > > You can do both :)
> > >
> > >
> > > > I have posted a similar question on your forum if you think it is better to take this offline?
> > >
> > > Thanx Kevin - I think you might like if i gave you the-grand-tour-demo-go-2-meeting some time :)
> > >
> > > > Rgds
> > > > Kevin
>
> Den 31/12/2010 kl. 00.32 skrev Kevin Turner:
>
> > "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.
> -- 
> 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.