Scalability has mostly been a factor of Hardware. But here I am trying to list down some of the Software Design Elements that will go a long way in deciding how scalable the application will be.
- Minimizing resource contention Contention for resources is the basic cause for all scalability problems. Insufficient memory, processor cycles, bandwidth, or database connections to meet demand would result in an application that cannot scale. For example, when performing transactions that involve resources that are scarce and thereby subject to contention, use those resources as late as possible. The shorter the amount of time that a process is using a resource, the sooner the resource will be available to another process. For example, return database connections to the pool as soon as possible.If possible, do not even use a contentious resource. Sometimes a process uses a transaction that does not require a resource when performing a function. For example, methods that require a transaction should be placed in a component separate from ones that do. As a result, you can avoid creating a transaction when it is not needed.
- Process Differentiation A process should never wait longer than necessary. Each time slice that a process is using a resource is a time slice that another process is not able to use that resource. One can place processes into two separate categories, synchronous and asynchronous.There are times when applications must perform actions synchronously. Some actions may need to wait for an action to return a result before continuing, or they may need to verify that an action was successful to ensure atomicity. That is, all of the actions associated with the operation must completely fail or succeed before performing another operation. However, when applications are limited in this manner, resources become a source of contention that negatively impacts scalability.One way to achieve scalability is by performing operations in an asynchronous manner. When operating asynchronously, long-running operations are queued for completion later by a separate process.
- Commutability The application design should try to incorporate the principle of Designing for commutability. Two or more operations are said to be commutative if they can be applied in any order and still obtain the same result. Typically, operations that you can perform in the absence of transaction are likely candidates. The less transaction oriented the operations are, easy it is to scale up the application.
- Interchangeability The whole idea here is to move the state out of the components. As you add more state to the componennts, they become less interchangeable. Requiring components to maintain state between method calls defeats interchangeability and, ultimately, scalability is adversely impacted. Instead, each method call should be self-contained. Store state outside the component when it is needed across method calls. When calling a method of a stateless component, any state required by that method can either be passed in as a parameter or read from the storage. At the end of the method call, preserve any state by returning it to the method caller or writing it back to the storage. Interchangeability extends beyond resource pooling. Server-side page caching for a Web application will most likely increase its scalability. Although personalization can give a user a unique experience, it comes at the expense of creating a custom presentation that you cannot reuse for another user.
- Partitioning The application will also look to partition resource and activities. By minimizing relationships between resources and between activities, one can minimize the risk of creating bottlenecks resulting from one participant of the relationship taking longer than the other. Two resources that depend on one another will live and die together. Partitioning of activities can help ease the load that you place on high cost resources. For example, using SSL entails a significant amount of overhead to provide a secure connection. As such, it is sensible to use SSL only for pages that actually require the increased security. In addition, Web servers dedicated to the task could handle SSL sessions.Transactions provide another opportunity for partitioning of activities. By separating methods that do not require transactions from those that do, you do not needlessly impose the overhead required for a transaction on methods that do not require one.However, partitioning is not always a good choice. Partitioning can make your system more complex. Dividing resources that have dependencies can add costly overhead to an operation.
Post a Comment