On 21 November 2016, I joined Redbubble as a web intern. My first surprise was meeting two other interns, Kirsten and Nick, who were starting their internships on the very same day, and Xinyi, who jumped on board as a data science intern the following week. At Redbubble, diversity is celebrated and individuals are welcome. Over the last few months, I have met people from all walks of life who work towards a common mission: to support independent artists and bring more creativity into the world. It is my personal belief that software is our most powerful means of achieving these goals. Through software, we are building more than just another online marketplace. Redbubble has grown into a community for
Introduction Hello. I thought it might be nice to share a story from the trenches, about how we identified a severe performance issue, and worked around it. This work relates to one of our background services called the Feed Service, which acts as our interface to Google Shopping. Each day Redbubble handles anywhere between 100K and 500K updates to art works, which need to be reflected in our Google Shopping catalogue. The catalogue currently contains tens of millions products, so the data to be processed and the number of API calls we need to do are non-trivial. We were having performance issues, where the message processing would periodically grind to a halt, running much slower than we would expect given our MySQL
The task Here at Redbubble we’ve been running Ruby on Rails since day one. We’re a small development team, so keeping up with even the latest stable release has been a struggle. Earlier this year we had a gap in product development and took the opportunity to move our stack forward. We’d been on Ruby 1.8.7 and Rails 2.3 for a year or two. After some investigation we decided we’d first move to Rails 3.0 which would make Ruby 1.9 an easier option. After significant library updates and code compatibility changes, we were ready to release Rails 3.0 on Ruby 1.8.7.
This is a tale of one of those times where it is actually useful to do code profiling and benchmarking. A bit of background: We’ve been in the process of upgrading our Ruby on Rails stack here at RedBubble, going from Rails 2.3 to 3.0, with an eye to moving forward to 3.2. Through this, to minimise the amount of change happening at once, we’ve stuck with Ruby 1.8.7, instead of jumping right to 1.9.3. When we rolled out Rails 3, we noticed a significant slowdown in the general performance of the site, even though the benchmarks we had run at the time indicated that it should be okay. It has been widely reported that Ruby 1.9.3 has in general,