Newsgroup Protocols?
Tim Johnson
I just subscribed to this newsgroup.
1)I would welcome information on appropriate protocol for this group.
2)I would also welcome being pointed to some sites that give a good
over-view of this language.
3)Among other things, I am interested in TCP/IP features in scheme
and in CGI
TIA
--
Tim Johnson <t...@johnsons-web.com>
http://www.johnsons-web.com
brl...@my-deja.com
> Hi :
> I just subscribed to this newsgroup.
> 1)I would welcome information on appropriate protocol for this group.
I think we're making it up as we go along.
Only tip I can give is when you ask a question, specify that it's not
for homework. Sometimes students come here trying to get others to do
their work for them.
> 2)I would also welcome being pointed to some sites that give a good
> over-view of this language.
There are several good books
http://www.schemers.org/Documents/#all-texts
Which to choose depends on your background and what you wish to do.
> 3)Among other things, I am interested in TCP/IP features in scheme
These vary from implementation to implementation.
> and in CGI
Usually, server-side web programming in Scheme does not use the Common
Gateway Interface (CGI) for performance reasons.
--
(for-each (lambda (str) (display (string-append (make-string (- 40
(quotient (string-length str) 2)) #\space) str)) (newline)) '(""
"Bruce Lewis" "MIT 1990" " http://brl.sourceforge.net/
")) ; I rarely read mail sent to brl...@my-deja.com
MJ Ray
> > and in CGI
> Usually, server-side web programming in Scheme does not use the Common
> Gateway Interface (CGI) for performance reasons.
MzScheme's CGI support almost seems fast enough to use in stand-alone
scripts to me. However, if you're talking to databases, that's not a
good idea...
--
MJR (Not an official statement)
Please note changes of address http://stats.mth.uea.ac.uk/
Rob Warnock
+---------------
| brl...@my-deja.com writes:
| > Usually, server-side web programming in Scheme does not use the Common
| > Gateway Interface (CGI) for performance reasons.
|
| MzScheme's CGI support almost seems fast enough to use in stand-alone
| scripts to me.
I agree. I just finished doing a one-off internal survey, for which both
the form-submission/data-recording and the later post-processing/reporting
were done with a CGI using the MzScheme "cgi.ss" library. It was plenty
fast for that application (~400 survey forms submitted the first two days,
with another ~40 that trickled in over the next week).
Minor neat hack: If you run a post-processing/reporting CGI script directly
from the shell [as yourself], the environment variable "REQUEST_METHOD"
will [normally] not be set, which will cause (get-cgi-method) to return
#f, which you can use to do something different for the interactive case,
such as at the very end:
(unless (get-cgi-method) ; if run from a shell,
(read-eval-print-loop)) ; stop before exiting for debugging
+---------------
| However, if you're talking to databases, that's not a good idea...
+---------------
Well, that depends. If you had an intermediate server program that
cached connections to the database, such that CGI scripts could connect
(with a TCP socket) to the intermediate program without going through
a full heavyweight database connection, then it should be plenty fast
enough for low-volume stuff (local intranets), though maybe not for
running a mass-distribution public web site.
-Rob
-----
Rob Warnock, 30-3-510 <rp...@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
Shriram Krishnamurthi
> MzScheme's CGI support almost seems fast enough to use in stand-alone
> scripts to me. However, if you're talking to databases, that's not a
> good idea...
I venture that if you're talking to a database, the mere cost of
accessing the database (through layers of protocols) is enough to
dwarf quite a bit of MzScheme cost. And presumably much of your
processing is being done in the database engine itself. So unless
it's a truly intensive computation, I don't see why MzScheme + DB
access is any worse than MzScheme's use stand-alone.
Btw, I'm not sure what your definition of "fast enough" is, but for
several years, every CGI script on the Rice CS department Web site was
written entirely in MzScheme. So are servers for several Web sites
now, including www.htdp.org and www.teach-scheme.org, as well as the
paper submission mechanism for the PADL 2002 symposium.
Shriram
brl...@my-deja.com
> MzScheme's CGI support almost seems fast enough to use in stand-alone
> scripts to me.
I was pleasantly surprised by mzscheme's startup time when I tried it
after reading your message. I even made a little test CGI script, which
Apache served up at 9 requests per second, fast enough for
most applications. I guess my assumptions about CGI speed are based on
1997 hardware.
However, CGI does put a ceiling on how much performance you can get.
I made a bash script that outputs the same content as the mzscheme
script, only without computation, and Apache served about 100
requests/sec. MzScheme can't exceed that with CGI no matter how fast
the startup time. You need the Plt web server.
For comparison, the same program in PHP was 175 request/sec, in BRL 220
requests/sec (using IBM's JRE). I would expect the Plt web server to be
as fast or faster.
> However, if you're talking to databases, that's not a
> good idea...
If 9 requests/sec is enough for your app, you're likely only getting 1
or 2 concurrent users at any given time. So adding a database
connection might not add noticeable lag time.
--
Bruce R. Lewis http://brl.sourceforge.net/
Mario Latendresse
brl...@kindness.mit.edu writes
> I was pleasantly surprised by mzscheme's startup time when I tried it
> after reading your message. I even made a little test CGI script, which
> Apache served up at 9 requests per second, fast enough for
> most applications. I guess my assumptions about CGI speed are based on
> 1997 hardware.
>
> However, CGI does put a ceiling on how much performance you can get.
> I made a bash script that outputs the same content as the mzscheme
> script, only without computation, and Apache served about 100
> requests/sec. MzScheme can't exceed that with CGI no matter how fast
> the startup time. You need the Plt web server.
>
> For comparison, the same program in PHP was 175 request/sec, in BRL 220
> requests/sec (using IBM's JRE). I would expect the Plt web server to be
> as fast or faster.
>
> > However, if you're talking to databases, that's not a
> > good idea...
>
> If 9 requests/sec is enough for your app, you're likely only getting 1
> or 2 concurrent users at any given time. So adding a database
> connection might not add noticeable lag time.
>
I recently did some work for the Navy transforming a CGI script
written in Scheme to a fastCGI version. It accesses a database for
each request.
The system works well in its CGI form, but a fastCGI version solves
several efficiency problems. There are several advantages to the
fastCGI architecture.
1) Startup time is near zero.
2) All connections with the database can be made permanent.
3) With Apache you can set a maximum of scripts that can be started.
Note that answering one request, a CGI application may have to use
several sub-scripts (database, etc.) creating several Unix processes.
In out case, it was like five processes for every request. With
thousands of requests a day it pulls down the capacity of the system.
Point (3) is important, since if one of the client request takes a lot
of processing (let say a minute or two), it may have a domino effect:
with a burst of incoming requests a large number of Scheme
interpreters will start, probably trashing the system. The permanent
(fastCGI) script can still answer more requests then the preset limit
of scripts, without creating that problem.
--
Mario Latendresse
Shriram Krishnamurthi
> For comparison, the same program in PHP was 175 request/sec, in BRL 220
> requests/sec (using IBM's JRE). I would expect the Plt web server to be
> as fast or faster.
Bruce, since you already have the basic setup in place, and it's best
to compare on the same platform, can you try the same w/ the PLT
server when you get a moment?
Shriram
MJ Ray
> [...] I don't see why MzScheme + DB
> access is any worse than MzScheme's use stand-alone.
Well, the start-up of the database extensions seems to be where the
time delay is for me, which I don't quite understand. I'll know more
when I look at this more closely, but for now I know that CGI wasn't
fast enough, while PLT webserver seems to be.
brl...@my-deja.com
> Bruce, since you already have the basic setup in place, and it's best
> to compare on the same platform, can you try the same w/ the PLT
> server when you get a moment?
Does it take long to download/install/configure the PLT server? I'm not
confident to have found the canonical place for it via google search.
I can also provide the pertinent files to anyone else who wants to
compare.
Shriram Krishnamurthi
> Does it take long to download/install/configure the PLT server? I'm not
> confident to have found the canonical place for it via google search.
Sorry, we're in the midst of upgrading various Web pages. It'll soon
have its own page. For now, go to
http://www.cs.utah.edu/plt/develop/
for our 3rd-party contributed software, or directly to
http://www.cs.utah.edu/plt/develop/webserver.plt
for the server. This is in PLT's portable, self-installing format.
You can either enter this URL into DrScheme's File | Open URL and sit
back and let it do all the work, or download it separately and run the
Setup PLT program (PLTHOME/bin/setup-plt, on Unix) on it.
When you're done, you need to config the server. (We will make this
much, much easier in future versions, but it's not particularly hard
even now.)
1. Run the program
----------------------------------------------------------------------
(require (lib "web-server.ss" "server"))
(serve 8080)
----------------------------------------------------------------------
in the server's root directory, eg,
mzscheme -r server.scm
If you leave out the port number, it serves out of port 80.
2. In the server's root directory, create
htdocs/
-- populate w/ docs; index.html is the default document
conf/
cgi-refresh.html
-- doc to display when server has re-loaded cached CGI scripts
not-found.html
-- doc to display for 404 error
cgi-bin/
-- for server scripts
Server scripts are written in Scheme. The documentation in
PLTHOME/collects/server/doc.txt should give you more information on
these, or you can just ask us.
Shriram
Shriram Krishnamurthi
a program crash and dump a core file. I (at Brown) wanted Matthew
Flatt (at Utah) to be able to run gdb on it. gdb is just an
interactive program, and our server is supposed to make it especially
easy to write interactive programs w/ information shared across
interactions. So instead of setting him up with login access, Paul
Graunke and I hacked up a quick little interface to gdb. It's quite
cute, really.
The code simply loops, prompting the user for a command line which it
feeds to GDB, and prints the output back. It keeps track of the
history of commands, and on each submit prints out a complete
transcript. Users can thus ignore a futile exploration by using the
Back button to go up a few levels, then explore a different path.
As you can see, the code is also written in two logically separate
halves -- the first half says nothing about GDB whatsoever (except the
comments I just added), while the second half is the GDB parser.
Therefore, you can easily share any application privately with someone
you trust (even a shell).
Hope this code's intent is clear (if not, ask!).
Shriram
;; Note: uses v200 syntax to load libraries (rest of the code
;; should work in any version)
(require (lib "unitsig.ss"))
(require (lib "cgi-sig.ss" "server"))
(require (lib "process.ss"))
(let ([process* process*])
(unit/sig () (import cgi^)
;; Given the history of commands and outputs,
;; HTML-formats them to be a bit pretty
(define (generate-i/o-page all-commands k-url)
`(html
(head
(title "Interaction"))
(body
,@(map (lambda (interaction-pair)
`(p
(strong (tt ,(car interaction-pair)))
(br)
(blockquote (pre ,(cdr interaction-pair)))))
(i/o-loop all-commands))
(form ((action ,k-url)
(method "post"))
(p
(input [(type "text")
(name "new-input")
(size "40")
(value "")])
(input [(type "SUBMIT")
(name "submit")
(value "Submit")]))))))
;; The main puppy
(define (driver-loop commands-so-far)
(let-values
([(method url headers bindings)
;; This is a continuation capture -- control returns here
;; when the user enters a new command for gdb
(send/suspend
(lambda (k-url)
(generate-i/o-page commands-so-far k-url)))])
(driver-loop (append commands-so-far
(list (cdr (assoc 'new-input bindings)))))))
;; Assumes a generic shell-like behavior
(define (i/o-loop all-commands)
(let-values
([(stdout stdin pid stderr status)
(apply values
(apply process*
PROGRAM-NAME
ARGUMENT-LIST))])
(begin0
(cons (cons "" (read-until-prompt stdout stderr))
;; The first element is the banner information;
;; the "" is because the user didn't type anything
(map (lambda (cmd)
(cons cmd
(get-program-output cmd stdin stdout
pid stderr status)))
all-commands))
(close-input-port stdout)
(close-output-port stdin)
(close-input-port stderr))))
;; Everything after this is GDB- and site-specific
(define PROGRAM-NAME "/pro/gnome/bin/gdb")
(define ARGUMENT-LIST
(list "<program path went here>"
"<core file path went here>"))
(define GDB-PROMPT (regexp "\\(gdb\\) $"))
(define GDB-PROMPT-SIZE 6)
(define (read-until-prompt stdout stderr)
(string-append
(let loop ([chars '()])
(cond
[(char-ready? stdout)
(loop (cons (read-char stdout) chars))]
[else
(cond
[(regexp-match GDB-PROMPT
(list->string (reverse chars)))
(list->string (reverse (list-tail chars GDB-PROMPT-SIZE)))]
[else
(loop (cons (read-char stdout) chars))])]))
(let loop ([chars '()])
(cond
[(char-ready? stderr)
(loop (cons (read-char stderr) chars))]
[else
(list->string (reverse chars))]))))
(define (get-program-output cmd stdin stdout pid stderr status)
(display cmd stdin)
(newline stdin)
(read-until-prompt stdout stderr))
;; We're all set up; begin execution by invoking the loop
(driver-loop '())
))
brl...@my-deja.com
do any special configuration on it. I took my previous CGI script that
invoked mzscheme and tweaked it to go in the server's cgi-bin (NOT based
on NCSA's CGI).
The result was 358 requests/sec, compared to 175 for PHP3.
This while logging 1000 requests to an xterm. Someone who wanted to try
harder could likely get a good deal more performance.
Forgive the top-posting, but here's my previous post for reference:
MJ Ray
[plt]
> The result was 358 requests/sec, compared to 175 for PHP3.
Great stuff! It would also be interesting to know how Serveez (Guile)
compares, although I expect it to be somewhere between the two and
you've done quite enough testing for the common benefit.