Comments on: CGI moon bounce

In ham radio a fun thing to do is bounce your signal off the moon. Well, in R3 A93, you can now have just about as much fun.

Type this:

url: http://www.rebol.net/cgi-bin/r3-echo.r
write url "test"
"test^/"

You've just sent an HTTP message to an R3 CGI script that echoed it back. I must admit, I really like simple examples.

And, it works reasonably fast (as least today):

dt [write url "test"]
0:00:00.328

Other lines to try, just for fun:

print write url mold system/options

print write url mold :import

print write url read %file.txt

print write url read http://www.rebol.com

The R3 CGI script is only 270 bytes:

#!./r3 -q
REBOL [Title: "R3 CGI Post Test"]

print "Content-type: text/plain^/"

limit: 100000
data: make binary! 10000

while [not empty? d: read system/ports/input][
    append data d
    if limit <= length? data [print "too big" quit]
]

print to-string data

Notice the limit if you try to send large data.

Once system/ports/output is fixed, I'll add a variation that removes the to-string line from the data. Then any binary data of any encoding can be "bounced off the moon".

See also R3 CGI test for another early R3 CGI example.

PS: now we need an embedded CGI module with the most common utility functions provided.

5 Comments

Comments:

-pekr-
27-Oct-2009 23:46:29 0.328 is not quite fast - it is imo quite slow. On my old box, for very simple stuff, I am getting order of magnitude better results using R2, and it involved decode-cgi an read-cgi functions.
So - any comparison to R2 here? I just hope we can be faster, not slower, that would be bad.
Carl Sassenrath
28-Oct-2009 0:20:13 No, for www.rebol.net, 0.328 is fast!
That time includes: local HTTP protocol processing, TCP/IP connection, transfer to server, CGI process startup, script read data, script write data, transfer back from server, local HTTP protocol data handling.
The www.rebol.net server is quite old... with no free memory (since Mediawiki with Php and MySQL were added) and very little bandwidth.
But, you say you are getting order of magnitude slower? For what types of things? Can you provide examples? I'm wondering if there is some other problem here? We should do some timings.
Generally, for most things R3 is about the same speed as R2, but keep in mind that it's using 64 bit integers and Unicode (e.g. UTF-8 encode/decode for all string I/O).
Also, if you use DO "string" types of coding practices, those are not valid in R3 and should be avoided (DO of a string is a mezz function, not a native!)
-pekr-
28-Oct-2009 4:46 My apologies. I thought you are just roughly testing R3 boot time, plus some simple stuff, while now I can understand, that you used Rebol as a client, to do measurements - then the time given is OK. My "order of magnitude" better result was just for the R2 CGI script delta (script start - script end time).
What I am doing right now is settting up web server and I will do some loop and measure R2 vs R3 speed. I don't know how to test it properly, as R3 http scheme might not be optimised, so any idea of how to properly compare R2/Base vs R3 boot time?
-pekr-
28-Oct-2009 5:49:50 So, here I am back with some tests. Tested under Cheyenne web server, the CGI script looks like following:
s: now/time/precise print "content-type: text/plain^/" print "ahoy^/" print now/time/precise - s print newline

and R2 test script to call it:
do-test: does [ s: now/time/precise loop 10000 [read http://localhost/test-r3.cgi] print ["R3 CGI test: " now/time/precise - s] ] do-test

For 1K loops, or 10K loops, results of R3 vs R2 are just about identical. Surprised, that R2/Base is not any faster than R2/View or R3/View.
So - good results for R3 indeed. I know that we still miss funcs like read-cgi, decode-cgi, cookie/session support - but those things might go into special module.
If we can also decide, what to boot, we might use it to our advantage, to further speed-up boot-time of the process for CGI purpose ...
Carl Sassenrath
28-Oct-2009 8:45:36 That test measures a lot more than just REBOL. It's also measuring TCP connection time, web server overhead, and process launch time. REBOL has no control over those things.
However, R3 is much more fine-tuned for startup, and we can also add various options to tune it even better. For example, the size of the primary stack. This is useful, but only in cases where you plan to launch hundreds of CGI queries per minute.
Also, if you look at R2, it always starts two processes. The second one is for DNS, which is often not used. R3 does not do that, so will start even faster.

Comments on: CGI moon bounce

Comments:

Post a Comment: