Mr. Anderson

"Mr. Anderson" is a personal experiment with different approaches to handling high amounts of traffic with a slow persistence mechanism that cannot itself be changed. I wanted to do this for several reasons:

• It seemed like an interesting problem to solve.
• It allows me to try out several technologies/methodologies that I've been interested in for some time.
• It's good exercise in building systematic and comparable tests, presenting the results clearly, thinking of new solutions, etc.
• I sometimes encounter the opinion that the only solution to performance problems is by applying increasingly unreadable query optimizations, making the application harder to maintain. I think this viewpoint is mainly supported by the fact that it requires less time studying alternatives, so here we are :-).

Overview

The general setup consists of the follow parts:

• a REST API that functions as the persistence mechanism
• a Gatling load test that scales sufficiently to show the limits of all approaches
• various approaches I can come up with that each attempt to perform as well as possible on the Gatling load test

All variants must use the REST API as canonical source of truth for the state of the application, and a variants maximum performance is measured by the amount of requests/second it can serve the correct response to with a <800ms response time.

Initially I have the basic API and a straight pass-through PHP implementation (as a baseline). The load test consists of a series of reads of 1 random item per request. The API adds an artificial 100ms delay to each request.

Plan

My intent is to first add some variants that perform better than the baseline (ie: with simple caching, load balancing, etc). After that I can start ratcheting up the requirements of the test with stuff like:

• writes/state changes
• requesting lists of multiple items at a time
• types of items that incur an especially heavy computation or data transfer cost to display
• randomized artificial reaction time delays/throughput limits in the base API
• adding relations between items and querying on those relations
• etc.

After each addition I can work out how to let the existing approaches deal with it and possibly add new approaches, if they provide a good solution and/or interest me.