multiple serverside processes 
Author Message
 multiple serverside processes


> > Hi,

> > with Ruby serverside (not mod_ruby):
> > An http request is made requesting a Ruby program. This starts Ruby, and
> > the Ruby program is executed. Let's say it creates, deletes, and updates
> > files, among other things.
> > Now a second http request is made to the same Ruby proram.

> > 1. Will a new Ruby interpreter be started?
> It totally depends on server software. If it's plain Apache with mod_cgi or
> mod_ruby (or something other using CGI-like interface), then the answer is
> yes.

I think, with mod_ruby this is not the case. All scripts use the same

> > 2. Can the two running Ruby programs interfer each other?
> >     For example: could the one instance try to update a file, while the

Using a mutex with mod_ruby is not possible, because the other script
has no access to the Mutex object.
Try using FastCGI where this is possible.



Michael Neumann
merlin.zwo InfoDesign GmbH

Thu, 22 Apr 2004 03:29:49 GMT  
 multiple serverside processes

> -----Original Message-----

> Sent: Saturday, November 03, 2001 11:02 PM
> To: ruby-talk ML
> Subject: [ruby-talk:24285] Re: multiple serverside processes

> > Try using FastCGI where this is possible.

> On the server I don't have mod_ruby anyways. Since fastCGI is pure Ruby,
> I might try it. Are there any resources other than
> ?
> Some practical, basic getting started tips and examples would be great.

Sorry, can't help.

> How exactly would I use FastCGI for serving content generated by various
>   Ruby programs?
> Would all URLs point to the same Ruby file, which uses FastCGI to serve
> the requested stuff?
> Something like
> b&format=.xhtml
> ?

FastCGI isn't an implementation ... it's a (loosely) defined protocol
standard, also it's often used as a name for simplest application server
Though, there is mod_fastcgi for apache. It's works with anything what
supports the fastcgi protocol (really only a subset of it).

And URL does not matter - if you want it to look nicer, you may use
mod_rewrite (though it's slow), but it totally depends on apache+mod_fastcgi
config and has nothing to do with fastcgi protocol, technology or ruby

_____________________________________________________________ creative group

Thu, 22 Apr 2004 04:38:49 GMT  
 multiple serverside processes
How would the complete FastCGI program look that can serve anything,
including Ruby programs that print their output?
Something that can fulfill requests such as
How would it pass on the parameters?

Are there security issues?


Tobias Reif


Thu, 22 Apr 2004 06:09:13 GMT  
 multiple serverside processes


> >>1.
> >>How would the complete FastCGI program look that can serve anything,
> >>including Ruby programs that print their output?
> >>Something that can fulfill requests such as
> >>
> >>or
> >>

> [...]

> > The obligatory "Hello World" FastCGI application looks like:

> >   require "fcgi"

> >   FCGI.each_request do |f|
> >     $stdin =
> >     puts "Content-type: text/html"
> >     puts
> >     puts "<html><body>Hello World</body></html>"
> >   end

> Thanks so far; but I don't understand yet. Your examples, and the one on
> the FastCGI page all serve one thing (one option). I guess I could get
> those to run.

Yes, one FastCGI application produces *one* dynamic page. But unlike a CGI app
a FastCGI app gets it's informations (URL parameter, POST data)
through a socket instead of stdin (variable f in the example above). And of course it will
handle multiple request (it will stay in the FCGI.each_request loop).

- Show quoted text -

> No if I got that right, I would use FastCGI to prevent that a new Ruby
> interpreter is started for each request to the server requesting a Ruby
> program.
> So if I got that right too, I would use a single FastCGI program
> similiar to the three examples, with the main difference, that it can
> serve any Ruby programs output. Then the one FastCGI program is always
> running in one interpreter, and no additional interpreters are needed.
> in pseudo code:

> ---all requests for Ruby programs go to that program---
> require "fcgi"

> FCGI.each_request do |f|
>    # get(find&open) and read the requested file
>    # if it's a Ruby program, check if allowed
>    # pass the params and eval it
>    # serve its' output
>    # else serve its' content.
> end
> -----------------------end---------------------------

> This way, I don't need to have FastCGI code in each and every Ruby
> program, but just one little FastCGI serverlein, that can handle any
> request.
> (perhaps this is feasible, by passing the files' name as param; but
> perhaps it's not necessary.)

> Or did I get that wrong?

that would work.

> If I use something like the examples for each and every Ruby program in
> my account, then wouldn't that result in a new intrpreter being started
> for each Ruby program, like before?

even worse, they would all stay in memory. But each Ruby program would
only be started once.

do you need that extra amount of performance given by FastCGI ?
It makes only sense if the FastCGI scripts are called frequently. Otherwise just use CGI.

> I'm sorry; I don't yet get the basic concept.

> Or does FastCGI handle that internally? I serve each and every Ruby
> program using its' own little FastCGI servlet, and because FastCGI is
> magic, only one interpreter is started, ever? That would be nice too.

CGI works as follows:
Suppose I invoke the page /cgi-bin/test.cgi, in which case the webserver executes
the script named test.cgi (if it's a Ruby app, a Ruby interpreter is started).
The data sent by the browser to the webserver is passed to the CGI application on stdin,
while the CGI application outputs to stdout which is returned to the webserver and finally
forwarded to the browser. Via the environment variables the CGI application can ask for the
requested URL, server software, CGI version etc.

Using FastCGI this is very similar with the difference that no application is invoked by
the webserver as this is the case for a CGI script (unless you let it invoke automatically
on request by mod_fastcgi; but this would happen once).
You have to run the FastCGI application (e.g. by typing ruby myFastCGIapp.rb) before you can
access the page generated by that FastCGI application in your browser.
In the Apache conf you have to specify a host and port number on which your FastCGI application
listens. Now if there is a request for your app the webserver sents the data forming the request
through a socket to it.

You see there is no magic. It's just a simple client/server application,
where the FastCGI app is the server and the webserver the client.

> I would intensely appreciate further enlightenment.
> (anyone writing a book on serverside ruby?)

> Also: does FastCGI work well, generally?

it is fast, scalable and works well for me.



Michael Neumann
merlin.zwo InfoDesign GmbH

Sat, 24 Apr 2004 08:08:48 GMT  
 multiple serverside processes

 > [a *lot* of enlightenment]

Thank you very much.


Tobias Reif


Sat, 24 Apr 2004 17:55:06 GMT  
 [ 5 post ] 

 Relevant Pages 

1. Multiple fileevents for multiple process pipelines?

2. Q: Multiple processes writing to a single process using Expect

3. Zope-like html-forms and required, disappearing values serverside in plain python

4. UI and multiple processes

5. Processing multiple input files

6. multiple file processing

7. How to process multiple files?

8. Process multiple files same structure?

9. Process multiple files of the same structure

10. Creating multiple reports in same process

11. Credit Card Processing in Multiple currencies...

12. How to process multiple files?


Powered by phpBB® Forum Software