Re: IceBreak as an alternative to Apache? -- WEB400

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: 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.