Here at Salsify, many of our customers regularly import large amounts of tabular product data into the system. This data needs to be sorted prior to being handled by different parts of the import process. Since we are running on Heroku, memory is a scarce resource. Sorting these arbitrarily large tabular data files requires great care. Reading all of the data into memory at once can result in extremely long execution times due to increased pressure on the Ruby garbage collector and can starve other processes on the same system of memory.

We needed a way to sort large files using a predictable amount of memory. Big data technologies like map reduce were overkill for our data scale. Creating an offline-sort gem to do this turned out to be quite the adventure and forced me to dig deeper into how Ruby manages memory, ultimately requiring a specialized heap implementation.

At Salsify we run most of our Ruby on Rails based infrastructure in Heroku. We recently switched our Puma web workers over from Heroku 2X dynos to more powerful Heroku PX dynos and saw dramatic performance improvements: a 51% reduction in mean response time and a 59% reduction in 99th percentile response time. Based on this we did some experiments running our more memory/CPU intensive Delayed Jobs on PX dynos and saw a similarly encouraging 43% reduction in mean job execution time and 66% reduction in 99th percentile job execution time. This was great for a proof of concept, but only one of the eight cores on the PX dyno was being used. In order to take this to production in a cost-effective manner, we had to figure out how to utilize all of the cores on the dyno.

---

At Salsify, we manage the flow of product information between manufacturers, and distributors through to large retail outlets such as Walmart and Google Shopping. Our flexible schema allows users to describe their products however they see fit. We store product attributes in a single table, but each product attribute has a potentially different data type and associated application-specific logic. 

When debugging software, particularly if it's code you didn't write and aren't familiar with, one of the hardest parts can be just determining where to start. Without the right context, you can end up chasing red herrings all over before finally tracking down the underlying problem. Well-placed log messages can help provide that context, saving that time and frustration. In this post, we'll look at adapting a logging technique employed by many Node tools on the command line for use in an Ember.js app in the browser.

Salsify is a multi-tenant SaaS product information exchange platform hosted in Heroku. We utilize delayed job extensively for long running tasks like import/export/search indexing/etc. One of the features we've grown to love about delayed job is its extensibility via plugins (see our other posts). Recently, an increasing number of job workers have been exceeding their dyno memory quota**, and consequently suffering serious performance degradation. While we are always working to improve our code performance, we thought it would be nice to have a mechanism for euthanizing workers that are unrecoverably exhausted. Enter the DelayedJob::YouthInAsiaPlugin. 

Over the past few months at Salsify we've spent some time exploring Ember.js and incorporating it into parts of our front-end. There's a lot to say on the topic, but today we'll just be taking a look at one of our first forays outside of the land of Ember's baked-in pieces: automatically generating breadcrumbs based on a user's application state.

Most Rails developers quickly learn that minimizing the number of database queries by properly specifying eager loads is critical for good application performance. Unfortunately specifying eager loads is error prone and can cause encapsulation problems. In this post we'll explore having Rails automatically handle eager loads.

At Salsify we write lots of Capybara integration tests of our single-page app. These tests are a key part of the infrastructure that allow us to move fast and refactor without break anything. Unfortunately as we added more and more tests we started experiencing sporadic hangs and database deadlocks while tearing down tests. After some investigation we figured out the problem was our JavaScript client making AJAX requests to our Rails server during the test teardown process. This post details our journey to stamp out these problems and get our tests running reliably again.  

I wanted to share a bit of information that we found interesting when writing active record migrations on tables leveraging STI (Single Table Inheritance). We came across a not so obvious gotcha with STI models re-defined in migration classes and wanted to explore our thought process while solving the subsequent problems.

Previously we blogged about eager loading calculations with database views in Rails to avoid running lots of database queries. The approach we described really only works if your SQL is fairly static and you don't mind creating database views for each of your calculations. In this post we'll explore an alternative approach that avoids these issues by not using database views. First let's quickly recap the problem...