Wiki Home

Scalability Requirements

Namespace: WIN_COM_API
A place to discuss scalability requirements

There is a difference between scale and ?scalability. The scale of an application is it's size or its extent as possibly measured in a variety dimensions (see below). Scalability is the headroom available, and the cost of using up incremental headroom, at a particular scale, possibly measured in a variety of ways (again, see below).

Dimensions Of Scalability
Scalability is often qualified along specific ranges of factors, among which are the ability to increase:
  • total number of users,
  • number of concurrent users,
  • number of user's locations,
  • the extent and size of the data store,
  • the transaction volume,
  • the output volume,
  • and response time.
    Also worthy of scalability consideration are...
  • Adding new applications or customers to the system.
  • Horizontal Scalability -- AKA "rack density". Throw hardware at the problem. Typically easier and affordable than most forms of vertical scalability.
  • Vertical Scalability -- The ability to increase the capacity of existing hardware or software by adding resources - for example, adding processing power to a server to make it faster.
  • Hardware/software scalability metrics Here are some metrics to measure the levels of resource saturation:
    • CPU utilization Number of users supported versus CPU utilization
    • Memory Number of users supported versus available memory
    • Disk I/O Number of users supported versus number of disks
    • Network I/O Number of users supported versus wire speed of network

    Managing resources is typically not a big problem in small homogeneous environments. However when you must manage a diverse software base, a large number of users, and disparate user and service availability requirements, Scalability is a major concern.

    Scalability concerns always result from one form or another of unpredictable increases (or even decreases) in system load.

    Generally speaking, a well-designed multi-tier approach increases the scalability of an application. Partitioning functionality in tiers provides a relatively reliable pattern for scalability -- Basically you add servers, and re-balancing processing across data and business servers, to get a greater degree of scalability.

    It is wise to use testing to measure an application's scalability before exposing the application to the unpredictable increases in system load. Scalability is nearly always measured by evaluation or exploratory prototyping.

    Scalability isn't only a computer software and hardware issue. Consider also the related infrastructure, including people, space, communication channels, even things like the number of loading docks.

    Also consider the marginal cost of scalability. For example scaling from 30 to 40 users might require a much different solution from scaling, for example, from 60 to 70 users. The cost of scalability is often a step function, such that adding just a few new users may, at some point, require a completely different technology.
    It can also be helpful to collect statistics on the system performance (measured in response time, or better (but more difficult to measure), overall useability and utility) as a function of the scalability dimensions above. This information is often easy to collect over time and can be a great ally in board room discussions.
    Contributors: Steven Black
    See Scalability
    Category Requirements Category Performance Category Scalability
  • ( Topic last updated: 2003.10.26 12:39:20 AM )