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 Someone:> 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 > endI 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 Timmler 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 Timmler <lists@inlet-media.de> wrote:> Am Sonntag, den 05.03.2006, 02:21 -0800 schrieb Just Someone: > > 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 > > 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 Timmler > > http://blog.inlet-media.de > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > 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 Someone:> 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 Timmler http://blog.inlet-media.de
Norman Timmler wrote:> Am Sonntag, den 05.03.2006, 06:52 -0800 schrieb Just Someone: >> 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.Yes, please do. -- Posted via http://www.ruby-forum.com/.
I''ll post a patch in trac. On 3/5/06, Andreas S. <f@andreas-s.net> wrote:> Norman Timmler wrote: > > Am Sonntag, den 05.03.2006, 06:52 -0800 schrieb Just Someone: > >> 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. > > Yes, please do. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Family management on rails: http://www.famundo.com - coming soon!