What's up guys? This episode on GoRails, we're going to talk about the performance on gorails.com. This is a question that came up on the forums recently about, you know, what are the tactics that I use to make gorails.com fast, and by any measure, I don't think GoRails is very fast. It's definitely faster than your average site, but that's definitely not in the 150 ms or less to glass measurement, which is the measurement used for saying: If you're 150 ms or less, generally that's going to appear to human beings instantaneous. GoRails isn't quite that fast but it's pretty fast, so we're going to talk about all of the different things that come into play to make GoRails as fast as it is, lots of improvements to make but we're going to talk about the ones that I've done so far.
So step number one is to simplify the amount of queries that you do. Keep your pages as simple as you can, that will help improve the performance at the database level. Now, that is even tricky on it's own, because database queries will show up with ActiveRecord saying: Well, this ran and it only took 3 ms. Well, it's not quite the case, because ActiveRecord actually has to take those results, put them in memory, then it has to convert all of that stuff into ActiveRecord objects, then you have to convert that into html and so on. It's a lot more work than the performance numbers of 3 ms of query time show in your logs, so you have to be careful with that, and that means that doing fragment caching comes into play significantly for performance when you're generating html server side. So when you're fragment caching, you want to make sure one of these records like this is cached into rails cache, but you also want to make sure that the rails cache is configured to save either until like redis or memcached, and the reason for that is because with those, you're saving the cached memory, so it's very quick to access, if you use the default cache, actually you have to write to your hard drive SSD, now SSDs are a lot quicker but they´re not still anywhere near as fast to and from memory, so if you can figure your rails cache to point to one of those two external services, you´re going to get a speed improvement for that, which is what I do. Now to take your fragment caching to another level, you can do rush, which is a recent feature of rails that basecamp talks a lot about, and it's really the concept of recent questions on the dashboard here, this is a section of the five most recent questions, we can cache each one of those in a fragment cache, but we can also encompass into one fragment cache, and then bust the larger cache when there's a new question, or one of the old ones gets updated. This is really nifty because it allows you to say: Well we're only going to access the class once for this entire chunk, instead of accessing the cache five times or more for every one of those questions. So that saves a number of network calls between you and redis o you and memcached from five to one, so that's pretty fantastic as well. That is another layer of reducing the number of queries that you're doing in order to get better performance when you're caching even.
Transcript written by Miguel
Join 20,000+ developers who get early access to new screencasts, articles, guides, updates, and more.