I''ve casually glanced through rails'' code and it seems pretty legit. Not too inefficient. Does what it should. So...my question is...why is it still somewhat slow? Blame it on Ruby, I suppose, however, there have been reports that running rails on Ruby 1.9 only results in a 15% increase--which is somewhat disappointing. So...how could one best contribute to try to get rails faster? Or stated in other words: where''s the bottleneck? Just the VM? Do Ramaze or merb run very large sites much faster? If so then rails might be the culprit. If not then I guess it''s just a ruby thing[?] Thanks! -R -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
The easy "copout" answer to questions of why Rails is slow is to blame
Ruby. Is Ruby slower than other languages, sure it is. But, this is
not the interesting question. The interesting question is, "How much
does Ruby performance matter to your application?"
Is it really that important to reduce your Ruby execution time from
say 100 milliseconds to 80 milliseconds so that you can gain more time
to wait 1000 milliseconds for the database to return your result set?
My point is that there are multitudes of factors involved in system
performance. Each part needs its own optimization. It''s so easy to
look at a set of benchmarks and draw conclusions about how platform x
is y times slower than platform z. However, that doesn''t take into
account any other platform advantages. For instance, it says nothing
about developer productivity. How much more performance do you get out
of that Rails application you built and deployed over the weekend,
while you''re still waiting for a Java team to get the project out of
the initial planning stage?
I realize these may be exaggerated examples, but as a JavaEE developer
by trade, just learning Rails, this is what has attracted me to the
Rails framework. I personally find that, on average, I can produce
between 4 and 5 times more deployable program features given a fixed
block of time. And I find the Rails code to be much easier to
understand, maintain, and enhance. So the developer productivity is
sustainable though the life of the product. In the vast majority of
cases this far outweighs the fact that Ruby is somewhat slower than
other languages.
Nearly every performance problem I have encountered has nothing to do
with the processor performance anyway. It''s nearly always some poor
database design (or usage) that causes the problem. And with a 4 to 5
times increase in deployable code, and shorten release cycles, it''s
usually pretty easy to budget in an extra Linux box to make up the
performance difference.
def choose_language
if scaleability == language_performance
development_language = assembly
else
development_language = your_choice
end
end
protected
def your_choice
what_makes_you_productive_and_happy
end
On Apr 29, 6:44 pm, Roger Pack
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:> I''ve casually glanced through rails'' code and it seems
pretty legit.
> Not too inefficient. Does what it should.
> So...my question is...why is it still somewhat slow? Blame it on Ruby,
> I suppose, however, there have been reports that running rails on Ruby
> 1.9 only results in a 15% increase--which is somewhat disappointing.
>
> So...how could one best contribute to try to get rails faster?
> Or stated in other words: where''s the bottleneck? Just the VM?
> Do Ramaze or merb run very large sites much faster? If so then rails
> might be the culprit.
> If not then I guess it''s just a ruby thing[?]
>
> Thanks!
> -R
> --
> Posted viahttp://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
I advice you to do it : [1] dont put prototype.js to your layout if it''s useless, because it will verify each time you''re loading the page. [2] use restful to speed up your performance. [3] Decrease in using tons of plugins. [4] Optimize uses of ActiveRecord. All activities of ActiveRecord should put it in ActiveRecord, dont in controller or View. And all business logics of controller dont runt it in View. [5] Decrease in storing your image in database. [6] Dont repeat your self in controller. [7] If you use AJAX, package it, if not it will make your web so slow. [8] Compress your image. [9] Checkout your webserver, you can contact your support to analyze your webserver or bandwith. Good Luck, reinhart http://teapoci.blogspot.com Experts Advice : http://www.bencurtis.com/archives/2007/08/5-tips-to-speed-up-your-rails-app/ http://www.clipclip.org/clips/detail/6487/infoq-a-look-at-common-performance-problems-in-rails http://www.fak3r.com/2006/05/11/speed-up-ruby-on-rails-with-memcached/ -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Roger Pack wrote:> So...my question is...why is it still somewhat slow? Blame it on Ruby, > I suppose, however, there have been reports that running rails on Ruby > 1.9 only results in a 15% increase--which is somewhat disappointing.My testing show me that the slowest part of Rails is loading all of the ActiveRecord components. AFAICT this is the fundamental issue with Rails being slower than other frameworks. It is why Rails needs to have a pre-running engine running with a pre-loaded version of ActiveRecord. Of course on the other hand many people feel that ActiveRecord is one of the best parts of Rails and therefore feel that the performance penalty is well worth it for the gain in functionality.> So...how could one best contribute to try to get rails faster?Optimize AciveRecord and it would speed up Rails.> Or stated in other words: where''s the bottleneck? Just the VM?The Ruby interpreter is slower than other interpreters but not unduly. This is getting speeded up in newer Ruby versions. But performance is on the same order of magnitude as other interpreters. But it doesn''t account for the ActiveRecord load times. If another language were used with the same design I am sure the same performance issues would be noted. Bob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 30 Apr 2008, at 22:46, Bob Proulx wrote:> > Roger Pack wrote: >> So...my question is...why is it still somewhat slow? Blame it on >> Ruby, >> I suppose, however, there have been reports that running rails on >> Ruby >> 1.9 only results in a 15% increase--which is somewhat disappointing. > > My testing show me that the slowest part of Rails is loading all of > the ActiveRecord components. AFAICT this is the fundamental issue > with Rails being slower than other frameworks. It is why Rails needs > to have a pre-running engine running with a pre-loaded version of > ActiveRecord. >I''m not sure what you mean - ActiveRecord (along with all of rails itself) is loaded when the server is started. Fred> Of course on the other hand many people feel that ActiveRecord is one > of the best parts of Rails and therefore feel that the performance > penalty is well worth it for the gain in functionality. > >> So...how could one best contribute to try to get rails faster? > > Optimize AciveRecord and it would speed up Rails. > >> Or stated in other words: where''s the bottleneck? Just the VM? > > The Ruby interpreter is slower than other interpreters but not unduly. > This is getting speeded up in newer Ruby versions. But performance is > on the same order of magnitude as other interpreters. But it doesn''t > account for the ActiveRecord load times. If another language were > used with the same design I am sure the same performance issues would > be noted. > > Bob > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Frederick Cheung wrote:> Bob Proulx wrote: > > Roger Pack wrote: > > > So...my question is...why is it still somewhat slow? Blame it on > > > Ruby, I suppose, however, there have been reports that running > > > rails on Ruby 1.9 only results in a 15% increase--which is > > > somewhat disappointing. > > > > My testing show me that the slowest part of Rails is loading all of > > the ActiveRecord components. AFAICT this is the fundamental issue > > with Rails being slower than other frameworks. It is why Rails needs > > to have a pre-running engine running with a pre-loaded version of > > ActiveRecord. > > I''m not sure what you mean - ActiveRecord (along with all of rails > itself) is loaded when the server is started.It all comes down to what part of the performance is a concern. Roger the original poster didn''t say and frankly I just made assumptions. I was probably wrong. Loading is the only performance issue I see. Once it is loaded I don''t have any performance concerns. Therefore by that logical case that I kept private in my own head I assumed Roger was concerned about load time performance. Bob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks for all your help guys. Looks like to speed up loading there are a few options [http://pennysmalls.com/ describes a few]. I''ll see if they help much. I wonder if once AR is loaded ''quickly'' uses these plugins if 1.9 ''really speeds up'' rendering or what not. That would be a sweet thing. -R On Wed, Apr 30, 2008 at 9:44 PM, Bob Proulx <bob-5cAygf9QrE/QT0dZR+AlfA@public.gmane.org> wrote:> > Frederick Cheung wrote: > > Bob Proulx wrote: > > > Roger Pack wrote: > > > > So...my question is...why is it still somewhat slow? Blame it on > > > > Ruby, I suppose, however, there have been reports that running > > > > rails on Ruby 1.9 only results in a 15% increase--which is > > > > somewhat disappointing. > > > > > > My testing show me that the slowest part of Rails is loading all of > > > the ActiveRecord components. AFAICT this is the fundamental issue > > > with Rails being slower than other frameworks. It is why Rails needs > > > to have a pre-running engine running with a pre-loaded version of > > > ActiveRecord. > > > > I''m not sure what you mean - ActiveRecord (along with all of rails > > itself) is loaded when the server is started. > > It all comes down to what part of the performance is a concern. Roger > the original poster didn''t say and frankly I just made assumptions. > I was probably wrong. > > Loading is the only performance issue I see. Once it is loaded I > don''t have any performance concerns. Therefore by that logical case > that I kept private in my own head I assumed Roger was concerned about > load time performance. > > > > Bob > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
roosevelt.lai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2008-May-01 05:41 UTC
Re: rails'' bottleneck
generally speaking, I didn''t feel ruby-on-rails is slower than struts- (or spring)-on-Java. J2EE is the worst performer I ever seen, but it still hold big chunk of the enterprise market. roosevelt ------------------------------ www.radio21g.com On Apr 30, 6:44 am, Roger Pack <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> I''ve casually glanced through rails'' code and it seems pretty legit. > Not too inefficient. Does what it should. > So...my question is...why is it still somewhat slow? Blame it on Ruby, > I suppose, however, there have been reports that running rails on Ruby > 1.9 only results in a 15% increase--which is somewhat disappointing. > > So...how could one best contribute to try to get rails faster? > Or stated in other words: where''s the bottleneck? Just the VM? > Do Ramaze or merb run very large sites much faster? If so then rails > might be the culprit. > If not then I guess it''s just a ruby thing[?] > > Thanks! > -R > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
roosevelt.lai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:> generally speaking, I didn''t feel ruby-on-rails is slower than struts- > (or spring)-on-Java. > J2EE is the worst performer I ever seen, but it still hold big chunk > of the enterprise market. >When you run it in production mode, you will feel it slower than php in apache. but java is still the slowest. Since i knew and learn Java, Yet no one project was done in Java, always ruby on rails or Cakephp. reinhart http://teapoci.blogspot.com -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On May 1, 7:22 am, Visit Indonesia 2008 <rails-mailing-l...@andreas- s.net> wrote:> roosevelt....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote: > > generally speaking, I didn''t feel ruby-on-rails is slower than struts- > > (or spring)-on-Java. > > J2EE is the worst performer I ever seen, but it still hold big chunk > > of the enterprise market. > > When you run it in production mode, you will feel it slower than php in > apache. but java is still the slowest. Since i knew and learn Java, Yet > no one project was done in Java, always ruby on rails or Cakephp. >When it comes to raw performance, Java is without hint of doubt much faster than ruby (how else could jruby be faster than ruby 1.8). Of course you can write a slow application in java, but you can do that in rails too. Fred --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Yet no vendors or programing languages have claimed that they are faster or fastest. Every application can be slower or faster even slowest or fastest, depend on programmer or system analyst who work together composing or creating its application. :D Reinhart -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I have made a lot of tests myself, and the slowness of Rails comes from: - InnoDB engine when performing loads of SELECT. - ActiveRecord which by default does a SELECT * - ActiveRecord which creates objects from everything returned from DB. - using :include with AR - using view helpers such as link_to and that kind of crap - coding practices from former php coders - plugins that do too much introspection like permalink_fu which can be hardcoced in only 3 lines in the model. - people forgetting about caching - ... By refactoring my code very frequently and keeping an eye on what SQL queries AR creates, I can increase my app''s performance by x5 on some critical processing. My biggest increase was actually x1000 by working on tuning the DB with a very big table of 100k rows. Honestly I consider that Rails is fast, it is the coder who doesn''t know how to use it correctly that is the real problem. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> - ActiveRecord which by default does a SELECT *> - ActiveRecord which creates objects from everything returned from DB.Is this last really avoidable, though? Unless you plan on paginating it seems like it''s hard to overcome [except, as you say, watching queries and cutting down on them where possible].> - using :include with ARI wonder if AR does a single query per item to retrieve those ''to be included'' items. Ugh.> - using view helpers such as link_to and that kind of crap > - coding practices from former php coders > - plugins that do too much introspection like permalink_fu which can be > hardcoced in only 3 lines in the model. > - people forgetting about caching > - ... > > By refactoring my code very frequently and keeping an eye on what SQL > queries AR creates, I can increase my app''s performance by x5 on some > critical processing. My biggest increase was actually x1000 by working > on tuning the DB with a very big table of 100k rows.Very interesting. So it seems that most of it is from AR and if you have large rows it slows you down. Nice look! -R> Honestly I consider that Rails is fast, it is the coder who doesn''t know > how to use it correctly that is the real problem.I''ve heard people mention that before. -R --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Fernando Perez wrote:> I have made a lot of tests myself, and the slowness of Rails comes from:...> - ActiveRecord which creates objects from everything returned from DB.I did notice a plugin which attempts to combat this--slim_attributes [1] and also hash_extension [3]> - using :include with ARNo help there :)> - using view helpers such as link_to and that kind of crapRecently found one treating this subject, as well [though it''s may not be that polished] [2].> - coding practices from former php coders > - plugins that do too much introspection like permalink_fu which can be > hardcoced in only 3 lines in the model. > - people forgetting about caching > - ... > > By refactoring my code very frequently and keeping an eye on what SQL > queries AR creates, I can increase my app''s performance by x5 on some > critical processing. My biggest increase was actually x1000 by working > on tuning the DB with a very big table of 100k rows.Interesting, so it''s AR loading that was troublesome. Well with the release of 2.2 and some non blocking IO drivers [4] hopefully it will put some more focus on speed, since there will no longer be an excuse of "well all the latency is caused by IO" I hope :) Thanks all! -=R [1] http://pennysmalls.com/2008/04/02/speed-up-mysql-in-rails/ [2] http://railsexpress.de/blog/articles/2006/08/15/rails-template-optimizer-beta-test [3] http://blog.chak.org/2008/01/22/activerecord-is-slow-hashes-are-fast/#comment-81 [4] http://www.rubyinside.com/mysqlplus-non-blocking-mysql-driver-for-ruby-1138.html -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Sep 16, 11:59 pm, Roger Pack <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > By refactoring my code very frequently and keeping an eye on what SQL > > queries AR creates, I can increase my app''s performance by x5 on some > > critical processing. My biggest increase was actually x1000 by working > > on tuning the DB with a very big table of 100k rows. > > Interesting, so it''s AR loading that was troublesome. > > Well with the release of 2.2 and some non blocking IO drivers [4] > hopefully it will put some more focus on speed, since there will no > longer be an excuse of "well all the latency is caused by IO" I hope :)Most of the time, the significant overhead is with AR composing the resultset into AR objects. Most benchmarks I saw report small times on the DB side (even with large resultsets). Of course, the smaller the resultset, the less objects AR has to compose so it''s always a good idea to watch the SQL. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---