|
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
"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.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
