From: ahoward <ahoward@...>
Date: 2003-03-10T13:03:27+09:00
Subject: Re: DRB and threads

On Mon, 10 Mar 2003, Brian Candler wrote:

> No - it is fcgi.rb which in turn tries to do require fcgi.so, and catches
> the exception if that fails, in which case it builds the Ruby classes
> itself.

hadn't noticed this...

> That's what I'd expect - well, actually I'd expect EINTR. Poking around
> FreeBSD header files, there's no ERESTARTSYS but there's an ERESTART which
> is used internally by the kernel, so I guess certain types of syscall are
> automatically restarted. Looks like I'll need to play to find out whether
> accept() works that way.

forgot to mention i was on linux.  i do not that restarting systems calls is
one of those gothcas between unices.  what i meant to say was that i don't
think it would be wise to mess with accept's sig handler and, since they get
installed AFTER the ones in ruby trying to reload via signals may be futile.

> Don't trap the SIGHUP. The child dies straight away, it gets respawned
> straight away by Apache (which will keep a minimum of one child per fcgi
> around unless you configure it otherwise), so the next request is handled
> successfully.

the problem is that this drops the current request, if you are using a
transactional database that might be fine - otherwise...

> I mean using the drb protocol over HTTP as an API: e.g. front-end server
> talks to the world, and talks DRB-over-HTTP to the back end system, which
> has a pool of database processes run under fastcgi. It requires Ruby at both
> ends of course, but it should be a darned sight faster than SOAP or
> YAML/OKAY, and is *so* easy to use because you just make object calls on the
> front-end (which magically perform actions on the backend)

i'm fuzzy on why you need fastcgi for the database backend?

> It can be made automatic. The C library provides a function FCGX_IsCGI()
> which lets you detect whether you're running under a fastcgi environment or
> not. (Alternatively, you could write a shell which popen's a fastcgi process
> and talks fastcgi protocol to it)

i will look into this, but not soon.  anyone else?

> Interestingly, the Ruby MOD_FCGI/CGI module itself isn't particularly
> speedly when compared with raw fcgi:

there are **alot** more function calls in mod_fcgi...

<snip>
> Argh!

good luck. ;-)

have you looked at siege - http://www.joedog.org/ - for testing?

-a


> Content-Disposition: attachment; filename="hithtml.rb"
>
> #!/usr/local/bin/ruby
>
> require 'net/http'
> require 'uri'
>
> TEST = [
>   [ 'http://127.0.0.1/index.html' ],
>   [ 'http://127.0.0.1/fcgi-bin/ftest.cgi' ],
>   [ 'http://127.0.0.1/fcgi-bin/ftest2.cgi' ],
> ]
> N = 50
> PERSIST = true
>
> $defout.sync=true
>
> TEST.each do |test|
>   it = URI.parse(test[0])
>   puts "Req:\t#{it.host},#{it.port},#{it.path}"
>   GC.disable
>   a = Net::HTTP.new(it.host, it.port || 80)
>   if PERSIST
>     a.start
>     a.socket.socket.setsockopt(6, Socket::TCP_NODELAY, 1)  # <<<< FOR UNIX
>   end
>   r = a.get(it.path)
>   puts r      ## want to check content is correct?
>   start = Time.now
>   N.times {
>     print "."   ## progress info
>     r = a.get(it.path)
>   }
>   puts "\nTime:\t#{(Time.now - start)/N}"
>   puts
>   a.finish if PERSIST
>   GC.enable
>   GC.start
> end

--
  ====================================
  | Ara Howard
  | NOAA Forecast Systems Laboratory
  | Information and Technology Services
  | Data Systems Group
  | R/FST 325 Broadway
  | Boulder, CO 80305-3328
  | Email: ahoward@fsl.noaa.gov
  | Phone:  303-497-7238
  | Fax:    303-497-7259
  ====================================