Archive for August, 2009
What A Modern Rails Application Looks Like In Production
Yellow Lab is a Rails application. When we first started up we chose Ruby on Rails (Sensis generally uses Java) to see how using a dynamic platform would change our delivery patterns. Now that we’ve been running for a while, we wanted to share what our high level architecture looks like and the various components that make it up. We hope it is interesting to see what a live, enterprise, Rails application looks like when deployed, and if you have some ideas to share with us, we are always happy to hear them.
We find that simple systems are easier to build and understand, which make them easier to change, so with that in mind we are always striving to make things as simple as they can be, without being simplistic. Our setup is a fairly standard in modern web applications with a web server that receives client’s requests then passes those requests back to either the file-system (if static assets are requested) or to the application server which in turn pulls data from a database, a search engine or the file system.
The Bits And Pieces
- The Web Server (Nginx) – (pronounced as “engine X”) is a light weight, high performance web server/reverse proxy. We chose Nginx for it’s light footprint and easy configuration. It has served us very well and hasn’t got in the way of anything we’ve needed to do. If you are looking for a web server and you’d like to try something beside Apache’s httpd then Nginx is a great alternative.
- The App Server (A Bunch Of Mongrels) – Mongrel is our application server. If you are from a Java world you can think of it as Apache’s Tomcat for Ruby. We use Mongrel to host our Rails application and it does a fine job. Mongrel was the default deployment option for Rails until the original author, Zed Shaw, decided he didn’t want to support it any more and a competing technology, Phusion’s Passenger, came along. Passenger is the “preferred deployment setup for Rails” – it is under active development but doesn’t really offer us enough to switch from Mongrel. We’ll probably swap over to it, but we’re in no rush.
- The Meat And Bones (Ruby On Rails) – We are using the Ruby on Rails framework to build the business logic for the site. So, has it changed our delivery patterns? Yes, it’s made us faster. Some of it is probably due to the fact that we are a lab/test bed group, but RoR has certainly been a major contributing factor to allow us to get features into ‘production’ more quickly (there are some stories and learnings here, but we can explore that some other time). Ruby is a fantastic language to build web applications with and Rails leverages Ruby’s language features pretty well.
- The Database (PostgreSQL) – PostgreSql is a mature, open source database with clear licensing. If you haven’t looked at it, then you should. We use PostgreSql to store business listing data and user generated content (we are sooo web 2.0). Fairly straight forwards stuff. We also use a PostgreSql GIS extension, PostGIS, to generate reference data for suburbs that we use during our search.
- How We Find Stuff (FAST ESP) – All Sensis properties use FAST ESP (bought by Microsoft last year) for their search requirements. Being a test bed for new functionality (of which search is a major component), we use it too. In the open source world Solr (build on Lucene), Sphinx or Xapian may fill the same requirements. We make heavy use of FAST and many of it’s feature and there is much we can say about it as well as all the things we have learned about search from using it, but we’re trying to keep this short and sweet, so moving right along.
That’s our logical design, but physically we have two servers.
Why Two Machines?
Notice that one of our machine is completely devoted to FAST (our search product). While we could use just a single server for delivering search results we need the grunt power of a second machine when we “ingest” our data (load it) into FAST.
If you have a comment or suggestion about our setup or simply want to brag about showcase your own, please leave a comment, we’d love to hear from you.
Popularity
We’ve had a few comments and feedback emails about our voting system (or you can call it recommendations or even word of mouth) so I thought I’d take the opportunity to talk about it. Mostly the questions have been around how it works, why it works that way and what does it affect, so I’ll tackle these questions in this post.
How?
We use a +1 model, that is, each time a user votes for a business the total votes go up by one for that business. So the more votes a business has, the more people have said that they liked it. Each user is allowed to vote for a business only once (which is why you need to register to vote). This is done for integrity reasons. Our users told us that if they couldn’t trust the system, then it didn’t matter how many votes a business had.
Why?
The usual objection to this is that people want to vote negatively as well. On the surface this seems completely reasonable, but there are 2 main reasons why we didn’t. The first and biggest reason we went with a +1 model is that people are far more likely to give, and look for, positive ratings than negative. We’ve done our own research into this (which unfortunately I can’t go into) but others have shown that positive ratings tend to eclipse negative ratings. The second and lesser reason is that being a business directory, we need to be a little sensitive to those businesses.
It also makes sense if you just think about it – when you’re asking friends where you should go for dinner, your friends will tell you about places they like. They might occasionally tell you about places to avoid, but the recommendations far out number them.
So that’s why we’ve gone with a +1 model, after all Yellow Lab is an area to try things out.
What’s Affected?
At the moment the number of votes a business has won’t affect your search unless you explicitly say so – which is done by sorting your results by votes (instead of the default ‘best match’). We have had considerable discussion on whether the number of votes should influence the best match result – there are reasons for and against. Two of the stronger ‘against’ reasons are location searches (I want the closest, not necessarily the best) and reputation (did those 5 people that like that restaurant like the same food as you, etc.).
If you want to see what effect there is, you can compare these 2 searches for a cafe in south melboure: sorted by best match and sorted by votes.
So hopefully that’s given yo a little background on our voting system. if you’ve got any more questions or comments about it, feel free to ask them in the comments section.
Cheers,
Dan.
