Ajax on Rails

Chapter 9. Performance

This chapter takes the same approach to performance as Chapter 8 does for security. As with security, Ajax doesn’t fundamentally change the principles of web application performance—it just adds some new factors to the equation.

Ajax can be a double-edged sword with regard to application performance. On one hand, the main promise of Ajax from a user-experience perspective is that it will speed up interaction. Think about the typical “live search” functionality—before Ajax, you’d type a search query, submit the form, and wait for the results page to be returned. With live search, every new keystroke fires off an Ajax request in the background, so that by the time you’ve finished typing your query, the results are already in front of your eyes.

Well, that’s the idea anyway. The reality is often not so simple. Search is generally a computationally expensive operation—especially if you’re doing a full-text search over a large data set. The Ajaxified search dramatically increases the load on the search operation—instead of one search for “Ruby on Rails,” it would need to perform as many as 13 separate searches, one for each keystroke—and most of those queries will be ignored anyway. Unless your search infrastructure is prepared for the load, adding Ajax to improve performance might actually backfire, multiplying the number of expensive requests and causing the average response time to fall.

The point is that while Ajax is often a performance boon, it isn’t a silver ...