They work by changing the #!/usr/bin/perl line to #!/usr/bin/speedy or
#!/usr/bin/pperl. The replacement version embeds the Perl interpreter.
The first time it’s run, it loads the interpreter, compiles the script,
and daemonizes itself after establishing a Unix socket (or TCP listening
socket). Then the second time the binary is run it will detect that the
daemon already exists and then just run the already-compiled script in
the daemon process, communicating through the socket.
So in effect it is like FastCGI, but without the web/CGI-like protocol
stuff. To use PPerl/SpeedyCGI, just replace the shebang line.
It sounds kind of neat, like a more automagic fastcgi. I don’t think that
Ruby has anything like this currently. Your options are fastcgi, modruby,
or webrick pretty much if you want to benefit from a persistent
interpreter. As far as pre-“compilation” of scripts, Ruby doesn’t have
anything like that afaik, aside from something like bRuby, but I don’t
know how fast that is or if anyone is using it for this purpose (dumping
the AST so it can be reloaded), like .pyc files in Python.
Are you interested in porting it?
–Gabriel
···
On Wed, 19 Feb 2003 04:31:33 +0900, David Garamond wrote:
Is there an equivalent of SpeedyCGI or PPerl for Ruby?
They work by changing the #!/usr/bin/perl line to #!/usr/bin/speedy or
#!/usr/bin/pperl. The replacement version embeds the Perl interpreter.
The first time it’s run, it loads the interpreter, compiles the script,
and daemonizes itself after establishing a Unix socket (or TCP listening
socket). Then the second time the binary is run it will detect that the
daemon already exists and then just run the already-compiled script in
the daemon process, communicating through the socket.
So in effect it is like FastCGI, but without the web/CGI-like protocol
stuff. To use PPerl/SpeedyCGI, just replace the shebang line.
They work by changing the #!/usr/bin/perl line to #!/usr/bin/speedy or
#!/usr/bin/pperl. The replacement version embeds the Perl interpreter.
The first time it’s run, it loads the interpreter, compiles the script,
and daemonizes itself after establishing a Unix socket (or TCP listening
socket). Then the second time the binary is run it will detect that the
daemon already exists and then just run the already-compiled script in
the daemon process, communicating through the socket.
So in effect it is like FastCGI, but without the web/CGI-like protocol
stuff. To use PPerl/SpeedyCGI, just replace the shebang line.
Interesting. If the embedded interpreter restarts the CGI script for each
invocation, does that mean it loses global variables, so you couldn't keep a
persistent connection to a database for example? Or is that state carried
forward between invocations? (In which case why not just use mod_perl?)
Regards,
Brian.
···
On Wed, Feb 19, 2003 at 04:31:33AM +0900, David Garamond wrote:
Is there an equivalent of SpeedyCGI or PPerl for Ruby?
How much of perl's state is kept when speedy starts another request?
Do globals keep their values? Are destructors run after the request?
Globals keep their values. Nothing is destroyed after the
request. STDIN/STDOUT/STDERR are closed -- other files are not.
%ENV and @ARGV are the only globals changed between requests.
Not sure of the advantages over mod_perl though; you end up with a separate
pool of perl processes, in addition to Apache's pool of httpd servers. I
suppose if you use the C wrapper to handle CGI requests it means you don't
have to modify your web server (but then if you use mod_speedycgi then you
lose that benefit!)
Regards,
Brian.
···
On Wed, Feb 19, 2003 at 03:07:20PM +0000, Brian Candler wrote:
Interesting. If the embedded interpreter restarts the CGI script for each
invocation, does that mean it loses global variables