Performance and Scalability

Recall HopPress’s performance and scalability requirements:

• Performance: When a reader requests a published post, HopPress must return the response in under two seconds.
• Scalability: HopPress must continue to meet its two-second response-time target as the number of simultaneous readers grows from 50 to 500.

We designed the database schema, and its indexes, with these requirements in mind. You cannot tell from the schema whether HopPress meets them. You have to run the application and measure its performance under the conditions the scalability requirement specifies.

Measuring performance

Performance is usually measured with the following metrics:

Response time is the time between a client sending a request and receiving the complete response. It is what the reader experiences. It includes the time the request spends on the network and the time it spends waiting to be handled.

Latency is the part of the response time that is not spent processing the request. It includes the time the request and response spend on the network and the time the request spends waiting to be handled. The request is latent in the system during that time, which is where the name comes from. Service time is the time the server spends doing the work needed to process the request and produce a response. Response time is latency plus service time.

Throughput is the number of operations (records, tasks, requests) the system completes per unit of time, usually per second.

Scalability and load

Scalability is the system’s ability to continue meeting its requirements as it grows.

A system grows in more than one way. HopPress’s requirement names one of them: more users, from 50 readers to 500. Data can grow too: tens of thousands of posts over a few years, which is the growth we designed database indexes for. Features can grow, so that each request does more work than it used to. A system can scale well against one kind of growth and badly against another.

Scalability is not a quality you can measure on its own. It is a statement about how the performance metrics behave as load changes.

Load is the amount of work a system is being asked to do. An example of load is requests per second arriving at a server. But there are other, more context-specific types of load, such as:

• The ratio of reads to writes at a database. A database that serves a hundred reads per write is under a different kind of load from one that serves one read per write, even at the same number of requests.
• The number of simultaneously active users in a chat room, since each one receives every message.
• The hit rate on a cache, since every miss becomes a request to whatever is behind the cache.

Check HopPress’s performance and scalability

We will measure response time under different loads and check the measured response times against the two requirements above. To do that, we will run a load test against the deployed application.

A load test runs the deployed application under a controlled amount of traffic and records how it responds. A load-testing tool for HopPress simulates a chosen number of readers. Each reader requests the list of published posts and individual posts, with time to read between requests. At any moment, some readers are waiting for a response and some are reading. The chosen number of simulated readers is the load. The tool records the response time of every request.

We run the test at several loads. The scalability requirement gives the range: from 50 simultaneous readers up to 500. At each load the tool runs for a few minutes and collects thousands of response times.