Benchmarking and Profiling Rails

Benchmarking: Is a process that enables comparison of inputs, processes or outputs between institutions (or parts of institutions) or within a single institution over time.

Pretty blah right. If you are new to programing you probably have heard the term mostly in comparative reviews of computer and graphic card specs. If you done a bit of coding you've probably seen in mostly in terms of comparing one language to another or iterations of the same language.

Benchmarking in terms of rails is a bit more specific. It entails comparing and contrasting various parts and pages of an application against one another. Mostly one is looking for how long a page requires to render, but memory consumption is also an area of concern.

Profiling: When a page or process is seen to be problematic due to speed or memory consumption we profile it. Meaning we measures the behavior as the page or process runs, particularly the frequency and duration of function calls. The goal of profiling is not to find bugs, but to eliminate bottlenecks and establish a baseline for future regression testing. It must be engaged in a carefully controlled process of measurement and analysis.

What does that actually mean?

You have to have a clear goal for when you profile. It's very comparable to BDD where you are taking small steps towards a solution instead of trying to do it all in one large all encompassing step. A clearly defined set of expectations is essential for meaningful performance testing. For example, for a Web application, you need to know at least two things: expected load in terms of concurrent users or HTTP connections and acceptable response time.

Numbers and data. You benchmark to compare, your profile to fix. It's all about gaining data to analyze and using that information to better your application. The most important thing you should take away at the moment that this must be done in a systematic way.

So the next logical question is how do we get this data.

What concerns us here is the last line of the action.

Completed in 0.04310 (23 reqs/sec) gives us the amount of requests this specific action can handle. 0.04310 is the total amount of time the process to complete and 23 reqs/sec is an estimation from this. As we will see this number is not strictly valid since is a single instance of the process. But it does give you a general feel as to how the action is performing.

Rendering: 0.00819 (19%) is the amount in milliseconds and the percentage of total time needed to complete the action for rendering the view

DB: 0.00757 (17%) is the amount in milliseconds and the percentage of total time needed to complete the action for querying the database

Pretty easy right. But wait 17+19 equals 36. 36%! where is the rest of the time going? The rest of the time is being spent processing the controller. Which is usually what takes up the bulk of the action

So why can't we just use this to test our rails application. Technically that could work, but would be very stressful and slow. You don't have time to view your log after every request to see if your code is running quickly. Also a request that runs 100 reqs/sec might simply be an outlier and really usually runs at 20 reqs/sec. It's simply not enough information to do everything we need it to do but it's a start.

But there is something else we must consider.

Is Completed in 0.04310 (23 reqs/sec) a good time. Seems like it doesn't it. 43 ms does not outrageous time for a dynamic page load. But is this a dynamic page load. Maybe it was all cached. In which case this is very slow. Or maybe I'm running on five year old equipment and this is actually blazing fast for my G3. The truth is that we can't answer the question given the data. This is part of benchmarking. We need a baseline. Through comparative analysis of all your pages in your app, and an simple dynamic page for a control we can determine how fast your pages are actually running and if any of them need to be optimized.

And now for something completely different a statistic lesson.

Adapted from a blog Article by Zed Shaw. His rant is funnier but will take longer to read. <br /> Programmers Need To Learn Statistics Or I Will Kill Them All

Statistics is a hard discipline. One can study it for years without fully grasping all the complexities. But its a necessary evil for coders of every level to at least know enough about statistics to know they know nothing about statistics. You can't optimize without it, and if you use it wrong, you'll just waste your time and the rest of your team's.

You must always question your metrics and try to demolish your supposed reasoning. Evidence and observation triumph over pure logic. Even the great Knuth once said: “Beware of bugs in the above code; I have only proved it correct, not tried it.”

If you done any benchmarking you have probably heard “All you need to do is run that test [insert power-of-ten] times and then do an average.”

For newbs this whole power of ten comes about because we need enough data to minimize the results being contaminated by outliers. If you loaded a page five times with three of those times being around 75ms and twice 250ms you have no way of knowing the real average processing time for you page. But if we take a 1000 times and 950 are 75ms and 50 are 250ms we have a much clearer picture of the situation.

But this still begs the question of how you determine that 1000 is the correct number of iterations to improve the power of the experiment? (Power in this context basically means the chance that your experiment is right.)

The first thing that needs to be determined is how you are performing the samplings? 1000 iterations run in a massive sequential row? A set of 10 runs with 100 each? The statistics are different depending on which you do, but the 10 runs of 100 each would be a better approach. This lets you compare sample means and figure out if your repeated runs have any bias. More simply put, this allows you to see if you have a many or few outliers that might be poisoning your averages.

Another consideration is if a 1000 transactions is enough to get the process into a steady state after the ramp-up period? A common element of process control statistics is that all processes have a period in the beginning where the process isn’t stable. This “ramp-up” period is usually discarded when doing the analysis unless your run length has to include it. Most people think that 1000 is more than enough, but it totally depends on how the system functions. Many complex interacting systems can easily need 1000 iterations to get to a steady state, especially if performing 1000 transactions is very quick. Imagine a banking system that handles 10,000 transactions a second. I could take a good minute to get this system into a steady state, but your 1000 transaction test is only scratching the surface.

We can demonstrate this through R Code with similar means but different deviations.

Note: R is a system for statistical computation and graphics. It consists of a language plus a run-time environment with graphics, a debugger, access to certain system functions, and the ability to run programs stored in script files.

I construct two sets of 100 random samples from the normal distribution. Now, if I just take the average (mean or median) of these two sets they seem almost the same:

They’re both around 30. So all good right? Not quite. If one looks at the outliers a different story emerges.

They aren't so similar now are they. Averages don't tell you everything. In fact in some cases they tell you almost nothing.

One cannot simply say my website “[insert power-of-ten] requests per second”. This is due to it being an Average. Without some form of range or variance error they are useless. Two averages can be the same, but hide massive differences in behavior. Without a standard deviation it’s not possible to figure out if the two might even be close. An even better approach (with normally distributed data) is to use a Student’s t-test to see if there are differences.

Note: A t-test is any statistical hypothesis test in which the test statistic has a Student's t distribution if the null hypothesis is true. It is applied when the population is assumed to be normally distributed but the sample sizes are small enough that the statistic on which inference is based is not normally distributed because it relies on an uncertain estimate of standard deviation rather than on a precisely known value. #TODO simply this to something I and the rest of the world will actually understand.

Let’s look at the standard deviation for our two samples:

Stability is vastly different for these two samples If this were a web server performance run I’d say the second server (represented by b) has a major reliability problem. No, it’s not going to crash, but it’s performance response is so erratic that you’d never know how long a request would take. Even though the two servers perform the same on average, users will think the second one is slower because of how it seems to randomly perform.

The moral of the story is that if you give an average without standard deviations then you’re totally missing the entire point of even trying to measure something. A major goal of measurement is to develop a succinct and accurate picture of what’s going on, but if you don’t find out the standard deviation and do at least a couple graphs then you are not gaining anything from the process. There are other thing though that you must be aware of when testing your system. A big one is Confounding

The idea of confounding is pretty simple: If you want to measure something, then don’t measure anything else.

An example. Imagine that someone tried to tell you that you needed to compare a bunch of flavors of ice cream for their taste, but that half of the tubs of creamy goodness were melted, and half were frozen. Do you think having to slop down a gallon of Heath Crunch flavored warm milk would skew your quality measurement? Of course it would. The temperature of the ice cream is confounding your comparison of taste quality. In order to fix the problem you need to remove this confounding element by having all the ice cream at a constant temperature.

#TODO add more information in how to avoid confounding.

Before you can measure something you really need to lay down a very concrete definition of what you’re measuring. You should also try to measure the simplest thing you can and try to avoid confounding.

The most important thing to determine though is how much data you can actually send to your application through it's pipe.

That’s all there is to performance measurement. Sure, “how much”, “data”, and “pipe” all depend on the application, but if you need 1000 requests/second processing mojo, and you can’t get your web server to push out more than 100 requests/second, then you’ll never get your JSP+EJB+Hibernate+SOAP application anywhere near good enough. If all you can shove down your DS3 is 10k/second then you’ll never get that massive 300k flash animation to your users in time to sell them your latest Gizmodo 9000.

#TODO add a good metaphore

He's read a lot, I'd trust him on these.

Now I know this was all a bit boring, but these fundamentals a necessary for understanding what we are actually doing here. Now onto the actual code and rails processes.

include::edge rails features.txt[]

So how do we profile a request.

One of the things that is important to us is how long it takes to render the home page - so let's make a request to the home page. Once the request is complete, the results will be outputted in the terminal.

In the terminal run

+ [source, bash]

After the tests runs for a few seconds you should see something like this.

Simple but efficient.

In addition we also gain three types of itemized log files for each of these outputs. They can be found in your tmp directory of your application.

The Three types are

Below are examples for Flat Files and Graphical Files

So what do these columns tell us:

Name can be displayed three seperate ways: #toplevel - The root method that calls all other methods MyObject#method - Example Hash#each, The class Hash is calling the method each * <Object:MyObject>#test - The <> characters indicate a singleton method on a singleton class. Example <Class::Object>#allocate

Methods are sorted based on %self. Hence the ones taking the most time and resources will be at the top.

So for Array#each which is calling each on the class array. We find that it processing time is 2% of the total and was called 15 times. The rest of the information is 0.00 because the process is so fast it isn't recording times less then 100 ms.

Very similar to the processing time format. The main difference here is that instead of calculating time we are now concerned with the amount of KB put into memory (or is it strictly the heap)

So for <Module::YAML>#quick_emit which is singleton method on the class YAML it uses 57.66 KB in total, 23.57 through its own actions, 6.69 from actions it calls itself and that it was called twice.

While the information gleamed from flat files is very useful we still don't know which processes each method is calling. We only know how many. This is not true for a graph file. Below is a text representation of a graph file. The actual graph file is an html entity and an example of which can be found Here

#TODO (Handily the graph file has links both between it many processes and to the files that actually contain them for debugging. )

As you can see the calls have been separated into slices, no longer is the order determined by process time but instead from hierarchy. Each slice profiles a primary entry, with the primary entry's parents being shown above itself and it's children found below. A primary entry can be ascertained by it having values in the %total and %self columns. Here the main entry here have been bolded for connivence.

So if we look at the last slice. The primary entry would be Array#each_index. It takes 0.18% of the total process time and it is only called once. It is called from Object#make_random_array which is only called once. It's children are Kernal.rand which is called by it all 500 its times that it was call in this action and Arry#[]= which was called 500 times by Array#each_index and once by some other entry.

It's pointless trying to represent a tree file textually so here's a few pretty pictures of it's usefulness

#TODO Add a bit more information to this.

Now I know all of this is a bit dry and academic. But it's a very powerful tool when you know how to leverage it properly. Which we are going to take a look at in our next section

You end up dealing with a large amount of data whenever you profile an application. It's crucial to use a rigorous approach to analyzing your application's performance else fail miserably in a vortex of numbers. This leads us to -

I’m going to give an example methodology for conducting your benchmarking and profiling on an application. It is based on your typical scientific method.

For something as complex as Benchmarking you need to take any methodology with a grain of salt but there are some basic strictures that you can depend on.

Formulate a question you need to answer which is simple, tests the smallest measurable thing possible, and is exact. This is typically the hardest part of the experiment. From there some steps that you should follow are.

Note: Even though we are using the typical scientific method; developing a hypothesis is not always useful in terms of profiling. The argument against using an hypothesis is that it will influence your experimental design and doesn’t really prove anything.

There are a lot of great profiling tools out there. Some free, some not so free. This is a sort list detailing some of them.

SyslogLogger

SyslogLogger is a Logger work-alike that logs via syslog instead of to a file. You can add SyslogLogger to your Rails production environment to aggregate logs between multiple machines.

By default, SyslogLogger uses the program name ‘rails’, but this can be changed via the first argument to SyslogLogger.new.

NOTE! You can only set the SyslogLogger program name when you initialize SyslogLogger for the first time. This is a limitation of the way SyslogLogger uses syslog (and in some ways, a the way syslog(3) works). Attempts to change SyslogLogger’s program name after the first initialization will be ignored.

Sample usage with Rails config/environment/production.rb Add the following lines:

/etc/syslog.conf Add the following lines:

/etc/newsyslog.conf Add the following line:

Now restart your Rails app. Your production logs should now be showing up in /var/log/production.log. If you have mulitple machines, you can log them all to a central machine with remote syslog logging for analysis. Consult your syslogd(8) manpage for further details.

A Hodel 3000 Compliant Logger for the Rest of Us

If you don't have access to your machines root system or just want something a bit easier to implement there is also a module developed by Geoffrey Grosenbach

link to module file

Just put the module in your lib directory and this to your environment.rb