I''ve been reading, hearing, and looking at blogs that state Ruby on Rails is rather slow. Coming from a VB 6 world (thank you Microsoft for killing VB because VB.NET is NOT VB) I was always told that VB was a toy or too slow. Now, I''ll easily tell you that yes VB was not a great language. It had it''s share of warts, like a lot of other languages I might add, but in the end you could build almost anything in VB and it ran well enough for 99% of apps. So I was curious to see the same thing being applied to Ruby on Rails. I''ve seen conversations that it: 1. Doesn''t scale 2. Its too slow 3. Its script, no one takes that seriously in the enterprise I''ve done a lot of testing with both Ruby and with Rails. First, I haven''t hit any issues where I''ve found it too slow. On the contrary I''ve found that when you get Rails setup correctly it performs exceptionally well (Litespeed''s LSAPI is insanely fast once configured). It certainly scales. The websites are out there proving this (Basecamp, 43Things, Yakima Herald, etc.) Sure, these sites aren''t eBay or Amazon but toss enough hardware at Rails and it could be eBay. I take script VERY seriously. Occasionally I''ll find myself in Objective-C to do some low level dirty work on the sytems level BUT when it comes to the web how many people aren''t using a scripting language of some sort? (Perl, Python, ASP, PHP?) These arguments don''t seem to hold a whole lot of water IMHO. My company''s next project is going to be 100% RoR and I already expect our dev time to be less than that of ASP.NET/C# (our current tool). Rails is evolving very fast and that is actually a good thing. (Begin Microsoft Rant --> Rails has excellent AJAX support whereas ASP.NET has STILL got Atlas in perma-beta. Sorry Microsoft but 7+ months and counting to get a released version of Atlas out is unacceptable - where does all that R&D money go? Answer: pie in the sky ideas like Zune and XBox). -- Posted via http://www.ruby-forum.com/.
On Jul 31, 2006, at 9:37 AM, Ted Bittle wrote:> I''ve been reading, hearing, and looking at blogs that state Ruby on > Rails is rather slow. Coming from a VB 6 world (thank you > Microsoft for > killing VB because VB.NET is NOT VB) I was always told that VB was > a toy > or too slow. Now, I''ll easily tell you that yes VB was not a great > language. It had it''s share of warts, like a lot of other languages I > might add, but in the end you could build almost anything in VB and it > ran well enough for 99% of apps. > > So I was curious to see the same thing being applied to Ruby on Rails. > I''ve seen conversations that it: > 1. Doesn''t scale > 2. Its too slow > 3. Its script, no one takes that seriously in the enterprise > > I''ve done a lot of testing with both Ruby and with Rails. First, I > haven''t hit any issues where I''ve found it too slow. On the contrary > I''ve found that when you get Rails setup correctly it performs > exceptionally well (Litespeed''s LSAPI is insanely fast once > configured). > > It certainly scales. The websites are out there proving this > (Basecamp, > 43Things, Yakima Herald, etc.) Sure, these sites aren''t eBay or > Amazon > but toss enough hardware at Rails and it could be eBay. > > I take script VERY seriously. Occasionally I''ll find myself in > Objective-C to do some low level dirty work on the sytems level BUT > when > it comes to the web how many people aren''t using a scripting > language of > some sort? (Perl, Python, ASP, PHP?) > > These arguments don''t seem to hold a whole lot of water IMHO. My > company''s next project is going to be 100% RoR and I already expect > our > dev time to be less than that of ASP.NET/C# (our current tool). Rails > is evolving very fast and that is actually a good thing. (Begin > Microsoft Rant --> Rails has excellent AJAX support whereas > ASP.NET has > STILL got Atlas in perma-beta. Sorry Microsoft but 7+ months and > counting to get a released version of Atlas out is unacceptable - > where > does all that R&D money go? Answer: pie in the sky ideas like Zune > and > XBox).I''m not sure why you don''t think those arguments hold much water. I guess you''re looking for something a bit bigger? If you google around a bit, you can find a number of speed comparisons between ruby and other languages. This one is nice: http://www.timestretch.com/FractalBenchmark.html There''s another one like it that includes YARV benchmarks, but I can''t turn it up. It is quite definitely slow. But not so slow to make it a problem. Similar to the scaling issue, there are a lot of big sites using it with no trouble at all. I also like this article from DHH on scaling: http:// www.loudthinking.com/arc/000479.html And I think the capistrano tutorial is a good testament to scaling RoR. The second example is a 5 server, scalable setup! As for scripting, I think people that don''t take interpreted languages seriously are really just showing their age. Like you said: perl, python, asp, php... interpreted languages make the world go round, these days. Are they good for everything? No. Are they good for web-apps (among other things, of course)? Hell yes. But if you''re company is already committed during the next project, why worry? Let RoR prove (or disprove if that''s your case) it''s worthiness. -Mat
Mat Schaffer wrote:> I''m not sure why you don''t think those arguments hold much water. I > guess you''re looking for something a bit bigger? If you google > around a bit, you can find a number of speed comparisons between ruby > and other languages. This one is nice: > http://www.timestretch.com/FractalBenchmark.htmlDrawing ASCII characters out to the console doesn''t make for a compelling or fair speed comparison of languages. -- Posted via http://www.ruby-forum.com/.
On Jul 31, 2006, at 10:31 AM, Ron Teasly wrote:> Mat Schaffer wrote: > >> I''m not sure why you don''t think those arguments hold much water. I >> guess you''re looking for something a bit bigger? If you google >> around a bit, you can find a number of speed comparisons between ruby >> and other languages. This one is nice: >> http://www.timestretch.com/FractalBenchmark.html > > Drawing ASCII characters out to the console doesn''t make for a > compelling or fair speed comparison of languages.It''s the math that''s the burden, not the ascii characters. What would you recommend? -Mat
Mat Schaffer wrote:> It''s the math that''s the burden, not the ascii characters. > What would you recommend?Well something real world to start with. Why not set each up to query a database filter through the results, do some updates, etc. Create socket servers, pass info between and see the performance. Create a web app, etc. Math stuff is pretty much useless for most real world apps. People need to hook up to Pay Pal, Amazon S3, etc. No one is rendering a mandlebrot on their website and wondering why its slow. -- Posted via http://www.ruby-forum.com/.
On Jul 31, 2006, at 11:53 AM, Ron Teasly wrote:> Mat Schaffer wrote: > >> It''s the math that''s the burden, not the ascii characters. >> What would you recommend? > > Well something real world to start with. Why not set each up to > query a > database filter through the results, do some updates, etc. Create > socket servers, pass info between and see the performance. Create > a web > app, etc. > > Math stuff is pretty much useless for most real world apps. People > need > to hook up to Pay Pal, Amazon S3, etc. No one is rendering a > mandlebrot > on their website and wondering why its slow.Well, I think the reason you don''t see more metrics like that is that it''s difficult if not impossible to make solid measurements in those situations. If a database (or paypal or s3) is involved, you could easily end up benchmarking that link in the chain. And that''s not even going into the differences in how each language hooks up to a database or web service. If you want to look at it as a business case, I think you''d do much better to focus on case-studies rather than benchmarks. Granted, the graphs are pretty, but benchmarks in general don''t tell you anything about the real world. -Mat
Sorry for a silly question, but what is the "capistrano tutorial"? I would appricate a link if someone has it. Thank you, Rob Bazinet On 7/31/06, Mat Schaffer <schapht@gmail.com> wrote:> > > On Jul 31, 2006, at 9:37 AM, Ted Bittle wrote: > > > I''ve been reading, hearing, and looking at blogs that state Ruby on > > Rails is rather slow. Coming from a VB 6 world (thank you > > Microsoft for > > killing VB because VB.NET is NOT VB) I was always told that VB was > > a toy > > or too slow. Now, I''ll easily tell you that yes VB was not a great > > language. It had it''s share of warts, like a lot of other languages I > > might add, but in the end you could build almost anything in VB and it > > ran well enough for 99% of apps. > > > > So I was curious to see the same thing being applied to Ruby on Rails. > > I''ve seen conversations that it: > > 1. Doesn''t scale > > 2. Its too slow > > 3. Its script, no one takes that seriously in the enterprise > > > > I''ve done a lot of testing with both Ruby and with Rails. First, I > > haven''t hit any issues where I''ve found it too slow. On the contrary > > I''ve found that when you get Rails setup correctly it performs > > exceptionally well (Litespeed''s LSAPI is insanely fast once > > configured). > > > > It certainly scales. The websites are out there proving this > > (Basecamp, > > 43Things, Yakima Herald, etc.) Sure, these sites aren''t eBay or > > Amazon > > but toss enough hardware at Rails and it could be eBay. > > > > I take script VERY seriously. Occasionally I''ll find myself in > > Objective-C to do some low level dirty work on the sytems level BUT > > when > > it comes to the web how many people aren''t using a scripting > > language of > > some sort? (Perl, Python, ASP, PHP?) > > > > These arguments don''t seem to hold a whole lot of water IMHO. My > > company''s next project is going to be 100% RoR and I already expect > > our > > dev time to be less than that of ASP.NET/C# (our current tool). Rails > > is evolving very fast and that is actually a good thing. (Begin > > Microsoft Rant --> Rails has excellent AJAX support whereas > > ASP.NET has > > STILL got Atlas in perma-beta. Sorry Microsoft but 7+ months and > > counting to get a released version of Atlas out is unacceptable - > > where > > does all that R&D money go? Answer: pie in the sky ideas like Zune > > and > > XBox). > > I''m not sure why you don''t think those arguments hold much water. I > guess you''re looking for something a bit bigger? If you google > around a bit, you can find a number of speed comparisons between ruby > and other languages. This one is nice: > http://www.timestretch.com/FractalBenchmark.html > > There''s another one like it that includes YARV benchmarks, but I > can''t turn it up. > > It is quite definitely slow. But not so slow to make it a problem. > Similar to the scaling issue, there are a lot of big sites using it > with no trouble at all. > > I also like this article from DHH on scaling: http:// > www.loudthinking.com/arc/000479.html > > And I think the capistrano tutorial is a good testament to scaling > RoR. The second example is a 5 server, scalable setup! > > As for scripting, I think people that don''t take interpreted > languages seriously are really just showing their age. Like you > said: perl, python, asp, php... interpreted languages make the world > go round, these days. Are they good for everything? No. Are they > good for web-apps (among other things, of course)? Hell yes. > > But if you''re company is already committed during the next project, > why worry? Let RoR prove (or disprove if that''s your case) it''s > worthiness. > -Mat > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Robert Bazinet http://www.robertbazinet.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060731/f5680af9/attachment.html
On 7/31/06, Robert Bazinet <rbazinet@gmail.com> wrote:> Sorry for a silly question, but what is the "capistrano tutorial"? I would > appricate a link if someone has it.http://wiki.rubyonrails.com/rails/pages/Capistrano -- Greg Donald http://destiney.com/
Thank you. On 7/31/06, Greg Donald <gdonald@gmail.com> wrote:> > On 7/31/06, Robert Bazinet <rbazinet@gmail.com> wrote: > > Sorry for a silly question, but what is the "capistrano tutorial"? I > would > > appricate a link if someone has it. > > http://wiki.rubyonrails.com/rails/pages/Capistrano > > > -- > Greg Donald > http://destiney.com/ > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Robert Bazinet http://www.robertbazinet.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060731/4a53d0ed/attachment.html
On Jul 31, 2006, at 1:18 PM, Robert Bazinet wrote:> Sorry for a silly question, but what is the "capistrano tutorial"? > I would appricate a link if someone has it.This was the one I was referring too: http://manuals.rubyonrails.com/read/book/17 I found it impressive that the second example (http:// manuals.rubyonrails.com/read/chapter/100) is a 6 server setup. That basically squashed all my worries about scaling. Granted, I haven''t tried it myself yet. -Mat
Ted Bittle wrote:> I''ve been reading, hearing, and looking at blogs that state Ruby on > Rails is rather slow. Coming from a VB 6 world (thank you Microsoft for > killing VB because VB.NET is NOT VB) I was always told that VB was a toy > or too slow. Now, I''ll easily tell you that yes VB was not a great > language. It had it''s share of warts, like a lot of other languages I > might add, but in the end you could build almost anything in VB and it > ran well enough for 99% of apps.Having done quite a bit of VB dev, I know 99% is way way too optimistic. One only needs to look through the book "Hardcore Visual Basic" to see the incredibly inane hacks needed to get VB to do more than the most basic of things. Joe -- Posted via http://www.ruby-forum.com/.
Joe wrote:> > Having done quite a bit of VB dev, I know 99% is way way too optimistic. > One only needs to look through the book "Hardcore Visual Basic" to see > the incredibly inane hacks needed to get VB to do more than the most > basic of things.Hmmmm, I never had to resort to inane hacks for my VB programming and I did everything from your typical 3-tier apps, to ActiveX controls/dlls/documents, DirectX, to even VB CGIs in the early days of the Internet. The only thing that ever could have been an issue was the single threaded nature of VB itself but I only once ever hit a point where I had which I could have spawned off a thread in the background. Never did it ever happen that I had to do something in VC++ instead and I''ve been working professionally in VB since 1996 and VC++ since 1998. Steve Inoo ------------------------ --> The Watcher MUD <--- ------------------------ Telnet toward a new dawn -- Posted via http://www.ruby-forum.com/.
Thank you. This is exactly what I was looking for and very interesting information. -Rob On 7/31/06, Mat Schaffer <schapht@gmail.com> wrote:> > > On Jul 31, 2006, at 1:18 PM, Robert Bazinet wrote: > > > Sorry for a silly question, but what is the "capistrano tutorial"? > > I would appricate a link if someone has it. > > This was the one I was referring too: > http://manuals.rubyonrails.com/read/book/17 > > I found it impressive that the second example (http:// > manuals.rubyonrails.com/read/chapter/100) is a 6 server setup. That > basically squashed all my worries about scaling. > > Granted, I haven''t tried it myself yet. > > -Mat > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Robert Bazinet http://www.robertbazinet.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060731/70f4215a/attachment.html
I''m not sure how good math is as a benchmark. But if you want to use math and see what''s coming here is a good posting about YARV and the future of ruby: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/201563 Can''t wait! AEM On 7/31/06, Mat Schaffer <schapht@gmail.com> wrote:> > On Jul 31, 2006, at 10:31 AM, Ron Teasly wrote: > > > Mat Schaffer wrote: > > > >> I''m not sure why you don''t think those arguments hold much water. I > >> guess you''re looking for something a bit bigger? If you google > >> around a bit, you can find a number of speed comparisons between ruby > >> and other languages. This one is nice: > >> http://www.timestretch.com/FractalBenchmark.html > > > > Drawing ASCII characters out to the console doesn''t make for a > > compelling or fair speed comparison of languages. > > It''s the math that''s the burden, not the ascii characters. > What would you recommend? > -Mat > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Adrian Esteban Madrid
Good to hear that Ruby on Rails is faster than PHP, because for me, all that matters is beating my competitor who uses PHP. I''d also like to point out that despite speed, which has been debatable, Rails cuts dev time, and allows you to gain an advantage over the competition in rolling out web apps. And anything can be sped up given the proper hardware; given less developement costs, it is possible to spend more on the actual server infrastructure. -- Posted via http://www.ruby-forum.com/.
Ruby is pretty damn slow. and with a few pieces of commodity hardware Rails can serve millions of hits a day. that should tell you everything you need to know about the marketing of other frameworks, ones built on ''enterprise-grade'' java, etc. as for profiling, im not sure what kind of work is going on. but theres neat profiles of camping in Red Handed''s post history, so i presume you could apply the same techniques to Rails. in the event things arent io bound or pushed down to an optimized layer of C (the DB, HTTP serving, etc), you can tweak to your hearts content with YARV or any of the other multi-language VM''s making the rounds in academic circles these daysll.. -- View this message in context: http://www.nabble.com/Ruby-on-Snails-tf2027561.html#a5588054 Sent from the RubyOnRails Users forum at Nabble.com.
As another data point re "enterprise-grade" Java solutions, I''m currently performance testing a massive portal app that uses IBM''s WebSEAL servers for authentication. We''ve got a whopping 10 concurrent users accessing it, and it runs like a slug on 2 high-end dedicated Linux server-class systems. It has to scale to 3000+ concurrent users. No problem, the bottleneck will be obvious and a bit of tuning will fix it. Well, that''s what I thought too, but IBM''s own experts are having a lot of trouble doing exactly that. I can monitor with a high degree of granularity where the delays are coming from, but they seem powerless to fix it. One guy was brought in at IBM''s recommendation specifically to profile and tune the login process; he''s been at it for about 2 months so far, and has very little in the way of tangible improvement to show for all that time. We''re now starting to hear the dreaded "fixed in the next release" mantra, which pretty much equates to "we have no idea" in my experience. While I''m not suggesting that a 100% RoR based solution would be appropriate in this case, there''s an awful lot to be said for RoR''s simplicity, horizontal scalability, easy deployment, support for several streams of testing, conciseness, etc. in terms of actually getting a meaningful product deployed. With 100+ architects/developers/testers plus the best tools and support money can buy, the app I''m currently testing paints a clear picture that enterprise Java development and infrastructure is woefully behind the times in all of these key areas. Regards Dave M. On 01/08/06, c <_@whats-your.name> wrote:> > Ruby is pretty damn slow. and with a few pieces of commodity hardware Rails > can serve millions of hits a day. that should tell you everything you need > to know about the marketing of other frameworks, ones built on > ''enterprise-grade'' java, etc. as for profiling, im not sure what kind of > work is going on. but theres neat profiles of camping in Red Handed''s post > history, so i presume you could apply the same techniques to Rails. > > in the event things arent io bound or pushed down to an optimized layer of C > (the DB, HTTP serving, etc), you can tweak to your hearts content with YARV > or any of the other multi-language VM''s making the rounds in academic > circles these daysll.. > -- > View this message in context: http://www.nabble.com/Ruby-on-Snails-tf2027561.html#a5588054 > Sent from the RubyOnRails Users forum at Nabble.com. > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Aug 1, 2006, at 8:09 AM, David Mitchell wrote:> As another data point re "enterprise-grade" Java solutions, I''m > currently performance testing a massive portal app that uses IBM''s > WebSEAL servers for authentication. We''ve got a whopping 10 > concurrent users accessing it, and it runs like a slug on 2 high-end > dedicated Linux server-class systems. It has to scale to 3000+ > concurrent users. > > No problem, the bottleneck will be obvious and a bit of tuning will > fix it. Well, that''s what I thought too, but IBM''s own experts are > having a lot of trouble doing exactly that. I can monitor with a high > degree of granularity where the delays are coming from, but they seem > powerless to fix it. One guy was brought in at IBM''s recommendation > specifically to profile and tune the login process; he''s been at it > for about 2 months so far, and has very little in the way of tangible > improvement to show for all that time. We''re now starting to hear the > dreaded "fixed in the next release" mantra, which pretty much equates > to "we have no idea" in my experience. > > While I''m not suggesting that a 100% RoR based solution would be > appropriate in this case, there''s an awful lot to be said for RoR''s > simplicity, horizontal scalability, easy deployment, support for > several streams of testing, conciseness, etc. in terms of actually > getting a meaningful product deployed. With 100+ > architects/developers/testers plus the best tools and support money > can buy, the app I''m currently testing paints a clear picture that > enterprise Java development and infrastructure is woefully behind the > times in all of these key areas. > > Regards > > Dave M.Well said! I love to hear this stuff, but haven''t been exposed to enough of the IBM/Sun stuff to talk about it myself. Thanks for sharing! -Mat