I was working on deploying an app with switchtower, and I really
dislike the way spawner is implemented. The way it will relaunch the
dispatcher all the time just to let it die if the port is in use is
too brute force for my taste.
As we’re in a ruby script, why not let ruby find out if the port is in
use? Using the TCPServer class we can try and bing to the port. If we
succeed, it means the process died and we can launch the dispatcher.
But if an exception is raised, we can skip even trying to launch the
dispatcher.
Here’s the change to the spawn method (and remember to add require
‘socket’ at the top):
def spawn(port)
print “Checking if something is already running on port #{port}…”
begin
srv = TCPServer.new(‘0.0.0.0’, port)
srv.close
srv = nil
print “NO\n "
print “Starting FCGI on port: #{port}\n "
system(”#{OPTIONS[:spawner]} -f #{OPTIONS[:dispatcher]} -p #{port}”)
rescue
print “YES\n”
end
end
More details in my blog: http://devblog.famundo.com/
Bye,
Guy
Family management on rails: http://www.famundo.com - coming soon!
Am Sonntag, den 05.03.2006, 02:21 -0800 schrieb Just S.:
system("#{OPTIONS[:spawner]} -f #{OPTIONS[:dispatcher]} -p #{port}")
rescue
print “YES\n”
end
end
I don’t see the benefit. It is the same brute force as in the spawner
script,
with the only difference that the test is done inside the script. Why do
you
want to check if the port is in use if spawn-fcgi will do it anyway?
There is even a disadvantage: If you test with TCPServer.new and the
port is not in use, it may be in use at the point spawn-fcgi is trying
to bind it. Am i missing something?
Norman T.
http://blog.inlet-media.de
It’s a much lower effort resource wise. Launching another process (the
dispatcher is actually a call to another process), that then loads and
does a few things before even attempting to open the port, can’t be
compared to openning a port in one single process.
On anything but a high load site this will be a non-issue anyway. But
when you have lots of FastCGI processes, and the computer is under
load already, the difference is big.
Another way to do that is to wait on each process to see if it
finished/died with Process.wait or one of the other similar functions.
But this complicates the spawner and I didn’t see a reason after
lowering the effort enough.
Bye,
Guy.
On 3/5/06, Norman T. [email protected] wrote:
dispatcher.
print "Starting FCGI on port: #{port}\n "
There is even a disadvantage: If you test with TCPServer.new and the
http://lists.rubyonrails.org/mailman/listinfo/rails
Family management on rails: http://www.famundo.com - coming soon!
Am Sonntag, den 05.03.2006, 06:52 -0800 schrieb Just S.:
It’s a much lower effort resource wise. Launching another process (the
dispatcher is actually a call to another process), that then loads and
does a few things before even attempting to open the port, can’t be
compared to openning a port in one single process.
On anything but a high load site this will be a non-issue anyway. But
when you have lots of FastCGI processes, and the computer is under
load already, the difference is big.
You are right. I did some tests and found out that your adjustment is
about 2000-4000 times faster on my machine. Maybe you should submit a
patch and announce it on the core mailinglist.
Norman T.
http://blog.inlet-media.de