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.

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

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?!

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.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.