performance Never Query the Same Thing More Than Once In a recent post, I talked about how I used Postgres DISTINCT ON to remove a pesky N+1 query. That was actually one of the final touches in immproving the Graphics#index action for Box Out. Prior to that, I whipped together a
performance Resilience in Ruby: Handling Failure For the second half of 2014 and 2015, most of my time at GitHub was spent working on moving the notifications feature off the primary MySQL cluster on to a new MySQL cluster and making the feature resilient to failure of that cluster. When
performance Fewer and Faster Sometimes I feel developers think that performance is a dark art. It is not. In my experience, well performing systems come down to this: fewer and faster. If you are doing something a lot, do it fewer times. If you are doing something that
performance Anti-Decay Programming de•cay noun - the state or process of rotting or decomposition. Let us kick off the new year with a lovely post on decay. All systems decay. Even when you continually work on improving the system, it decays. That said, in my experience,
performance Database Performance Simplified I have been fortunate enough to work on a few high throughput applications (Words with Friends, GitHub.com, Gaug.es, etc.; hundreds to thousands of requests per second) in my life where a database was the bottleneck. I am far from an expert on
performance All Requests Are Not Equal The norm for rate limiting these days seems to be based on the number of requests a consumer can make in a given time window. The problem with this is that all requests are not equal. Some requests are more expensive than other requests
performance Analytics at GitHub In the interest of getting back into writing, I want to break the seal with a simple “what have I been up to and thinking about lately” style post. Hopefully future topics will be more focused and frequent. For the past year, I have