The concept of good performance versus bad performance has struck me as a little too vague for a while. We had this problem at another ecommerce shop during design and code reviews – “does this perform well?” – but too often it was driven by gut instinct or some held assumptions about a particular technology. There is nothing wrong with gut instinct; it’s a key to being able to make decisive decisions, but maybe not the best for making a series of informed decisions to improve a product or delivery to a customer over the long term.

Serendipitously, last fall I opened of a copy of Communications of the ACM and found a great two part series on “thinking clearly” about performance which really helped clarify concrete items to look at from a design and architecture view (I like metrics, so that helps.)

From there I was able to help our team start looking less at a general performance feeling, but considering real response time and throughput to understand concurrency and capacity.  These concepts present a dichotomy in traditional computing architectures so dissecting each separately, and then bring them back together is helpful.  The links below present this much better than I.

On the web, and especially ecommerce, we have to focus a very critical eye on the whole delivery chain to the customer/user/browser: First Byte server response times, content download, load distribution, CDN configuration, etc.

Over the years I’ve seen very smart developers join our team that simply haven’t had serious web exposure and have been more concerned about a LINQ operator than the fact that there is a queuing delay at the service layer or the JavaScript files are gigantic and not compressed (as a really simple example and not to discredit troublesome code). Or the alternate, when there is too much premature optimization done and project delivery is thrown off.

We had a great peak season from a technology perspective so I want to share these articles as much as possible.