Rails - Dec 2005 - Lighty External Fast CGI Process Load Balacing Note

I''ve just spent a while chasing a false bug in lighttpd and load 
balancing among external fast cgi processes  due to what I think is a 
documentation bug. Following the info on the wiki page 
<http://wiki.rubyonrails.com/rails/pages/LighttpdWithProcessScripts>, 
one would think that something like this works:

	fastcgi.debug = 1
	fastcgi.server = ( ".fcgi" =>
	  ( "server1" =>
	    ( "host" => "127.0.0.1", "port" =>
8081, "check-local" => "disable"
)
	  ),
	  ( "server2" =>
	    ( "host" => "127.0.0.1", "port" =>
8082, "check-local" => "disable"
)
	  )
	)

(NOTE, a real server wouldn''t talk to 127.0.0.1, this is for debugging)

But, this doesn''t work well. When run, the debug output indicates that 
all server requests are going to the first process:

	2005-12-19 13:11:04: (mod_fastcgi.c.2539) proc: 127.0.0.1 8081  1 0 3 0
	2005-12-19 13:11:04: (mod_fastcgi.c.2539) proc: 127.0.0.1 8082  1 0 0 0

(the next to last number indicates the active requests to that process)

After diving into the lighty source code, learning about how it does its 
configurations, and then rereading the documentation at 
<http://www.lighttpd.net/documentation/fastcgi.html>, something like 
this works much better:

	fastcgi.debug = 1
	fastcgi.server = ( ".fcgi" =>
	    (( "host" => "127.0.0.1", "port" =>
8081, "check-local" =>
"disable" ),
	    ( "host" => "127.0.0.1", "port" =>
8082, "check-local" => "disable"
))
	)

The debug output looks like this:

	2005-12-19 13:10:19: (mod_fastcgi.c.2539) proc: 127.0.0.1 8081  1 0 2 0
	2005-12-19 13:10:19: (mod_fastcgi.c.2539) proc: 127.0.0.1 8082  1 0 2 0

Once again, the next to last number tells the story. Even balancing.

So, I think the problem is solved, but I want to kick this out to the 
community for comment before going in and hacking on the wiki to correct 
it.

Comments?

-- 
Posted via http://www.ruby-forum.com/.

On Dec 19, 2005, at 2:57 PM, James Duncan Davidson wrote:
> I''ve just spent a while chasing a false bug in lighttpd and load
> balancing among external fast cgi processes  due to what I think is a
> documentation bug. Following the info on the wiki page
> <http://wiki.rubyonrails.com/rails/pages/LighttpdWithProcessScripts>,
> one would think that something like this works:
>
> 	fastcgi.debug = 1
> 	fastcgi.server = ( ".fcgi" =>
> 	  ( "server1" =>
> 	    ( "host" => "127.0.0.1", "port" =>
8081, "check-local" =>
> "disable"
> )
> 	  ),
> 	  ( "server2" =>
> 	    ( "host" => "127.0.0.1", "port" =>
8082, "check-local" =>
> "disable"
> )
> 	  )
> 	)
>
> (NOTE, a real server wouldn''t talk to 127.0.0.1, this is for  
> debugging)
>
> But, this doesn''t work well. When run, the debug output indicates
that
> all server requests are going to the first process:
>
> 	2005-12-19 13:11:04: (mod_fastcgi.c.2539) proc: 127.0.0.1 8081  1  
> 0 3 0
> 	2005-12-19 13:11:04: (mod_fastcgi.c.2539) proc: 127.0.0.1 8082  1  
> 0 0 0
>
> (the next to last number indicates the active requests to that  
> process)
>
> After diving into the lighty source code, learning about how it  
> does its
> configurations, and then rereading the documentation at
> <http://www.lighttpd.net/documentation/fastcgi.html>, something like
> this works much better:
>
> 	fastcgi.debug = 1
> 	fastcgi.server = ( ".fcgi" =>
> 	    (( "host" => "127.0.0.1", "port"
=> 8081, "check-local" =>
> "disable" ),
> 	    ( "host" => "127.0.0.1", "port" =>
8082, "check-local" =>
> "disable"
> ))
> 	)
>
> The debug output looks like this:
>
> 	2005-12-19 13:10:19: (mod_fastcgi.c.2539) proc: 127.0.0.1 8081  1  
> 0 2 0
> 	2005-12-19 13:10:19: (mod_fastcgi.c.2539) proc: 127.0.0.1 8082  1  
> 0 2 0
>
> Once again, the next to last number tells the story. Even balancing.
>
> So, I think the problem is solved, but I want to kick this out to the
> community for comment before going in and hacking on the wiki to  
> correct
> it.
>
> Comments?
>
Interesting discovery, James.

I''ve always wondered what the purpose of those "named"
servers are,
since the names never seemed to do anything anyway... now it appears  
that they have some significance after all.  Anyone else with more  
expertise want to confirm?

Duane Johnson
(canadaduane)
http://blog.inquirylabs.com/