Can anyone give me a short list of well known, high traffic sites that use the horizontal, more hardware, type of scaling that Rails would be use? (Sorry, can''t go for "cool" like basecamp, need well known high volume.) I''d like to "quiet" some Rails'' detractors at my office who seem to be hell-bent on bleating out ad nauseum this "Rails doesn''t scale, CGI is for kids" type dogma. As this is probably OT, offline responses welcome. Thanks.
If CGI is their problem (not Rails itself) you''ll have a much better time pointing to higher-volume sites, IMO. On Jul 13, 2005, at 5:48 PM, Michael Campbell wrote:> Can anyone give me a short list of well known, high traffic sites that > use the horizontal, more hardware, type of scaling that Rails would be > use? (Sorry, can''t go for "cool" like basecamp, need well known high > volume.) > > I''d like to "quiet" some Rails'' detractors at my office who seem to be > hell-bent on bleating out ad nauseum this "Rails doesn''t scale, CGI is > for kids" type dogma. > > As this is probably OT, offline responses welcome. > > Thanks. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
That might be what I''m asking for; to be honest, I''m not sure. Since THEY are not exactly sure either... But I think the problem is rails uses a CGI model, and CGI is "so 90''s", it''s not scaleable by their definition. I want some concrete counter evidence; ebay? Google? Yahoo? I''m not sure what any of them use, so I''d like to know one way or the other. On 7/13/05, Toby Boudreaux <rails-lb8SQxIZKShBDgjK7y7TUQ@public.gmane.org> wrote:> If CGI is their problem (not Rails itself) you''ll have a much better > time pointing to higher-volume sites, IMO. > > > On Jul 13, 2005, at 5:48 PM, Michael Campbell wrote: > > > Can anyone give me a short list of well known, high traffic sites that > > use the horizontal, more hardware, type of scaling that Rails would be > > use? (Sorry, can''t go for "cool" like basecamp, need well known high > > volume.) > > > > I''d like to "quiet" some Rails'' detractors at my office who seem to be > > hell-bent on bleating out ad nauseum this "Rails doesn''t scale, CGI is > > for kids" type dogma. > > > > As this is probably OT, offline responses welcome. > > > > Thanks. > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > >
Right, what is the crux of their complaint? They do realize that massive volume sites like Slashdot, Yahoo, and so on use Perl and PHP (respetively), and are really no different than Rails. Or, maybe reading between the lines: these sites are not done with Java :) eBay I believe does use Java. Google I think is a mix of Java and Python. It seems that if they themselves can only come up with a "CGI is bad" kind of argument, but can''t really back it, that that''s your response right there... On 7/13/05 2:53 PM, "Michael Campbell" <michael.campbell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> That might be what I''m asking for; to be honest, I''m not sure. Since > THEY are not exactly sure either... But I think the problem is rails > uses a CGI model, and CGI is "so 90''s", it''s not scaleable by their > definition. > > I want some concrete counter evidence; ebay? Google? Yahoo? I''m not > sure what any of them use, so I''d like to know one way or the other. > > > On 7/13/05, Toby Boudreaux <rails-lb8SQxIZKShBDgjK7y7TUQ@public.gmane.org> wrote: >> If CGI is their problem (not Rails itself) you''ll have a much better >> time pointing to higher-volume sites, IMO. >> >> >> On Jul 13, 2005, at 5:48 PM, Michael Campbell wrote: >> >>> Can anyone give me a short list of well known, high traffic sites that >>> use the horizontal, more hardware, type of scaling that Rails would be >>> use? (Sorry, can''t go for "cool" like basecamp, need well known high >>> volume.) >>> >>> I''d like to "quiet" some Rails'' detractors at my office who seem to be >>> hell-bent on bleating out ad nauseum this "Rails doesn''t scale, CGI is >>> for kids" type dogma. >>> >>> As this is probably OT, offline responses welcome. >>> >>> Thanks. >>> _______________________________________________ >>> 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
google, ebay, amazon, yahoo, blogger and life journal should convince them. The share nothing, horizontal approach to scaling is by far the most popular. CGI is useless but FastCGI is great tech On 7/13/05, Michael Campbell <michael.campbell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Can anyone give me a short list of well known, high traffic sites that > use the horizontal, more hardware, type of scaling that Rails would be > use? (Sorry, can''t go for "cool" like basecamp, need well known high > volume.) > > I''d like to "quiet" some Rails'' detractors at my office who seem to be > hell-bent on bleating out ad nauseum this "Rails doesn''t scale, CGI is > for kids" type dogma. > > As this is probably OT, offline responses welcome. > > Thanks. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
On 7/14/05, Christopher Bailey <chris-yzaz/rx7IpEXSVZzYpeOkQC/G2K4zDHf@public.gmane.org> wrote:> Right, what is the crux of their complaint? They do realize that massive > volume sites like Slashdot, Yahoo, and so on use Perl and PHP (respetively), > and are really no different than Rails. Or, maybe reading between the > lines: these sites are not done with Java :) eBay I believe does use Java. > Google I think is a mix of Java and Python.Yeah, Ebay is Java, Amazon is C++, Dell is ASP.NET, livejournal is perl (more than 5 times the load of slashdot). Livejournal used fastcgi the last time they presented their architecture (danga.com/words) and check the archives for another mention of a large chineses portal using fastcgi. Anyone who thinks that language is the problem is, to put it somewhat bluntly, an idiot. If livejournal can do 4000 hits per second on perl, your coworkers can do their apps in whatever they want. -- Cheers Koz
* Tobias Luetke [2005-07-13 18:00]:> google, ebay, amazon, yahoo, blogger and life journal should convince them. > The share nothing, horizontal approach to scaling is by far the most popular. > > CGI is useless but FastCGI is great tech >I think FastCGI needs to be rebranded, i.e. DHTML -> AJAX. Pisses off lots of tech people, but works damn well (rebranding that is). -- ________________________________ toddgrimason*todd[ at ]slack.net
Lots of programmers have "performance obsession" and the first question they ask is "how fast is it?". These same programmers are the time wasters on software projects who instead of implementing a simple, easy to maintain and understandable solution that might not be lightning fast, are so performance obsessed that they always spend far more time implementing complex, difficult to understand and maintain "high performance" features, proving how smart they are, puzzling their peers, setting back the schedule and reducing the maintainability and reliability. All this to make the application a little bit faster when it possibly didn''t need to be any faster in that area. "Speed", "performance", "scalability" is their foolish mantra. How many applications being built in the corporate world need Yahoo/Google/Slashdot/microsoft.com level performance? Probably not many. The performance obsessed programmers who think speed is the first and primary issue have usually never project managed or acted as a development team lead or had any responsibility for the project outcomes. In most cases a far more important question than "how fast is it?" is "how simple is it?" - "how productive will the developrs be with this technology". Give me a simple solution that''s fast enough any time over a complex solution that is more than fast enough. The best question is is this technology fast enough for "what we need?" where "what we need" = varying degrees and priorities of maintainability reliability expected lifetime of software disk/memory footprint compliance with corporate standards suitability of software licence cost expertise of development resources match with operational and implementation environment availability of documentation for technology ability to integrate with existing systems ability to implement specific application requirements time to market/completion defined level of reliability oh, and performance too If there are performance issues, first profile them, measure them, optimise them and then finally hit them with the hardware hammer and see if they go away. The most critical point about performance arguments in my experience as that they are almost always agrued without any quantifiable numbers at all - no-one bothers to profile or run apachebench to discuss the issue with true numbers. I ran performance tests on fastcgi whwne I first looked at rails to understand "is this fast enough" and I do recall that for dirt-simple fastcgi ruby scripts I was getting a maximum of about 900 requests/second. More real world applications would probably yield 5% of that which is fast enough for my applications. Andrew ----- Original Message ----- From: "Michael Campbell" <michael.campbell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> Sent: Thursday, July 14, 2005 7:48 AM Subject: [Rails] "Rails doesn''t scale" Can anyone give me a short list of well known, high traffic sites that use the horizontal, more hardware, type of scaling that Rails would be use? (Sorry, can''t go for "cool" like basecamp, need well known high volume.) I''d like to "quiet" some Rails'' detractors at my office who seem to be hell-bent on bleating out ad nauseum this "Rails doesn''t scale, CGI is for kids" type dogma. As this is probably OT, offline responses welcome. Thanks. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
LiveJournal, Flickr, Wikipedia, and Slashdot, all use the "horizontal scaling" approach. Some amazing LJ stats can be gleaned from here: http://www.livejournal.com/users/news/2004/12/31/ Especially see this LJ presentation about their architecture and scaling (pdf) http://www.danga.com/words/2004_lisa/ Some info about Flickr''s architecture: http://www.niallkennedy.com/blog/archives/2004/10/flickr_architec.html Tom Coates has a little writeup of Flickr dev Cal Henderson''s "How We Built Flickr" workshop: http://www.plasticbag.org/archives/2005/06/cal_henderson_on_how_we_built_flickr.shtml About Wikipedia''s arch: http://meta.wikimedia.org/wiki/Wikimedia_servers
> I think FastCGI needs to be rebranded, i.e. DHTML -> AJAX. > Pisses off lots of tech people, but works damn well > (rebranding that is).Absolutely, it never ceases to amaze me what a little re-branding can do to a product or a company. At the very least, a new name -- or a new term -- really helps to shed former associations. Nissan => Lexus Contax/Kyocera Cameras => Zeiss Ikon Kentucky Fried Chicken => KFC (OK, this one''s a stretch, but you get the picture...) When I first heard of FastCGI, I thought, ''oh, there''s a nice oxymoron'', which is totally untrue but I''m sure I''m not the first one to wrongly make a snap judgement like that.
how about fastcgi => quickserve fastcgi => snapserve fastcgi => rocketscript fastcgi => scripturbo ----- Original Message ----- From: "Dean Matsueda" <dmatsueda-1n2u0cAa2q8@public.gmane.org> To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> Sent: Thursday, July 14, 2005 8:57 AM Subject: RE: [Rails] "Rails doesn''t scale"> I think FastCGI needs to be rebranded, i.e. DHTML -> AJAX. > Pisses off lots of tech people, but works damn well > (rebranding that is).Absolutely, it never ceases to amaze me what a little re-branding can do to a product or a company. At the very least, a new name -- or a new term -- really helps to shed former associations. Nissan => Lexus Contax/Kyocera Cameras => Zeiss Ikon Kentucky Fried Chicken => KFC (OK, this one''s a stretch, but you get the picture...) When I first heard of FastCGI, I thought, ''oh, there''s a nice oxymoron'', which is totally untrue but I''m sure I''m not the first one to wrongly make a snap judgement like that. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Well, what about Slashdot and LiveJournal? For that matter, I think google essentially uses a round robin routing system, similar to what you can achieve with apache and fastcgi. When it comes down to it, a lot of the "Enterprise" systems have so many layers of abstraction that they might not even scale as well as people would think. "Rails Scales" just fine, it just requires a different approach. .adam Can anyone give me a short list of well known, high traffic sites that> use the horizontal, more hardware, type of scaling that Rails would be > use? (Sorry, can''t go for "cool" like basecamp, need well known high > volume.) > > I''d like to "quiet" some Rails'' detractors at my office who seem to be > hell-bent on bleating out ad nauseum this "Rails doesn''t scale, CGI is > for kids" type dogma. > > As this is probably OT, offline responses welcome. > > Thanks._______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Wed, 13 Jul 2005, Dean Matsueda wrote:> When I first heard of FastCGI, I thought, ''oh, there''s a nice oxymoron'', > which is totally untrue but I''m sure I''m not the first one to wrongly > make a snap judgement like that.Like the "Simple" in "SOAP"? -- _Deirdre web / blog: http://deirdre.net/ yarn: http://fuzzyorange.com cat''s blog: http://fuzzyorange.com/vsd/ "Memes are a hoax! Pass it on!"
Andrew Stuart said:> how about > > fastcgi => quickserve > fastcgi => snapserve > fastcgi => rocketscript > fastcgi => scripturboThose aren''t bad. Some more: UltraServe SpeedScript Cheetah Comet (hehe, a bit of an Ajax joke, could be an acronym for Cgi On METal or something ;) Ryan
Thanks guys, this is precisely what I was looking for!
On Wed, 13 Jul 2005, Andrew Otwell wrote:> Some amazing LJ stats can be gleaned from here: > http://www.livejournal.com/users/news/2004/12/31/ > > Especially see this LJ presentation about their architecture and scaling > (pdf) > http://www.danga.com/words/2004_lisa/There''s an update on that from when they spoke at BayLisa earlier this year: http://www.baylisa.org/library/slides/2005/may2005lj.pdf -- _Deirdre web / blog: http://deirdre.net/ yarn: http://fuzzyorange.com cat''s blog: http://fuzzyorange.com/vsd/ "Memes are a hoax! Pass it on!"
On Jul 13, 2005, at 3:57 PM, Dean Matsueda wrote:>> I think FastCGI needs to be rebranded, i.e. DHTML -> AJAX. >> Pisses off lots of tech people, but works damn well >> (rebranding that is). >> > > Absolutely, it never ceases to amaze me what a little re-branding > can do > to a product or a company. At the very least, a new name -- or a new > term -- really helps to shed former associations. > > Nissan => LexusNot to mention the Toyota => Infinti rebranding. Both were so successful it''s like the rebranded vehicles are from two completely separate companies! ;) -Dane
On Thu, Jul 14, 2005 at 08:44:05AM +1000, Andrew Stuart wrote:> How many applications being built in the corporate world need > Yahoo/Google/Slashdot/microsoft.com level performance? Probably not many. > > The performance obsessed programmers who think speed is the first and > primary issue have usually never project managed or acted as a development > team lead or had any responsibility for the project outcomes. > > In most cases a far more important question than "how fast is it?" is "how > simple is it?" - "how productive will the developrs be with this > technology".Hear, hear. Ofcouse it doesn''t hurt to have fastcgi/mod_ruby/whatever portabiltiy in mind when you''re developing. In my experience with dynamic languages, the startup/compile time is by far the most expensive. If you can use a solution like fastcgi so you can reduce the effective compilation overhead to something like 0.1%, the rest is easy. And when you get to slashdot type performance requirements, there is no substitute for good design and hand-tweaking no matter what technology you choose.> Give me a simple solution that''s fast enough any time over a complex > solution that is more than fast enough. > > The best question is is this technology fast enough for "what we need?" > > where "what we need" = varying degrees and priorities of > maintainability > reliability > expected lifetime of software > disk/memory footprintJust a hint for *real* high-performance sites: I heard that kernel.org has its data partitions mounted with atime logging disabled. Probably only useful when your average network IO speed resembles your disk speed, though. :D> compliance with corporate standards > suitability of software licence > cost > expertise of development resources > match with operational and implementation environment > availability of documentation for technology > ability to integrate with existing systems > ability to implement specific application requirements > time to market/completion > defined level of reliability > oh, and performance too > > If there are performance issues, first profile them, measure them, optimise > them and then finally hit them with the hardware hammer and see if they go > away. > > The most critical point about performance arguments in my experience as that > they are almost always agrued without any quantifiable numbers at all - > no-one bothers to profile or run apachebench to discuss the issue with true > numbers. > > I ran performance tests on fastcgi whwne I first looked at rails to > understand "is this fast enough" and I do recall that for dirt-simple > fastcgi ruby scripts I was getting a maximum of about 900 requests/second. > More real world applications would probably yield 5% of that which is fast > enough for my applications. > > Andrew > > > > > ----- Original Message ----- > From: "Michael Campbell" <michael.campbell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> > Sent: Thursday, July 14, 2005 7:48 AM > Subject: [Rails] "Rails doesn''t scale" > > > Can anyone give me a short list of well known, high traffic sites that > use the horizontal, more hardware, type of scaling that Rails would be > use? (Sorry, can''t go for "cool" like basecamp, need well known high > volume.) > > I''d like to "quiet" some Rails'' detractors at my office who seem to be > hell-bent on bleating out ad nauseum this "Rails doesn''t scale, CGI is > for kids" type dogma. > > As this is probably OT, offline responses welcome. > > Thanks. > _______________________________________________ > 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
On Wed, Jul 13, 2005 at 04:08:01PM -0700, Deirdre Saoirse Moen wrote:> On Wed, 13 Jul 2005, Dean Matsueda wrote: > > > When I first heard of FastCGI, I thought, ''oh, there''s a nice oxymoron'', > > which is totally untrue but I''m sure I''m not the first one to wrongly > > make a snap judgement like that. > > Like the "Simple" in "SOAP"?Well, it fooled me until I tried it :-) Joost.
Michael, in case you haven''t seen them to make your argument: http://naeblis.cx/rtomayko/2005/05/28/ibm-poop-heads http://www.loudthinking.com/arc/000479.html Are both good reads.
On 7/13/05, Dane Jensen <jensen-hTe+RANN9c/LSiWjCY9aRNBPR1lH4CV8@public.gmane.org> wrote:> > Absolutely, it never ceases to amaze me what a little re-branding > > can do > > to a product or a company. At the very least, a new name -- or a new > > term -- really helps to shed former associations. > > > > Nissan => Lexus > > Not to mention the Toyota => Infinti rebranding.Honda => Acura Jaguar => Ford... no, wait =)
> > > Absolutely, it never ceases to amaze me what a little re-branding > > > can do > > > to a product or a company. At the very least, a new name -- or a new > > > term -- really helps to shed former associations.Oak -> Java (?!) NextSTEP -> Apple (ha!) It''s pretty hard to change the name of a specific "thing" as opposed to say DHTML->AJAX though, as it pretty much requires agreement with authors of said thing. Not to mention every lib out there has the name fastcgi in it, all the docs, etc. So, probably best to help get FCGI nice and debugged and working well for everyone [apache2 compat *is* a good thing, even if many haven''t moved to it yet -- fcgi may in many cases actually be the reason for that] than just trying to gloss over an incorrect repuation that some (clueless) people hold on to without bothering to learn otherwise. -- ________________________________ toddgrimason*todd[ at ]slack.net
Colin Fleming wrote:> Michael, in case you haven''t seen them to make your argument: > > http://naeblis.cx/rtomayko/2005/05/28/ibm-poop-heads > > http://www.loudthinking.com/arc/000479.html > > Are both good reads.Yeah, those are great reads! Also take a look at what Lucas Carlson had to say: http://tech.rufy.com/entry/69 Curt
Andrew Stuart wrote:> Lots of programmers have "performance obsession" and the first question they > ask is "how fast is it?". These same programmers are the time wasters on > software projects who instead of implementing a simple, easy to maintain and > understandable solution that might not be lightning fast, are so performance > obsessed that they always spend far more time implementing complex, > difficult to understand and maintain "high performance" features, proving > how smart they are, puzzling their peers, setting back the schedule and > reducing the maintainability and reliability. All this to make the > application a little bit faster when it possibly didn''t need to be any > faster in that area. "Speed", "performance", "scalability" is their foolish > mantra.As DJB says [1]: "Profile. Don''t speculate" [1] http://en.wikiquote.org/wiki/Daniel_J._Bernstein> In most cases a far more important question than "how fast is it?" is "how > simple is it?" - "how productive will the developrs be with this > technology".I think a more pertinent question is "how fast does it need to be?"> > Give me a simple solution that''s fast enough any time over a complex > solution that is more than fast enough. > > The best question is is this technology fast enough for "what we need?"+1> > where "what we need" = varying degrees and priorities of > maintainability > reliability > expected lifetime of software > disk/memory footprint > compliance with corporate standards > suitability of software licence > cost > expertise of development resources > match with operational and implementation environment > availability of documentation for technology > ability to integrate with existing systems > ability to implement specific application requirements > time to market/completion > defined level of reliability > oh, and performance too > > If there are performance issues, first profile them, measure them, optimise > them and then finally hit them with the hardware hammer and see if they go > away.Absolutely. R. -- http://robinbowes.com If a man speaks in a forest, and his wife''s not there, is he still wrong?
Evan William''s (from blogger.com) new venture Odeo.com has been built with ruby on rails from scratch, with some this will show wheter Ruby scales or not. Lucas On 7/14/05, Robin Bowes <robin-lists-uu/5VZhsSz10ubjbjo6WXg@public.gmane.org> wrote:> Andrew Stuart wrote: > > Lots of programmers have "performance obsession" and the first question they > > ask is "how fast is it?". These same programmers are the time wasters on > > software projects who instead of implementing a simple, easy to maintain and > > understandable solution that might not be lightning fast, are so performance > > obsessed that they always spend far more time implementing complex, > > difficult to understand and maintain "high performance" features, proving > > how smart they are, puzzling their peers, setting back the schedule and > > reducing the maintainability and reliability. All this to make the > > application a little bit faster when it possibly didn''t need to be any > > faster in that area. "Speed", "performance", "scalability" is their foolish > > mantra. > > As DJB says [1]: "Profile. Don''t speculate" > > [1] http://en.wikiquote.org/wiki/Daniel_J._Bernstein > > > In most cases a far more important question than "how fast is it?" is "how > > simple is it?" - "how productive will the developrs be with this > > technology". > > I think a more pertinent question is "how fast does it need to be?" > > > > > Give me a simple solution that''s fast enough any time over a complex > > solution that is more than fast enough. > > > > The best question is is this technology fast enough for "what we need?" > > +1 > > > > > where "what we need" = varying degrees and priorities of > > maintainability > > reliability > > expected lifetime of software > > disk/memory footprint > > compliance with corporate standards > > suitability of software licence > > cost > > expertise of development resources > > match with operational and implementation environment > > availability of documentation for technology > > ability to integrate with existing systems > > ability to implement specific application requirements > > time to market/completion > > defined level of reliability > > oh, and performance too > > > > If there are performance issues, first profile them, measure them, optimise > > them and then finally hit them with the hardware hammer and see if they go > > away. > > Absolutely. > > R. > -- > http://robinbowes.com > > If a man speaks in a forest, > and his wife''s not there, > is he still wrong? > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> Comet (hehe, a bit of an Ajax joke, could be an acronym for Cgi On METal > or something ;)or CGI On METh... -- - Frank FrankManno.com <a href="http://www.spreadfirefox.com/?q=affiliates&id=2496&t=1">Get Firefox!</a>
Very well put Andrew. When I was working on *very* high-load sites, my team concentrated on features and getting it done. Whenever we would do an iteration with our client, we would also load the code into our load test environment. The load test environment simulated production as closely as possible. It also included a set of client machines that could ramp up to generate a lot of "traffic". If, during an iteration, there was any major damage to the performance numbers, that part would get re-architected/rewritten. We wrote applications for clients like Ford cars in Java, PHP and ASP. In all of my experience, the language in which we did the project had almost no bearing on the performance numbers. If anything, the more flexible languages allowed for more re-architecting/refactoring in order to streamline the code. We were usually left with more time on those projects to play the optimization game. The other reality is, a new server can be purchased to add horsepower and cost less than a day''s worth of wages for a team. -Simon Andrew Stuart wrote:> Lots of programmers have "performance obsession" and the first question they > ask is "how fast is it?". These same programmers are the time wasters on > software projects who instead of implementing a simple, easy to maintain and > understandable solution that might not be lightning fast, are so performance > obsessed that they always spend far more time implementing complex, > difficult to understand and maintain "high performance" features, proving > how smart they are, puzzling their peers, setting back the schedule and > reducing the maintainability and reliability. All this to make the > application a little bit faster when it possibly didn''t need to be any > faster in that area. "Speed", "performance", "scalability" is their foolish > mantra. > > How many applications being built in the corporate world need > Yahoo/Google/Slashdot/microsoft.com level performance? Probably not many. > > The performance obsessed programmers who think speed is the first and > primary issue have usually never project managed or acted as a development > team lead or had any responsibility for the project outcomes. > > In most cases a far more important question than "how fast is it?" is "how > simple is it?" - "how productive will the developrs be with this > technology". > > Give me a simple solution that''s fast enough any time over a complex > solution that is more than fast enough. > > The best question is is this technology fast enough for "what we need?" > > where "what we need" = varying degrees and priorities of > maintainability > reliability > expected lifetime of software > disk/memory footprint > compliance with corporate standards > suitability of software licence > cost > expertise of development resources > match with operational and implementation environment > availability of documentation for technology > ability to integrate with existing systems > ability to implement specific application requirements > time to market/completion > defined level of reliability > oh, and performance too > > If there are performance issues, first profile them, measure them, optimise > them and then finally hit them with the hardware hammer and see if they go > away. > > The most critical point about performance arguments in my experience as that > they are almost always agrued without any quantifiable numbers at all - > no-one bothers to profile or run apachebench to discuss the issue with true > numbers. > > I ran performance tests on fastcgi whwne I first looked at rails to > understand "is this fast enough" and I do recall that for dirt-simple > fastcgi ruby scripts I was getting a maximum of about 900 requests/second. > More real world applications would probably yield 5% of that which is fast > enough for my applications. > > Andrew > >-- Simon C. Wex Sr. Software Developer simon-CdwZJljFklGxC8Nw+8W25jKzEDxYleXD@public.gmane.org 519.679.7888 "There are 10 types of people in this world, those who understand binary, and those who do not"
I once ran an application server which later I found out it didn''t scale. It sucked big-time, I lost a lot of sleep and probably some hair from that experience. The server technology was never really tested in high-volume production environments. I was new to the game at the time so I didn''t know what to look for. It was a commercial product and had a large user-base but the main app was pretty new so there wasn''t much experience with it by anyone other than the "beta testers" which ended up being the people who bought it (like me). Lesson learned. I can see the cause of people''s concerns about Rails being scalable. Here are some of the things I see that hinder scalability and how Rails does not suffer from those problems. #1 No RDB support. When you have an app that has its own db-type be weary (like an ODB) with no support for other db-types. Not Rails: Rails Supports multiple tried and proven RDB''s with native drivers. Yay! #2 Stuck on 1 platform. When you have only 1 or 2 choices of operating systems like Win or MacOS, I am talking OS8 here people serious. Not Rails: Rails runs on Linux, Win32, Unix, OSX the list goes on.... #3 Runs own http server. When you can only use whatever http server the app has built-in with no choice of other tried and proven http servers (regardless of using Apache/proxypass which is more overhead and the bottleneck is still the same). Not Rails: Rails supports multiple tried and proven http servers: Lighttpd, Apache, WEBrick, IIS??? I imagine any http server that supports cgi or fcgi. #4 Has no benchmarking/profiling ability or way to discover bottlenecks in code. Not Rails: Rails has profiling and benchmarker already! Yay! #5 Has never been used on a high-volume site with stats. Not Rails: Rails is used on quite a few sites that get millions of hits a day. See: www.43things.com, www.basecamphq.com, any 37sigs sites... Scott Burton www.similarthings.com Blog.similarthings.com Spurton.blogspot.com -----Original Message----- From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Curt Hibbs Sent: Wednesday, July 13, 2005 9:15 PM To: Colin Fleming; rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: Re: [Rails] "Rails doesn''t scale" Colin Fleming wrote:> Michael, in case you haven''t seen them to make your argument: > > http://naeblis.cx/rtomayko/2005/05/28/ibm-poop-heads > > http://www.loudthinking.com/arc/000479.html > > Are both good reads.Yeah, those are great reads! Also take a look at what Lucas Carlson had to say: http://tech.rufy.com/entry/69 Curt _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails