sent back to the user. The number in each box is the number of requests per second (e.g., 200
RPS) that the module can process when tested in isolation.
Figure 2-1. Typical program flow
From a business perspective, the proprietary calculations are the most important thing; they
are the reason the program exists, and the reason we are paid. Yet making them 100% faster
will yield absolutely no benefit in this example. Any application (including a single, stan-
dalone JVM) can be modeled as a series of steps like this, where data flows out of a box
(module, subsystem, etc.) at a rate determined by the efficiency of that box. (In this model,
that time includes the code in that subsystem and also includes network transfer times, disk
transfer times, and so on. In a module model, the time includes only the code for that mod-
ule.) Data flows into a subsystem at a rate determined by the output rate of the previous box.
Assume that an algorithmic improvement is made to the business calculation so that it can
process 200 RPS; the load injected into the system is correspondingly increased. The LDAP
system can handle the increased load: so far, so good, and 200 RPS will flow into the calcu-
lation module, which will output 200 RPS.
But the database can still process only 100 RPS. Even though 200 RPS flow into the data-
base, only 100 RPS flow out of it and into the other modules. The total throughput of the sys-
tem is still only 100 RPS, even though the efficiency of the business logic has doubled. Fur-
ther attempts to improve the business logic will prove futile until time is spent improving the
other aspects of the environment.