StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>No matter what you do to scale or increase performance of Rails you will want to take benchmarks before and after. It is easy to install the latest performance-enhancing plugin or copy someone else's technique, but without measuring execution times you will never know whether the things you are doing increase performance or degrade it.</p> <p>Performance is relative and can vary based on many factors. There are two aspects of performance that are important for scaling Rails:</p> <ul> <li>Latency -- How fast can we answer a request? This is measured as the time elapsed between request and response. </li> <li>Throughput -- How many requests can we process over a given amount of time? This is measured as responses per second.</li> </ul> <p>After we do our general performance testing we can easily see bottlenecks begin to appear. At that point we can further use packaged tools to narrow the field of focus to one or more of the following, which are in order of most common to least common:</p> <ul> <li><strong>Database problems</strong>: Poor custom SQL, incorrect or non-optimal joins and associations, overly large database tables, etc.</li> <li><strong>Model problems</strong>: Business rules are overly complex or incorrectly designed.</li> <li><strong>Front-end view problems</strong>: Poor HTML or CSS choices, extremely large javascript libraries, un-optimized images, etc.</li> <li><strong>Transactional problems</strong>: Too few Mongrel (or other app server) instances running, not enough hardware, poorly written or non-optimal controllers, incorrectly architected application, etc.</li> </ul> <p>Often people think of transactional problems as the cause of poor performance, when more often it is caused by the other types of problems.</p> <p>If you have poorly-designed custom SQL, extremely large database tables, or non-optimal joins or associations, no matter how much hardware you throw into the mix you may never increase performance. Your Rails application just won't scale. The same thing applies for some transactional problems. Most scalability problems occur when bad practices were followed during design and coding phases of development.</p> <p>The following tools will be helpful in determining where your bottlenecks live...</p> <ul> <li>"<a href="http://agilewebdevelopment.com/plugins/query_analyzer" rel="noreferrer">query_analyzer</a>" - Bob Silva's MySQL tool for automatically EXPLAINing each query.</li> <li>"<a href="http://ruby-prof.rubyforge.org/" rel="noreferrer">ruby-prof</a>" - A fast Ruby code profiler written in C.</li> <li>"<a href="http://rails-analyzer.rubyforge.org/pl_analyze/" rel="noreferrer">pl_analyze</a>" - Written by Eric Hodel, this analyzes logger output from SysLogLogger.</li> <li>"<a href="http://developer.yahoo.com/yslow/" rel="noreferrer">yslow</a>" - A Firebug plugin to measure and determine why a particular page is slow.</li> <li>"<a href="http://developer.yahoo.com/yui/compressor/" rel="noreferrer">YUI compressor</a>" - A Javascript/CSS compression tool from the performance team at Yahoo.</li> </ul> <p>Once you determine where the problems exist it is much easier to zero-in and address each issue.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload