9.3 Dynamic Capacity Requirement Pattern

9.3 Dynamic Capacity Requirement Pattern

Basic Details

Related patterns:	None
Anticipated frequency:	Up to two requirements
Pattern classifications:	None

Applicability

Use the dynamic capacity requirement pattern to specify the quantity of a particular type of entity for which the system must be able to perform processing at the same time. It is intended primarily for the number of simultaneous users a system must be capable of handling. It also suggests what do to when too many users come along at once.

Discussion

Specifying dynamic capacity is difficult, unless you have an existing system from which you can obtain figures. It doesn't help developers, except as a rough idea of scale. It comes into its own only when sizing hardware, after the system has been built. Demanding that a system be scalable is much more valuable and can be done instead of demanding a particular capacity level-see the scalability requirement pattern in Chapter 10, "Flexibility Requirement Patterns." Nevertheless, the topics discussed in the "Extra Requirements" subsection are well worth thinking about. Those requirements are often more useful than a dynamic capacity requirement itself-in particular, being able to exert control on the load imposed on your system. A Web site is open for the whole world to come and visit, but if even a small country turned up all at once, you'd be trampled underfoot unless you took precautions.

You can calculate an expected number of simultaneous users using a sizing model, but producing a decent estimate is tricky and takes a lot of care. You need to work out how an average user behaves: when they visit, how long they stay, which functions they use (and how many times). If your users are distributed across multiple time zones, take into account what percentage of users reside in each time zone-and adjust their visit times to the system's local time zone.

Content

A dynamic capacity requirement should contain these items:

1. Type of entity What sort of thing are we stating capacity for? In the case of simultaneous user capacity, this is either all users or just one or more class of users (for example, customer). If two different user classes behave in very different ways (that is, place very different levels of demand on the system), treat them separately-or else we're adding apples and oranges. For a system driving a Web site, two fundamental classes of users exist: external (customers and casual visitors) and internal (employees, and perhaps employees of partner companies). An internal user might impose a smaller load on the system (per minute) than an external user to whom we might, say, display fancy graphics. And we might have fewer internal users logged in at any one time, although it is important for employee productivity that the system has adequate dynamic capacity for them.

   Note that a dynamic capacity requirement doesn't concern itself with the duration of user sessions.

2. Number of entities How many must the system be able to handle at once?

3. Entity condition In what state must an entity be in order to count? What must they be doing to be regarded as dynamically using the system? For example, we typically count users who are logged in, actively using the system, or both. Define this carefully and explain it precisely, or else users who aren't dynamically using the system are likely to be included. In particular, users might leave the system without telling us (logging out); this is the norm for visitors to Web sites. Write an entity condition clause to exclude departed visitors from the count of dynamic users. The subject of what to do about users who don't log out (what we might call "stale" user sessions) is dealt with in the "Extra Requirements" and "Considerations for Development" subsections of this pattern.

4. Duration of peak, if relevant Some systems have peaks of activity that last only a relatively short time. If so, describe the nature of such peaks-what causes them, when, and for how long-because it might be possible to take steps to squeeze the best possible performance from the system while peaks last (by "clearing the decks" so that the system has as little other work as possible during these times). If this item is omitted, the system must be able to maintain this capacity level all the time it is running.

5. Concessions during peak period If we're specifying dynamic capacity for a peak period (that is, short continuous duration), what concessions in other areas (in functionality and/or performance) can be made to help boost dynamic capacity?

6. Achievement timeframe By when must the system be able to cater for this capacity level? If this isn't stated, it's reasonable to assume the system will cater for this capacity level from the moment it is installed and for ever thereafter.

Template(s)

Open table as spreadsheet

Summary	Definition
Simultaneous «Entity type» capacity	The system shall be able satisfy «Entity count» simultaneous «Entity type»s «Entity condition statement» [«Duration of peak statement»]. [«Achievement timeframe statement».] [«Peak period concession statement»].

Example(s)

Open table as spreadsheet

Summary	Definition
Simultaneous customer capacity	The system shall accommodate 100 customers logged in and active simultaneously. A user is deemed to be active if they have submitted a request to the system in the past five minutes.
Peak customer capacity	The system shall accommodate 200 customers logged in and active simultaneously when tickets for a popular concert go on sale-from half an hour before the published sale time until two hours afterwards. The definition of active customer is as given in the previous requirement. During a popular concert initial sale peak, it is acceptable for secondary services offered by the Web site (including any involving large downloads or the streaming of audio or video) to be shut down. It is also acceptable to prevent internal users from accessing any functions that involve intensive processing.

Extra Requirements

A dynamic capacity requirement could have the following kinds of extra requirements-though they are all useful in their own right, and they can be specified even if you decide not to specify a dynamic capacity requirement at all:

1. Limit the number of users allowed in at once. This is usually achieved by preventing someone logging in if there are already at least a certain number of users logged in. This scheme can be refined to treat classes of users (or specific users) in different ways. For example, when the system is busy, we could let in only high-priority users.

2. Consider ways to reduce the load on the system imposed by internal users at times when it's exceptionally busy. Perhaps we could arrange for intensive work to be done at times of low external load. You could require the ability to temporarily disable functions that cause intensive processing.

3. A monitoring function to show the number of users currently active is always useful. This could show how many users are being handled by each server machine, and how many users of each type. It could let you dig down and view information on a selected individual session (start time, time since last request, user type, functions accessed). But be careful what you ask for, because it could be costly in development effort and its potential impact on performance. System monitoring is discussed further, with an example requirement, in the "Attack Direction 6: Duration of Failures" section of the availability requirement pattern later in this chapter.

4. Add one or more inquiry or report to show the number of active users over time, and perhaps also according to time of day (in order to identify peaks).

5. To help achieve a dynamic capacity requirement, developers might free up valuable system resources used by users who appear to have gone away. This, of course, is an implementation matter that doesn't concern the requirements. But it could have consequences the user might notice if they do return. They might be forced to log in again, or details of what they had done in the session might be lost, or their first response might be a little slower than normal (while the system fetches the details of their session and allocates any resources the session needs). If these sorts of consequences are unacceptable, write requirements to prevent them. But bear in mind that by doing so, extra hardware (or other steps) might be needed to achieve the dynamic capacity goals.

6. Demand a function to forcibly eject (log out) a selected user. This could be accompanied by a related function to bar a selected user, to stop them coming back. Neither of these functions directly affect dynamic capacity, but they can help if a particular user's actions are imposing a significant load on the system (either by accident or maliciously).

7. Raise an alarm if the number of simultaneous users exceeds a set number. You could ask for the ability for several different thresholds, each with its own alarm severity.

8. A sophisticated system could let a system administrator tinker with rules for allocating user sessions to machines, to give certain users (or types of users) better performance. This can also allow the load on a machine to be reduced, preparatory to shutting it down (for example for maintenance or upgrading). However, features such as this stray close to prescribing solutions: they are hard to specify without making assumptions about the nature of the solution.

Most of these are features for observing how well the system is performing, and for controlling it in order to squeeze maximum performance from it. The scalability requirement pattern (in Chapter 10) discusses further measures that contribute to achieving high dynamic capacity, such as the ability to add resources (server machines, for example) dynamically.

Considerations for Development

Consider how to deal with "stale" user sessions (again, where the user has departed without logging out). If a user session takes up precious resources, there are two approaches to making the most of them. First, they can be freed up by forcibly ending the session, which could inconvenience the user if they attempt to return shortly after. Second, we could store the session details elsewhere (such as in the database) so that the session can be revived if the user does come back.

Make provision for processing load to be spread across multiple server machines so that the system's dynamic capacity isn't held hostage by the performance of a single machine and whether that one machine can satisfy a given dynamic capacity target. Again, this says that scalability is usually more valuable than being able to achieve a particular performance goal. What would happen, for instance, if the volume of business turned out to be larger than anticipated? It's better to be able to react positively than to throw up your hands and plead that the system performs as asked for.

Considerations for Testing

Any dynamic capacity target (such as the number of users logged in simultaneously) is likely to be so high that imposing this load manually will be difficult. After all, if the target is small, there's little point in the requirement being there. A test team (even if it conscripted extra volunteers) has better things to do than trying to manually replicate the activity of a collection of users twice its number. The only option is to use software to simulate this many users. There are products for this purpose, and it's easier to buy one of these than to embark on developing software in house to do the job.