Clustrix presented a RoR benchmark at Percona NYC where the Clustrix database outperformed and out-scaled MySQL

1. Breakthrough Scalability
for Ruby on Rails with MySQL
How the Clustrix Database scales Ruby on Rails
Neil Harkins Clayton Cole
Performance Test Engineer Software Deployment Engineer
Clustrix Clustrix

2. What is Clustrix?
Clustrix is NewSQL: PLUS…
• Scalablility and Fault-Tolerance…  Distributed query processing
without sacrificing ACID  Online schema changes
compliance.
 Multi-master replication slave
• Drop-in scalable replacement for  Multi-binlog replication master
MySQL (dump, restore, change the
ip address!)  Fast Parallel Backup/Restore
“Radical Scalability, Radical And now…
Simplicity”  DBaaS via partnerships with
multiple Cloud/Hosting Providers
2

3. The Clustrix Database: Previous Benchmarks
October, 2011:
Percona-Clustrix TPC-C Evaluation
Compared:
• Clustrix 3/6/9 nodes
• MySQL w/ Intel SSD
• MySQL w/ FusionIO
Demonstrated how Clustrix provides
linear scale:
more nodes = more performance

4. Ruby on Rails: A popular web application framework
• Open-source “full-stack” web app framework
for the Ruby programming language.
• Uses Model-View-Controller (MVC) paradigm,
abstracts data store behind ORM (“ActiveRecord”)
lets you focus on your webapp’s features, not infrastructure.
• Philosophy:
• Convention over Configuration
• Don’t Repeat Yourself
• Quick Turnaround / Short Development Cycle
• Promises prototype -> full-featured website in record time
…and delivers.
• As of Feb 2012, Gartner estimates >235k websites use Rails!

5. What’s the catch? Does Rails scale?
“By various metrics Twitter is the biggest Rails site on the net right now.
… The common wisdom in the Rails community at this time
is that scaling Rails is a matter of cost: just throw more CPUs at it.
The problem is that more instances of Rails means more requests to your database.
… Once you hit a certain threshold of traffic, either you need to strip out
all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.)
or move the slow parts of your application out of Rails, or both.”
- Twitter Developer Alex Payne, 2007-03-29
http://tumblr.yasulab.jp/post/10271634919/5-question-interview-with-twitter-developer-alex-payne
The Answer lies in whether your database can scale
5

6. Our Goal: Prove that Rails can Scale
To run a performance benchmark that…
• Allows us to observe the database workload from a real-world webapp
“scenarios” written in Ruby on Rails,
• At a commercial Rails-hosting environment,
• Against both a standard MySQL server offered by that service, and the same
Clustrix nodes used by our various DBaaS partners.
…does such a benchmark already exist?
Our search resulted only in modules which could be used to measure timing, but
we did not find a comprehensive RoR simulation comparable to a TPC
benchmark.

7. Designing the Benchmark – keeping it real
Tacit Knowledge supplied some Ruby • BlueBox was our Rails-hosting
coders to write the benchmark in “The service offering physical MySQL
Rails Way”. servers and virtual Rails servers
 Cut out the View and Controller, • We then engaged with Percona to
concentrate solely on the Model review that the MySQL server
 Avoids complexities and latencies configuration is optimal.
associated with HTTP load testing
 Still uses the Rails “core”, in
particular ActiveRecord
 Tacit added a lot of “knobs” in order
to test different ratios of scenario
“ingredients”, etc.

8. Sample Scenarios used in the Benchmark
Tacit took the data model • Create User, optionally with metadata
located in other tables.
we created for an auction • Create Auction, optionally with url to a
application and created picture.
• View Auction with its most recent
13 scenarios for how comments.
user might interact with • Add Tags and/or Comments to an
Auction.
the site
• Bid on an Auction, Determine current
highest bidder.
• Generate “tag cloud” for items
recently commented upon.
• etc.. 8

9. Sample Schema for a Social-Media Auction website
This is the
relational database
model used to back
the site used for
this benchmark. All
relational, all ACID.

10. Sample Scenario: Ruby code snippet for creating a user
Ruby
lib/benchmark/scenarios.rb Sample SQL generated
# Create User with 2 Phones BEGIN;
def scenario_3 INSERT INTO users (created_at, email, first, last,
login, status, updated_at)
user = User.new(login: VALUES ('2012-04-17 22:08:01', 'bill@walker.biz',
"#{Faker::Internet.user_name}_#{Random.rand(65536)} 'Dillan', 'Hamill',
_#{Faker::Internet.user_name.reverse}", email: 'harrison_34356_ztem_sivart', 0,
Faker::Internet.email, first:
Faker::Name.first_name, last: '2012-04-17 22:08:01');
Faker::Name.last_name, status: Random.rand(0..5))
INSERT INTO user_phones (number, phone_type, user_id)
user.user_phones << UserPhone.new(phone_type: VALUES ('530-209-0599', 1, 4426);
Random.rand(0..1), number:
INSERT INTO user_phones (number, phone_type, user_id)
Faker::PhoneNumber.phone_number)
VALUES ('1-978-714-2317', 1, 4426);
user.user_phones << UserPhone.new(phone_type:
COMMIT;
Random.rand(0..1), number:
Faker::PhoneNumber.phone_number)
user.save
end
10

11. Test Hardware Setup: Clustrix vs MySQL
Clustrix MySQL Instance
CLX 4110 nodes that we • 8 cores (Quantity 2 of
formed into 3-node and 6- Intel Xeon 5450
node clusters, each with (3GHz, 12MB
• 8 Cores Cache))
• 48GB RAM • 128GB RAM
• 896GB SSD • 1.6TB of spinning
• 600GB HDD HDD space (12 x
• Clustrix VIP 300GB Seagate 15k
(software load RPM SAS)
balancer) • Hardware RAID 10
• Running Scientific
Linux 6.2
• MySQL version
5.1.61
• Settings tuned
H by Percona
o
s

12. Test Sequence
Ruby on Rails Benchmark
• Starts desired number of threads, connects
each to target DB system
• Each thread begins running the prescribed
workload during a warm-up period
• After warm-up, statistics collection is turned
on and test runs for a set time (10 minutes)
• Results of test are saved locally as a JSON
file

13. Benchmark Results: MySQL only
Summary:
• This graph shows throughput (TPS)
over a range of concurrencies
5,000 – 6,000 TPS @ 256 Threads • MySQL maxes out around a TPS of 5-
6k at concurrency of 256
• This drops down to 3-4k as TPS
3,000 – 4,000 TPS @ 1024 Threads
concurrency approaches 1024, a
1/3 decrease in performance
Put in perspective:
• 256 threads might represent a small
and growing organization
• 1024 threads might represent when
that site starts getting more popular

14. Benchmark Results: 3-Node Clustrix v. MySQL
• Same graph as before, now adding
Clustrix database
• Same axis, with greater scale
because Clustrix outperforms MySQL
• At 256 threads (MySQL’s peak),
8x TPS Performance @ 1024 Threads Clustrix performs 2.5x faster
• At 1024 threads, a 3-node Clustrix
Clustrix 3-Node
database achieves peak performance
of 30,000 TPS
2.5x TPS Performance @ 256 Threads
MySQL
But wait! There is more

15. Benchmark Results: Clustrix 6-Node, 3-Node, MySQL
Clustrix 6-Node • Again, same graph as before, now
adding a 6 node Clustrix database
• Clustrix has 15x performance of
MySQL at 1024 threads
15x TPS Performance @ 1024 Threads
• Concurrency reaches 45,000 TPS as
concurrency reaches 10,000
How’s that for scale?
Clustrix 3-Node
MySQL

16. Average Scenario Execution Time: 6-Node, 3-Node, MySQL
7 – 8 seconds @ ~9,250 Threads
2 – 3 seconds @ 1024 Threads
MySQL
Clustrix 3-Node
~0.1 seconds @ 1024 Threads ~0.7 seconds @ ~9,250 Threads
~0.1 seconds @ 256 Threads Clustrix 6-Node

17. Conclusion
• Ruby on Rails: Great rapid development framework for
the web
• MySQL & Rails: frequent development strategy
• Scaling limits for Rails = Scaling limits for MySQL
• The Clustrix database breaks through traditional Rails
limitations by providing:
 Linear scalability
 Drop-in replacement for MySQL
 Superior performance
 High availability and inherent fault tolerance

18. Breakthrough Scalability
for Ruby on Rails with MySQL
Thank you!
info@clustrix.com