Hi Folks, I''ve got a functioning SCGI server that uses the libevent C extension I wrote recently and runs some simple ruby code. So far it''s pretty fast and works with lighttpd easily. I have yet to performance tune/measure it, but so far my little tests shows that it actually keeps up with lighttpd quite well. No comparisons to FCGI yet, but that will come soon. What I''d like to know is what you''d really want in a SCGI Rails deployment scenario that you don''t get from FCGI? Not bashing FCGI, just looking at the next generation of Rails deployment. I''m not talking things like, "It should be fast and not leak memory." I''m talking more like, "I''d like to be able to do better cluster management." Or, "I''d love to be able to set a ''closing time'' and have SCGI server tell me when everyone is finally out the door so I can restart." Or, "I''d like a control panel that told me stats." Speed and correctness will be a given, so think management, deployment, monitoring, authentication, etc. Thanks for the ideas and feedback. Zed A. Shaw http://www.zedshaw.com/
Zed, you rock. I''m beginning to be a bit of a fan of the projects you take on. On Jul 19, 2005, at 10:30 PM, Zed A. Shaw wrote:> Hi Folks, > > I''ve got a functioning SCGI server that uses the libevent C > extension I > wrote recently and runs some simple ruby code. So far it''s pretty > fast > and works with lighttpd easily. I have yet to performance tune/ > measure > it, but so far my little tests shows that it actually keeps up with > lighttpd quite well. No comparisons to FCGI yet, but that will come > soon. > > What I''d like to know is what you''d really want in a SCGI Rails > deployment scenario that you don''t get from FCGI? Not bashing FCGI, > just looking at the next generation of Rails deployment. > > I''m not talking things like, "It should be fast and not leak memory." > I''m talking more like, "I''d like to be able to do better cluster > management." Or, "I''d love to be able to set a ''closing time'' and > have > SCGI server tell me when everyone is finally out the door so I can > restart." Or, "I''d like a control panel that told me stats." > Speed and > correctness will be a given, so think management, deployment, > monitoring, authentication, etc. > > Thanks for the ideas and feedback. > > Zed A. Shaw > http://www.zedshaw.com/ > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >Duane Johnson (canadaduane)
On 7/19/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote:> What I''d like to know is what you''d really want in a SCGI Rails > deployment scenario that you don''t get from FCGI? Not bashing FCGI, > just looking at the next generation of Rails deployment.All I want from SCGI is for simpler deployment & configuration than FCGI. Eg, I want to avoid the huge redundant fcgi configuration in my lighttpd config file and have something that''s more DRY and rails-y with less configuration and more convention/implicit/automatic setup. -- Urban Artography http://artography.ath.cx
Zed A. Shaw wrote:> Hi Folks, > > I''ve got a functioning SCGI server that uses the libevent C extension I > wrote recently and runs some simple ruby code. So far it''s pretty fast > and works with lighttpd easily. I have yet to performance tune/measure > it, but so far my little tests shows that it actually keeps up with > lighttpd quite well. No comparisons to FCGI yet, but that will come > soon.Could you explain a little more how this works? (High level overview) What major benefits does SCGI bring over FCGI? Sascha
On Wed, 2005-07-20 at 11:07 +0200, Sascha Ebach wrote:> Could you explain a little more how this works? (High level overview) >Basically it works exactly the same as FCGI, but with a simpler protocol. You run a backend with your Rails application. You configure your frontend lighttpd to connect to the backend to service different URLs or extensions.> What major benefits does SCGI bring over FCGI? >SCGI doesn''t really bring any benefits over FCGI in functionality. They both do basically the exact same thing: pass HTTP requests to a persistent backend server. The main advantage of SCGI is it''s much simpler to implement, so it''s easier to get it right and use it. As for the implementation I have, I''m hoping my question will get people to tell me what they''d like in the SCGI server. Then you''ll have some major benefits that people actually need. Zed A. Shaw http://www.zedshaw.com/
Hi, I know FastCGI could be used in authorizer role, where it grants or denies access to webserver files, e.g. big static file such as movie. This feature utilization is on my future plan to provide access to spefic files only after successful login of user. I can''t find information if this scenario is possible with SCGI. Do anybody know something about it? On 7/20/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote:> > > On Wed, 2005-07-20 at 11:07 +0200, Sascha Ebach wrote: > > Could you explain a little more how this works? (High level overview) > > > Basically it works exactly the same as FCGI, but with a simpler > protocol. You run a backend with your Rails application. You configure > your frontend lighttpd to connect to the backend to service different > URLs or extensions. > > > What major benefits does SCGI bring over FCGI? > > > > SCGI doesn''t really bring any benefits over FCGI in functionality. They > both do basically the exact same thing: pass HTTP requests to a > persistent backend server. The main advantage of SCGI is it''s much > simpler to implement, so it''s easier to get it right and use it. > > As for the implementation I have, I''m hoping my question will get people > to tell me what they''d like in the SCGI server. Then you''ll have some > major benefits that people actually need. > > Zed A. Shaw > http://www.zedshaw.com/ > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Stats would be a nice-to-have feature but not a vital one. Cluster management would be more important but still not vital. Authentication - yeah, +1 to that. Near equal performance, stability and speed on Windows, Mac and Linux would be near the top of my list, second only to that nagging "I want it now!" voice in my head. I would make v1.0 just be stable and fast, and put the nice-to-have stuff in 2.0. Zed A. Shaw wrote:> Hi Folks, > > I''ve got a functioning SCGI server that uses the libevent C extension I > wrote recently and runs some simple ruby code. So far it''s pretty fast > and works with lighttpd easily. I have yet to performance tune/measure > it, but so far my little tests shows that it actually keeps up with > lighttpd quite well. No comparisons to FCGI yet, but that will come > soon. > > What I''d like to know is what you''d really want in a SCGI Rails > deployment scenario that you don''t get from FCGI? Not bashing FCGI, > just looking at the next generation of Rails deployment. > > I''m not talking things like, "It should be fast and not leak memory." > I''m talking more like, "I''d like to be able to do better cluster > management." Or, "I''d love to be able to set a ''closing time'' and have > SCGI server tell me when everyone is finally out the door so I can > restart." Or, "I''d like a control panel that told me stats." Speed and > correctness will be a given, so think management, deployment, > monitoring, authentication, etc. > > Thanks for the ideas and feedback. > > Zed A. Shaw > http://www.zedshaw.com/ > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
I''d like to see the startup/restart time faster! lighttpd/fastcgi takes a bit of time to restart, which in heavy traffic can result in a fair number of dropped (or really slow) connections On Wed, 2005-07-20 at 00:30 -0400, Zed A. Shaw wrote:> Hi Folks, > > I''ve got a functioning SCGI server that uses the libevent C extension I > wrote recently and runs some simple ruby code. So far it''s pretty fast > and works with lighttpd easily. I have yet to performance tune/measure > it, but so far my little tests shows that it actually keeps up with > lighttpd quite well. No comparisons to FCGI yet, but that will come > soon. > > What I''d like to know is what you''d really want in a SCGI Rails > deployment scenario that you don''t get from FCGI? Not bashing FCGI, > just looking at the next generation of Rails deployment. > > I''m not talking things like, "It should be fast and not leak memory." > I''m talking more like, "I''d like to be able to do better cluster > management." Or, "I''d love to be able to set a ''closing time'' and have > SCGI server tell me when everyone is finally out the door so I can > restart." Or, "I''d like a control panel that told me stats." Speed and > correctness will be a given, so think management, deployment, > monitoring, authentication, etc. > > Thanks for the ideas and feedback. > > Zed A. Shaw > http://www.zedshaw.com/ > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Thanks! Just don''t show up on my doorstep asking for autographs. :-) On Tue, 2005-07-19 at 22:43 -0600, Duane Johnson wrote:> Zed, you rock. > > I''m beginning to be a bit of a fan of the projects you take on.
I believe I''m shooting for the bare minimum on the webserver side, which seems to be the tough point for people. On the SCGI side you''d start a server (or servers) and they get accessed. I''m also looking to focus on TCP socket only configuration to further simplify things. One thing I would like in this respect is "configless clustering", where you start an SCGI instance and it requests what it needs from the webserver to get working. Anyway, keep the ideas coming. Zed On Wed, 2005-07-20 at 02:52 -0600, Rob Park wrote:> On 7/19/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote: > > What I''d like to know is what you''d really want in a SCGI Rails > > deployment scenario that you don''t get from FCGI? Not bashing FCGI, > > just looking at the next generation of Rails deployment. > > All I want from SCGI is for simpler deployment & configuration than > FCGI. Eg, I want to avoid the huge redundant fcgi configuration in my > lighttpd config file and have something that''s more DRY and rails-y > with less configuration and more convention/implicit/automatic setup. >
Looks interresting. I can imagine even more sofisticated pattern: - user requests protected file - application grants access - download start - download finishes, application is notified IMHO, this is better than timeout. Payed mp3/movie downloads, etc. But this is probably more to lighttpd mailing list. :) Maybe we could abstract this secured download rules to support both: - SCGI with those modules on lighttpd - FastCGI with authorizer role on apache and lighttpd Some default configuration file generator? On 7/21/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote:> The SCGI spec doesn''t have anything like that, but have you seen: > > http://www.lighttpd.net/documentation/secdownload.html > http://www.lighttpd.net/documentation/trigger_b4_dl.html > > Which kind of do the same thing. I was thinking, maybe a bit more > generic solution would be if the Rails app can add a header which any > webserver can interpret to implement the above. > > What do you think? > > Zed > > On Wed, 2005-07-20 at 15:30 +0200, Rastislav Kassak wrote: > > Hi, > > > > I know FastCGI could be used in authorizer role, where it grants or > > denies access to webserver files, e.g. big static file such as movie. > > This feature utilization is on my future plan to provide access to > > spefic files only after successful login of user. > > > > I can''t find information if this scenario is possible with SCGI. > > Do anybody know something about it? > > > >
I''d like to see the following: - a simple, idiot-proof install process for Windows and Linux. Although some have got it working, it''s obviously a problem for many people using Rails/FCGI today - a reasonable default configuration, so it could be gotten up and going with minimal thought required. BTW, this is one area where Postgres really lags behind MySQL, and I think it''s a big part of the reason why MySQL is so popular. Maybe have a "development" (i.e. minimal resources used) and a "production" default config, which can be manually tweaked by those in the know but will work OK for 90%+ of everyone else Dave M. On 7/21/05, Rastislav Kassak <kasou.sk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Looks interresting. > I can imagine even more sofisticated pattern: > - user requests protected file > - application grants access > - download start > - download finishes, application is notified > IMHO, this is better than timeout. Payed mp3/movie downloads, etc. > But this is probably more to lighttpd mailing list. :) > > > Maybe we could abstract this secured download rules to support both: > - SCGI with those modules on lighttpd > - FastCGI with authorizer role on apache and lighttpd > Some default configuration file generator? > > > On 7/21/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote: > > The SCGI spec doesn''t have anything like that, but have you seen: > > > > http://www.lighttpd.net/documentation/secdownload.html > > http://www.lighttpd.net/documentation/trigger_b4_dl.html > > > > Which kind of do the same thing. I was thinking, maybe a bit more > > generic solution would be if the Rails app can add a header which any > > webserver can interpret to implement the above. > > > > What do you think? > > > > Zed > > > > On Wed, 2005-07-20 at 15:30 +0200, Rastislav Kassak wrote: > > > Hi, > > > > > > I know FastCGI could be used in authorizer role, where it grants or > > > denies access to webserver files, e.g. big static file such as movie. > > > This feature utilization is on my future plan to provide access to > > > spefic files only after successful login of user. > > > > > > I can''t find information if this scenario is possible with SCGI. > > > Do anybody know something about it? > > > > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I love the configless clustering idea. Round-robin SCGI? On 7/21/05, David Mitchell <monch1962-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I''d like to see the following: > - a simple, idiot-proof install process for Windows and Linux. > Although some have got it working, it''s obviously a problem for many > people using Rails/FCGI today > - a reasonable default configuration, so it could be gotten up and > going with minimal thought required. BTW, this is one area where > Postgres really lags behind MySQL, and I think it''s a big part of the > reason why MySQL is so popular. Maybe have a "development" (i.e. > minimal resources used) and a "production" default config, which can > be manually tweaked by those in the know but will work OK for 90%+ of > everyone else > > Dave M. > > On 7/21/05, Rastislav Kassak <kasou.sk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Looks interresting. > > I can imagine even more sofisticated pattern: > > - user requests protected file > > - application grants access > > - download start > > - download finishes, application is notified > > IMHO, this is better than timeout. Payed mp3/movie downloads, etc. > > But this is probably more to lighttpd mailing list. :) > > > > > > Maybe we could abstract this secured download rules to support both: > > - SCGI with those modules on lighttpd > > - FastCGI with authorizer role on apache and lighttpd > > Some default configuration file generator? > > > > > > On 7/21/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote: > > > The SCGI spec doesn''t have anything like that, but have you seen: > > > > > > http://www.lighttpd.net/documentation/secdownload.html > > > http://www.lighttpd.net/documentation/trigger_b4_dl.html > > > > > > Which kind of do the same thing. I was thinking, maybe a bit more > > > generic solution would be if the Rails app can add a header which any > > > webserver can interpret to implement the above. > > > > > > What do you think? > > > > > > Zed > > > > > > On Wed, 2005-07-20 at 15:30 +0200, Rastislav Kassak wrote: > > > > Hi, > > > > > > > > I know FastCGI could be used in authorizer role, where it grants or > > > > denies access to webserver files, e.g. big static file such as movie. > > > > This feature utilization is on my future plan to provide access to > > > > spefic files only after successful login of user. > > > > > > > > I can''t find information if this scenario is possible with SCGI. > > > > Do anybody know something about it? > > > > > > > > > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Hello, Looks great. I also saw your alpha announcement. Congrats and thanks. Question and a couple thoughts. Forgive if any of the below is FAQ. I am working through the Pickaxe2 right now. I haven''t touched the Rails book pdf yet. You mention clustering. I don''t know how Rails currently handles multiple processor machines right now if it does at all. But when you speak of clustering would that simply mean across machines? Or would that enable spreading Rails across processors also? In your alpha email you state 1 scgi server. Does that mean 1 ruby process? If I remember correctly the Quixote guys, (the ones behind SCGI), in their Quixote scgi deployment have management of children processes to allow/enable spreading Quixote across multiple processes and therefore processors. Is any such in your mind? Does Rails current use of FCGI limit Ruby/Rails to a single ruby instance? I know some of this might become somewhat moot with a native-threading YARV and updated Rails. But thats not today. :) Another thought/question. Would any of this enable the creation of another Rails instance on a machine for development of future website(s) and updates to website(s)? That way the stable version is untouched, but development proceeds. I am not a professional web developer so I do not know what Rails best practices are concerning such. Thanks again. Jimmie
On Jul 20, 2005, at 9:37 PM, Zed A. Shaw wrote:> I believe I''m shooting for the bare minimum on the webserver side, > which > seems to be the tough point for people. On the SCGI side you''d > start a > server (or servers) and they get accessed. I''m also looking to > focus on > TCP socket only configuration to further simplify things. > > One thing I would like in this respect is "configless clustering", > where > you start an SCGI instance and it requests what it needs from the > webserver to get working.Consider using a zeroconf based config by default (overrideable to specific hosts) so that it is literally -- start server with a group name: scgi_server "wombats" which apache is configured to look for via zeroconf: SCGIClient wombats Have a pool of clients in the scoreboard which can be dynamically modified (hence pool) and let it rip. Gets more fun if the scgi_server uses a prefork child process pooling strategy as well. You can load balance based on server pool size, and all of this is discoverable at runtime rather than in the config -- assuming reasonable defaults for number of children on the scgi_server instance. Just my 2 cents. -Brian> > Anyway, keep the ideas coming. > > Zed > > On Wed, 2005-07-20 at 02:52 -0600, Rob Park wrote: > >> On 7/19/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote: >> >>> What I''d like to know is what you''d really want in a SCGI Rails >>> deployment scenario that you don''t get from FCGI? Not bashing FCGI, >>> just looking at the next generation of Rails deployment. >>> >> >> All I want from SCGI is for simpler deployment & configuration than >> FCGI. Eg, I want to avoid the huge redundant fcgi configuration in my >> lighttpd config file and have something that''s more DRY and rails-y >> with less configuration and more convention/implicit/automatic setup. >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >
zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org
2005-Jul-25 22:08 UTC
Re: Re: SCGI wish list?
> Hello, > > Looks great. I also saw your alpha announcement. > Congrats and thanks. >Yeah, there''s a small bug in that release, so you might want to wait. Didn''t find it until I used it at work today. I''ll be posting an official release tonight. <snip>> > You mention clustering. I don''t know how Rails currently handles > multiple processor machines right now if it does at all. But when you > speak of clustering would that simply mean across machines? Or would > that enable spreading Rails across processors also? >The "clustering" I''m aiming for is very simple. You start lots of SCGI servers with your Rails app in them. You tell your web server where they are. Web server hits them. Whether you run 10 on one 10-processor machine, or 10 on 10 one-processor machines is your biz.> In your alpha email you state 1 scgi server. Does that mean 1 ruby > process? If I remember correctly the Quixote guys, (the ones behind > SCGI), in their Quixote scgi deployment have management of children > processes to allow/enable spreading Quixote across multiple processes > and therefore processors. >One ruby process running separately from the lighttpd process (i.e. lighttpd didn''t start it the way it usually starts dispatch.fcgi). I''m aware of what the other SCGI folks did (including Quixote) but not intimately familiar with it. I''m probably going to delve into how other SCGI systems set things up to find the best practices, and then try to get them working the Rails way. One thing I do disagree with in general is "auto child spawning". This makes it really hard to do capacity planning and usually ends up causing more trouble than its worth. I''m hoping to figure out a balance between having to explicitly configure the world, and having some unseen force magically start things you didn''t ask be started.> Is any such in your mind? > Does Rails current use of FCGI limit Ruby/Rails to a single ruby instance? >Nope, Rails can run tons of FCGI ruby instances. In the usual usage people configure their lighttpd to spawn them up, but I''ve heard people having major problems with that too.> I know some of this might become somewhat moot with a native-threading > YARV and updated Rails. But thats not today. :) >Actually, native-threading doesn''t improve the performance of network systems. For a really good explanation as to why this is refer to: http://www.kegel.com/c10k.html> > Another thought/question. > > Would any of this enable the creation of another Rails instance on a > machine for development of future website(s) and updates to website(s)? > That way the stable version is untouched, but development proceeds. > I am not a professional web developer so I do not know what Rails best > practices are concerning such. >That''s what I do. I have one running that''s production and one that''s development. I monkey around with the development, and when it''s done I kick over the production with the new code. If you want to do both prod/dev in one directory while you''re hacking at code then you should go see a therapist. Otherwise running more than one SCGI server on the same machine is very easy.
I''m assuming you mean http://www.zeroconf.org/ when you say "zeroconf" The problem with zeroconf is it requires an ass-load of external dependencies and is really damn complex to get working. All my experience with zeroconf required modifying the DNS, running special DNS servers, changing routers, and installing specialized libraries to use them all. This was a while back, but it still haunts me to this day. Only the Bonjour Apple people have it easy. While I''m totally into zeroconf, one big request that people have with SCGI is that "it should just work without tons of external crap". Currently people have huge problems getting fcgi installed because of this, so I''m trying to keep everything very self contained. Now, what would be very possible is using Ruby''s Linda and/or DRb to emulate zeroconf. I was contemplating that, but at first I think I want to get the thing working before I get into wild cluster stuffs. Thanks for the comments though. I know "simple clustering" is a big request for many people. Zed> Consider using a zeroconf based config by default (overrideable to > specific hosts) so that it is literally -- start server with a group > name: > > scgi_server "wombats" > > which apache is configured to look for via zeroconf: > > SCGIClient wombats > > Have a pool of clients in the scoreboard which can be dynamically > modified (hence pool) and let it rip. > > Gets more fun if the scgi_server uses a prefork child process pooling > strategy as well. You can load balance based on server pool size, and > all of this is discoverable at runtime rather than in the config -- > assuming reasonable defaults for number of children on the > scgi_server instance. > > Just my 2 cents. > > -Brian >
Zed- I''m not going to pretend to be able to read Brian''s mind, but it seems to me that what he''s hoping for (and this would be really cool) would be some solution that leveraged Multicast DNS. If it was designed correctly (as Apple did with Bonjour), it wouldn''t need anything in the way of external dependencies, but it would require some extra work on the developers side. At my day job (sadly web/Rails stuff is still sidework for me) at Jabber, Inc., we recently started using a MDNS-based solution to add dynamic scalability to our product line. The basic theory is that you''d have some sort of main process that would be a dispatcher that would round-robin through handlers that could be brought up when necessary and automatically register themselves with the dispatcher by simply sending out a MDNS notification. There are obvious security issues to deal with in this scenario in a shared hosting environment, but for an environment dedicated to your services, this would provide quick and easy scalability. The advantages are that rather than having to pre-configure the dispatcher to know about all the handlers, the handlers can register themselves to the dispatcher when they come online. This would make it possible for an administrator to simply purchase a new box, install the software from a disc image, boot it up and have another handler that could share the load. You''d almost certainly want to provide the ability to have multiple dispatchers to provide greater realiability and fail-over and again, they would simply register themselves with each other and the handlers via MDNS. I really think this idea has some wheels to it. It really intrigues me... (plus I just think it''d be fun). Maybe I''ll take a look at your existing SCGI code tonight and see if I can''t prototype something along these lines. Not sure I''ll be able to get much done in the next couple days, but I''m really curious now. Hope my rambling isn''t too far off in the woods... Cheers, Ben On 7/25/05, zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote:> I''m assuming you mean http://www.zeroconf.org/ when you say "zeroconf" > > The problem with zeroconf is it requires an ass-load of external > dependencies and is really damn complex to get working. All my experience > with zeroconf required modifying the DNS, running special DNS servers, > changing routers, and installing specialized libraries to use them all. > This was a while back, but it still haunts me to this day. Only the > Bonjour Apple people have it easy. > > While I''m totally into zeroconf, one big request that people have with > SCGI is that "it should just work without tons of external crap". > Currently people have huge problems getting fcgi installed because of > this, so I''m trying to keep everything very self contained. > > Now, what would be very possible is using Ruby''s Linda and/or DRb to > emulate zeroconf. I was contemplating that, but at first I think I want > to get the thing working before I get into wild cluster stuffs. > > Thanks for the comments though. I know "simple clustering" is a big > request for many people. > > Zed > > > Consider using a zeroconf based config by default (overrideable to > > specific hosts) so that it is literally -- start server with a group > > name: > > > > scgi_server "wombats" > > > > which apache is configured to look for via zeroconf: > > > > SCGIClient wombats > > > > Have a pool of clients in the scoreboard which can be dynamically > > modified (hence pool) and let it rip. > > > > Gets more fun if the scgi_server uses a prefork child process pooling > > strategy as well. You can load balance based on server pool size, and > > all of this is discoverable at runtime rather than in the config -- > > assuming reasonable defaults for number of children on the > > scgi_server instance. > > > > Just my 2 cents. > > > > -Brian > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Jul 25, 2005, at 6:54 PM, Ben Schumacher wrote:> Zed- > > I''m not going to pretend to be able to read Brian''s mind, but it seems > to me that what he''s hoping for (and this would be really cool) would > be some solution that leveraged Multicast DNS. If it was designed > correctly (as Apple did with Bonjour), it wouldn''t need anything in > the way of external dependencies, but it would require some extra work > on the developers side.Yep, that is exactly it. A simpler udp multicast might be easier, and not introduce dependencies on as many third party libraries. For a multicast announcement based system, you should be able to get by with a broadcast announcement at startup, then simply responding to matching broadcasts as they occur (ie, server announces itself at startup, then simply pong''s when a new client comes up and makes its announcement -- and vice versa).> At my day job (sadly web/Rails stuff is still sidework for me) at > Jabber, Inc., we recently started using a MDNS-based solution to add > dynamic scalability to our product line. The basic theory is that > you''d have some sort of main process that would be a dispatcher that > would round-robin through handlers that could be brought up when > necessary and automatically register themselves with the dispatcher by > simply sending out a MDNS notification. There are obvious security > issues to deal with in this scenario in a shared hosting environment, > but for an environment dedicated to your services, this would provide > quick and easy scalability.Yep, though even that is reasonably -- multicast can is named, and the broadcast name can be a hash, then the same name (as it is a shared secret) can be a key for wrapping the SCGI protocol in an encryption layer. This is grossly overkill for an initial version, but could be relevant in a hosting environment as you could do on- demand upscaling, or sell insurance on traffic spikes (if traffic increases, we''ll allocate additional processes to you until traffic winds down -- slashdot insurance). The app would need to be deployed to this, but that kind of deployment is pretty much a solved problem -- particularly if it is a rails-specific hosting situation. I digress, however =)> The advantages are that rather than having to pre-configure the > dispatcher to know about all the handlers, the handlers can register > themselves to the dispatcher when they come online. This would make it > possible for an administrator to simply purchase a new box, install > the software from a disc image, boot it up and have another handler > that could share the load. You''d almost certainly want to provide the > ability to have multiple dispatchers to provide greater realiability > and fail-over and again, they would simply register themselves with > each other and the handlers via MDNS.I would suggest a name other than Dispatcher, the overloaded meaning in rails world will make us all hurt down the line =) The ability to slap a disc image in the drive, or even better netboot, to add capacity which is discovered is really kind of nice.> I really think this idea has some wheels to it. It really intrigues > me... (plus I just think it''d be fun).I agree. I think Zed''s work is aimed at lighttpd, I''d prefer to make it all play nicely with the Apache web server -- lighttpd rocks, but Apache has way more functionality still. Lighttpd is a scalpel -- perfect for what it does, whereas apache is more of a swiss army chainsaw, which is pretty useful. The nice part is that it is all protocol, the scgi server will communicate however it likes, and if a discover protocol can be specced, then you can mix and match the environment! Is SCGi using APR at present? Just thinking about that from a cross- platform POV (also a nice network abstraction for multicast, but no biggie). I looked over the SCGI protocol, it really is nice and simple. Another thing to consider, if we''re looking at writing something of any size, is AJP13 -- the Apache JServ Protocol. Before you fall over laughing, it is simply an optimized HTTP, much like SCGI, except with some additional hooks for playing nicely as an app server deployment and control protocol. The reason for considering it is that there is a lot of really nice stuff for proxying and load balancing in apache 2 and way nicer stuff coming up in apache 2.2 for it with mod_proxy_balancer. The protocol is much more complicated than SCGI, however. 1.3 is in fact horrendous -- the protocol spec is derived from the implementation. 1.4 cleans up the protocol a lot, but is under development, not actually released. So... SCGI is probably the way to go. Keeping some protocol abstraction in the back of the mind may be a good idea though. -Brian ps: you realize we are really talking about a ruby/rails app server model?> Maybe I''ll take a look at your existing SCGI code tonight and see if I > can''t prototype something along these lines. Not sure I''ll be able to > get much done in the next couple days, but I''m really curious now. > > Hope my rambling isn''t too far off in the woods... > > Cheers, > > Ben > > On 7/25/05, zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote: > >> I''m assuming you mean http://www.zeroconf.org/ when you say >> "zeroconf" >> >> The problem with zeroconf is it requires an ass-load of external >> dependencies and is really damn complex to get working. All my >> experience >> with zeroconf required modifying the DNS, running special DNS >> servers, >> changing routers, and installing specialized libraries to use them >> all. >> This was a while back, but it still haunts me to this day. Only the >> Bonjour Apple people have it easy. >> >> While I''m totally into zeroconf, one big request that people have >> with >> SCGI is that "it should just work without tons of external crap". >> Currently people have huge problems getting fcgi installed because of >> this, so I''m trying to keep everything very self contained. >> >> Now, what would be very possible is using Ruby''s Linda and/or DRb to >> emulate zeroconf. I was contemplating that, but at first I think >> I want >> to get the thing working before I get into wild cluster stuffs. >> >> Thanks for the comments though. I know "simple clustering" is a big >> request for many people. >> >> Zed >> >> >>> Consider using a zeroconf based config by default (overrideable to >>> specific hosts) so that it is literally -- start server with a group >>> name: >>> >>> scgi_server "wombats" >>> >>> which apache is configured to look for via zeroconf: >>> >>> SCGIClient wombats >>> >>> Have a pool of clients in the scoreboard which can be dynamically >>> modified (hence pool) and let it rip. >>> >>> Gets more fun if the scgi_server uses a prefork child process >>> pooling >>> strategy as well. You can load balance based on server pool size, >>> and >>> all of this is discoverable at runtime rather than in the config -- >>> assuming reasonable defaults for number of children on the >>> scgi_server instance. >>> >>> Just my 2 cents. >>> >>> -Brian >>> >>> >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >
I''d say this is all dandy, but before you can run you have to walk. So, let me get the damn thing working well in the simple case, then let''s see if this is doable. Some comments below though... On Mon, 2005-07-25 at 20:36 -0400, Brian McCallister wrote:> On Jul 25, 2005, at 6:54 PM, Ben Schumacher wrote:<snip>> > I really think this idea has some wheels to it. It really intrigues > > me... (plus I just think it''d be fun). > > I agree. I think Zed''s work is aimed at lighttpd, I''d prefer to make > it all play nicely with the Apache web server -- lighttpd rocks, but > Apache has way more functionality still. <snip>Nope, it works with Apache, lighttpd, or anything that does SCGI. I specifically made sure that it starts up independent of the fronting web server. The main reason why is I need to do a Java based connector for this, so I can''t depend on any particular server.> Is SCGi using APR at present? Just thinking about that from a cross- > platform POV (also a nice network abstraction for multicast, but no > biggie). I looked over the SCGI protocol, it really is nice and simple.Are you asking if what I wrote is using APR or whether the Apache mod is using APR? I don''t know for the Apache mod, but for my stuff it''s just a thin layer around libevent. Should be super portable, but I have yet to test this theory. See above for why APR in this project is a really bad idea.> Another thing to consider, if we''re looking at writing something of > any size, is AJP13 -- the Apache JServ Protocol. Before you fall over > laughing, it is simply an optimized HTTP, much like SCGI, except with > some additional hooks for playing nicely as an app server deployment > and control protocol. The reason for considering it is that there is > a lot of really nice stuff for proxying and load balancing in apache > 2 and way nicer stuff coming up in apache 2.2 for it with > mod_proxy_balancer. The protocol is much more complicated than SCGI, > however. 1.3 is in fact horrendous -- the protocol spec is derived > from the implementation. 1.4 cleans up the protocol a lot, but is > under development, not actually released. So... SCGI is probably the > way to go. Keeping some protocol abstraction in the back of the mind > may be a good idea though. >Yikes Brian, how much time do you think I have? :-) Seriously, there are much simpler ways to do the same thing. Also, my experience with the proxying and load balancing tools you mentioned are very different. I found them over-engineered, complicated to implement, and not even close to the hype they''re given. Give me pound (http://www.apsis.ch/pound/) or a hardware solution any day.> -Brian > > ps: you realize we are really talking about a ruby/rails app server > model? >Sshhhh! Don''t tell the Rails folks that. The second you say "app server" they''ll start screaming, "Oh my god! It''s the ENTERPRISE ariseth. Run for your lives!" :-) Zed
Yep, I should be releasing this again tonight to cover a bug and to get some docs up. Feel free to take a look at it. It''s very small, just one script for the whole thing. First though, I''d like to get it working for the common case of simple setup and then go from there. Zed On Mon, 2005-07-25 at 16:54 -0600, Ben Schumacher wrote:> Zed-<snip>> I really think this idea has some wheels to it. It really intrigues > me... (plus I just think it''d be fun). > > Maybe I''ll take a look at your existing SCGI code tonight and see if I > can''t prototype something along these lines. Not sure I''ll be able to > get much done in the next couple days, but I''m really curious now. > > Hope my rambling isn''t too far off in the woods... > > Cheers, > > Ben > > On 7/25/05, zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote: > > I''m assuming you mean http://www.zeroconf.org/ when you say "zeroconf" > > <snip>> > > Consider using a zeroconf based config by default (overrideable to > > > specific hosts) so that it is literally -- start server with a group > > > name: > > > <snip>
> Sshhhh! Don''t tell the Rails folks that. The second you say "app > server" they''ll start screaming, "Oh my god! It''s the ENTERPRISE > ariseth. Run for your lives!" :-)That''s it, you''re outta here. ;) -- Cheers Koz
On Jul 25, 2005, at 10:15 PM, Zed A. Shaw wrote:> I''d say this is all dandy, but before you can run you have to > walk. So, > let me get the damn thing working well in the simple case, then let''s > see if this is doable. Some comments below though...Yep, just wandering off into idea land, definitely not asking for a "do it now!" =) -Brian> > On Mon, 2005-07-25 at 20:36 -0400, Brian McCallister wrote: > >> On Jul 25, 2005, at 6:54 PM, Ben Schumacher wrote: >> > <snip> > > >>> I really think this idea has some wheels to it. It really intrigues >>> me... (plus I just think it''d be fun). >>> >> >> I agree. I think Zed''s work is aimed at lighttpd, I''d prefer to make >> it all play nicely with the Apache web server -- lighttpd rocks, but >> Apache has way more functionality still. <snip> >> > > Nope, it works with Apache, lighttpd, or anything that does SCGI. I > specifically made sure that it starts up independent of the > fronting web > server. > > The main reason why is I need to do a Java based connector for > this, so > I can''t depend on any particular server. > > > >> Is SCGi using APR at present? Just thinking about that from a cross- >> platform POV (also a nice network abstraction for multicast, but no >> biggie). I looked over the SCGI protocol, it really is nice and >> simple. >> > > Are you asking if what I wrote is using APR or whether the Apache > mod is > using APR? I don''t know for the Apache mod, but for my stuff it''s > just > a thin layer around libevent. Should be super portable, but I have > yet > to test this theory. See above for why APR in this project is a > really > bad idea. > > >> Another thing to consider, if we''re looking at writing something of >> any size, is AJP13 -- the Apache JServ Protocol. Before you fall over >> laughing, it is simply an optimized HTTP, much like SCGI, except with >> some additional hooks for playing nicely as an app server deployment >> and control protocol. The reason for considering it is that there is >> a lot of really nice stuff for proxying and load balancing in apache >> 2 and way nicer stuff coming up in apache 2.2 for it with >> mod_proxy_balancer. The protocol is much more complicated than SCGI, >> however. 1.3 is in fact horrendous -- the protocol spec is derived >> from the implementation. 1.4 cleans up the protocol a lot, but is >> under development, not actually released. So... SCGI is probably the >> way to go. Keeping some protocol abstraction in the back of the mind >> may be a good idea though. >> >> > > Yikes Brian, how much time do you think I have? :-) Seriously, there > are much simpler ways to do the same thing. Also, my experience with > the proxying and load balancing tools you mentioned are very > different. > I found them over-engineered, complicated to implement, and not even > close to the hype they''re given. Give me pound > (http://www.apsis.ch/pound/) or a hardware solution any day. > > >> -Brian >> >> ps: you realize we are really talking about a ruby/rails app server >> model? >> >> > > Sshhhh! Don''t tell the Rails folks that. The second you say "app > server" they''ll start screaming, "Oh my god! It''s the ENTERPRISE > ariseth. Run for your lives!" :-) > > Zed > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >
> One thing I do disagree with in general is "auto child spawning". This > makes it really hard to do capacity planning and usually ends up causing > more trouble than its worth. I''m hoping to figure out a balance between > having to explicitly configure the world, and having some unseen force > magically start things you didn''t ask be started.I agree. Auto-spawning, especially using lower and higher bounds, works like crap in my experience. It''s buggy, unpredictive, and not all that helpful. But at the same time, it''s painful to manage FCGIs by hand without any help. THUS! I''ve added script/process, which includes reaper, spawner, and spinner. Three small tools to make managing external FCGIs much more pleasant. With the help of these tools, I dare say that it''s easier to manage external FCGIs than internal ones. And you can restart your web server without causing the FCGIs to restart. And of course run 3 apps with 5 FCGIs each on the same web server and then only restart 1 app (with 5 FCGIs) without monkeying with either web server or the other apps. Naturally, we''d want to make these tools work with SCGIs too. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework