# A nicer and gentler form of spawner **URL:** \ **Category:** Rails\ **Created:** [March 5, 2006, 11:23am UTC](https://www.ruby-forum.com/t/a-nicer-and-gentler-form-of-spawner/76895 "2006-03-05T11:23:32Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![justsomeone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7ea924/32.png) [@justsomeone](https://www.ruby-forum.com/u/justsomeone)\ **Post date:** [March 5, 2006, 11:23am UTC](https://www.ruby-forum.com/t/a-nicer-and-gentler-form-of-spawner/76895/1 "2006-03-05T11:23:32Z")
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/](http://devblog.famundo.com/) Bye, Guy Family management on rails: [http://www.famundo.com](http://www.famundo.com) - coming soon! ---
**Author:** ![justsomeone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7ea924/32.png) [@justsomeone](https://www.ruby-forum.com/u/justsomeone)\ **Post date:** [March 5, 2006, 3:31pm UTC](https://www.ruby-forum.com/t/a-nicer-and-gentler-form-of-spawner/76895/2 "2006-03-05T15:31:45Z")
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](http://blog.inlet-media.de) ---
**Author:** ![justsomeone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7ea924/32.png) [@justsomeone](https://www.ruby-forum.com/u/justsomeone)\ **Post date:** [March 5, 2006, 3:53pm UTC](https://www.ruby-forum.com/t/a-nicer-and-gentler-form-of-spawner/76895/3 "2006-03-05T15:53:03Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](http://lists.rubyonrails.org/mailman/listinfo/rails) Family management on rails: [http://www.famundo.com](http://www.famundo.com) - coming soon! ---
**Author:** ![justsomeone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7ea924/32.png) [@justsomeone](https://www.ruby-forum.com/u/justsomeone)\ **Post date:** [March 5, 2006, 4:26pm UTC](https://www.ruby-forum.com/t/a-nicer-and-gentler-form-of-spawner/76895/4 "2006-03-05T16:26:37Z")
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](http://blog.inlet-media.de) ---
**Author:** ![justsomeone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7ea924/32.png) [@justsomeone](https://www.ruby-forum.com/u/justsomeone)\ **Post date:** [March 5, 2006, 6:00pm UTC](https://www.ruby-forum.com/t/a-nicer-and-gentler-form-of-spawner/76895/5 "2006-03-05T18:00:31Z")
I’ll post a patch in trac. On 3/5/06, Andreas S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > > removed\_email\_address@domain.invalid > [http://lists.rubyonrails.org/mailman/listinfo/rails](http://lists.rubyonrails.org/mailman/listinfo/rails) – Family management on rails: [http://www.famundo.com](http://www.famundo.com) - coming soon! ---
**Author:** ![justsomeone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7ea924/32.png) [@justsomeone](https://www.ruby-forum.com/u/justsomeone)\ **Post date:** [March 5, 2006, 4:51pm UTC](https://www.ruby-forum.com/t/a-nicer-and-gentler-form-of-spawner/76895/6 "2006-03-05T16:51:12Z")
Norman T. wrote: > 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. Yes, please do.