I’ve been working a lot on getting MoosTrax ready for the App Store and the latest beta adds a lot of great features.
The beta is still open, so send an e-mail to moostraxsupport@gmail.com to join.
I just got a new iPhone 4 with iOS4…and it supports background location updates! I’ve decided to bring MoosTrax back to the iPhone.
I’m looking for beta testers…and then soon I’ll be pushing it to the App Store.
Please e-mail moostraxsupport@gmail.com with your iPhone’s UDID.
For information on finding the UDID, go here: http://www.geekology.co.za/blog/2009/07/how-to-check-your-iphones-udid-from-itunes/
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.
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)
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.
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 |
Average Latency: 123ms
Requests per second: 385 r/s
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/ |
Average Latency: 90ms
Requests per second: 1100 r/s
Average Latency: 2235ms
Requests per second: 44 r/s
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
One comment so far, add another ▶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 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.
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 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 |
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
2 comments so far, add yours ▶Since Apple launched the iPhone in 2007 there has been an unprecedented growth in the mobile phone market. From new advances in hardware, such as touch screens, to operating systems mimicking the full power of a desktop computer. Never has a smartphone been able to penetrate the demographics of 10 year olds, to teenagers, or mom and dad — until the iPhone.
There are now hundreds of thousands of applications built for mobile phones, with every use case you can imagine. But even with the growth and advances of the past few years, the industry is still in its youth.
Apple, with its enormous success, is still constantly on the front page because of its questionable practice — sole control of the iPhone platform. Unlike desktop operating systems, such as Windows or Mac OS X, where the user is in complete control of the operating system, the iPhone is a jail, with Apple deciding what can come in and go out.
The App Store, the only way for a developer to target an iPhone, or a user to install an application on the iPhone, is in constant censorship mode. Certain API’s are not allowed and questionable content is put to rest.
It is time that Apple realizes that it is not only the hardware in the iPhone, or the software that powers it, that makes it a powerful force in the mobile phone market. The power is in the apps, the platform, and in the imaginations of developers.
Even though there are many applications for the iPhone, there could be so much more. The iPhone is a powerful device that can be used to provide a platform for mobile applications in every industry possible. Medical, industrial, retail — the list goes on. But as long as Apple is in control of what happens on the iPhone, developers will never be able to harness the full potential of such a beautiful device.
Apple now has the ability to turn the iPhone, and the new iPad, into a commodity device. The PC of the mobile world. My intuition tells me that Apple won’t let this happen. They prefer to maintain complete control of their platform, and while making it a premium and luxury item, they stop it from attaining the growth that it most definitely can achieve.
The future is in Apple’s hands — and they have the ability to make it an awesome place.
Leave the first comment ▶
Powered by WordPress
My Google+
