chris moos's blog » ruby

AsyncRecord: Non-blocking database access for Ruby

Chris Moos — Tue, 22 Jun 2010 04:17:18 +0000

Two weeks ago I developed my first event-driven web framework for Ruby, Fastr. It helped me understand why running a web framework in an event loop is so natural.

As I continued to tackle more features in Fastr, it was time to tackle persistence — notably, database access.

AsyncRecord is/will be an ORM, similar to ActiveRecord — with one major difference — it doesn’t block. AsyncRecord currently uses em-mysql to access a MySQL database.

How it usually works

In most ORMs, when you attempt to access the database, everything in that thread will block until a response is received. This means that you waste time — just waiting. The CPU may be idle, but you cannot handle any more requests. (Typically you start multiple instances of your application to get past this, unfortunately each instance requires more resources on your server)

How AsyncRecord works

When you access something in the database with AsyncRecord, the request is sent to the database server, but control returns to the application immediately after the packet(s) are sent. When the server responds, which could be 20ms or 200ms later, a callback that you specify is invoked.

One important thing about accessing a database asynchronously, especially in web frameworks, is the ability to defer a response. Fastr has built-in support for deferred responses, a-la EventMachine/Thin.

A deferred response is when you tell the web server that you will send data to the client some time in the future, and the server is free to handle more requests until you are ready to respond.

Benchmarking

As I was implementing AsyncRecord, I knew it would be faster — but I wasn’t sure by how much. I setup a very simple Rails 2.3.5 application, as well as a Fastr application (from the latest source).

My goal was to make an application that has a single page, which shows 5 usernames from the database.

Rails controller:

1
2
3
4
5
6
7
8
9
10
11
12

class MainController < ApplicationController
def index
users = []

User.all(:limit => 5).each do |user|
users << user.username
end

headers['Content-Type'] = 'text/plain'
render(:text => users.join("\n"))
end
end

Fastr controller:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class MainController < Fastr::Controller
def index
defer_response(200, {"Content-Type" => "text/plain"}) do |response|

User.all(:limit => 5) do |users|
users.each do |user|
response.send_data("#{user.username}\n")
end
response.succeed
end

end
end
end

The Numbers

Fastr

Average Latency: 123ms
Requests per second: 385 r/s

Rails

Average Latency: 2040ms
Requests per second: 42 r/s

The tests were performed using JMeter. 100 concurrent requests (10 requests per connection).

I also ran some tests using apache bench, here are the results:

1	ab -c 100 -n 1000 http://127.0.0.1:5000/

Fastr

Average Latency: 90ms
Requests per second: 1100 r/s

Rails

Average Latency: 2235ms
Requests per second: 44 r/s

Conclusion

I am extremely happy with what AsyncRecord can do — and I hope to make it even better. I will be moving it out of Fastr and into its own project soon.

Fastr GitHub: http://github.com/chrismoos/fastr

Fastr – A Web Framework for Ruby

Chris Moos — Wed, 09 Jun 2010 04:12:06 +0000

Foreword

Every month I go on a binge and learn something new. The most recent binge resulted in a new web framework, called fastr.

I’ve always used Rails when I needed to create a web application in Ruby, but despite how great it is to code in, the performance and concurrency is not up to par.

Don’t get me wrong — Rails can scale, but it is not inherently very good when it comes to an individual instance’s performance. While this is hopefully changing in Rails 3, I wanted to see what kind of concurrency and performance I could get out of a simple EventMachine web application. Thus, fastr was born.

Fastr’s Architecture

Fastr is nothing special. It is an extremely simple MVC style web framework, similar in configuration to Rails.

What makes it different though, is how it handles requests and responses.

The core of fastr runs on an EventMachine reactor, which is basically just a big event loop. EventMachine is very capable of maintaining thousands of connections in one instance. This is great when you want an application that supports Comet and chunked responses. There is very minimal overhead in having thousands of connections that have occasional data flowing through.

EventMachine and Fastr also support the ability to defer a response until a long running task finishes executing. This is nice because it won’t block the rest of the application. The only catch is you are limited to EventMachine’s thread pool size, which I believe defaults to 20. You can always up this number though, if you want.

Routing

The routing is very similar to Rails, an example routes.rb file looks like this:

1
2
3
4
5

router.draw do |route|
route.for '/:controller/:action'
#route.for '/home/:action', :action => '[A-Za-z]+'
#route.for '/test', :to => 'home#index'
end

Controllers

Controllers are simple, with just a list of actions that are called based on the route. Actions should return a valid Rack response. There are convenience methods in the controller that help in creating Rack responses.

The nice thing about the controllers in Fastr is that you can defer responses with ease. Here is an example of a deferred response:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

def long_running_task
defer_response(200, {"Content-Type" => "text/plain"}) do |response|
puts "in our deferred response...now we can do cool stuff!"
response.send_data("hey\n")

long_task = proc {
log.debug "Sleeping for 5 seconds...but this won't block other requests"
sleep(5)
log.debug "Finished sleeping, returning response to client."
return "finished"
}

callback = proc { |result|
log.debug "Callback result: #{result}"
response.send_data("#{result}\n")
response.succeed
}

response.task(long_task, callback)
end
end

The alternative render methods also exist, where you can render a HAML template or just text:

1 2	render(:text, "Hello, world!") render(:haml, :template => "index") # this searches for index.haml in your app/views/ folder

Future

For now, fastr is just a toy framework for me, that I hope to share with anyone interested in learning about building web frameworks.

I intend to start writing some tests as well as making fastr more robust. I don’t mean to displace any other Ruby web framework, but as I learn with fastr I hope to contribute what I learn back to projects like Rails and Sinatra.

Also, I’d like to get em-mysql or equivalent integrated so that you can really enjoy a event-driven web framework — event with database access.

Check out the GitHub page for more examples on getting fastr up and running.

GitHub: http://github.com/chrismoos/fastr

MoosTrax Ruby Library

Chris Moos — Mon, 23 Feb 2009 21:28:35 +0000

You can now access MoosTrax with Ruby.

Install the gem

1 2	$ wget http://www.moostrax.com/static/MoosTrax-0.1.gem $ sudo gem install MoosTrax-0.1.gem

Try out this demo script

make sure to fill your API_KEY in.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

require 'rubygems'
require 'moostrax'
require 'time'

def get_local_date(date_str)
Time.parse(date_str + ' UTC').getlocal.asctime
end

mt = MoosTrax.new('API_KEY')

begin
devices = mt.devices
devices.each do |device|
info = mt.device_info(device)
puts "Device ID: #{info['device_id']}\n"
puts "Device Name: #{info['device_name']}\n"
puts "Last Contact: #{get_local_date(info['last_contact'])}\n"
puts "Date Added: #{get_local_date(info['date_added'])}\n"

location = mt.location(device)

puts "Most Recent Location: #{location['latitude']}, #{location['longitude']} #{get_local_date(location['date'])}\r\n"

history = mt.history(device, Time.now-86400, Time.now)
puts "Number of location updates in past 24 hours: #{history.length}\r\n"

puts "First Location in History: #{history[0]['latitude']}, #{history[0]['longitude']}\r\n" if history.length >=1

puts '------------------------------------------------------'
end

rescue MoosTrax::APIError => e
puts "Unable to access MoosTrax: #{e.message}"
end

For more information, check out the Developer API Wiki.