Database Reference
In-Depth Information
Throughput can be determined by establishing the number of concurrent users or the maximum number of jobs
that the system/servers can handle. This measurement could be based on the following:
The interaction between the user and the application that has been mentioned in the business
requirements.
Length of this typical interaction to complete the request or job by the user measured as the
acceptable response time, which is measured in units of time.
Based on the preceding criteria, the throughput measurement based on the number of users could be
Throughput = the number of concurrent users (per requirements)
÷ UART (the user acceptable response time )
If this formula is applied to the current application or to the simulation model, then throughput of the system
could be measured for the application (which is the inverse of the preceding formula):
UART = throughput × the number of concurrent users supported
The throughput derived previously could be increased in several ways, such as the following:
By making changes to the application; normally an expensive process because it may result in
rewriting parts of or the entire application.
Increasing the capacity of the hardware running the application; a situation of vertical
scalability, which could also be an expensive process because hardware limitations could be
experienced again after the current estimated users have been reached and the business grows.
Clustering is probably the best opportunity in this situation due to the provision for horizontal
scalability. Clustering enables the administrator to meet the increased demand of users as
the business grows and requirements change (with higher numbers of concurrent users)
by adding additional nodes to the cluster to help scale the application. This is done while
providing the same amount of throughput and UART.
Once the clustering options have been decided, the next step is to determine how this will be done. It is
imperative to consider or create a goal that this activity will accomplish before establishing the best method
to incorporate it. It is often argued that maintenance should be simple; however, from an overall management
perspective, the ultimate focus of the operation is geared toward performance.
Although maintenance is an important feature, performance plays a more important role in this process.
Some options to consider during the clustering process are as follows:
Multiplexed: Do multiple copies of the application run on each of the nodes in the cluster?
Service oriented: Is the application designed in such a manner that it could be broken up into
several pieces based on functionality and mode of operation? For example, users could be
grouped based on functionality like accounts payable, accounts receivable, and payroll, all
based on the departments that will be accessing these functionalities. The other alternative is to
partition the application by the mode of operation like OLTP and batch or application behavior.
Hybrid scenario: Is a combination of the previous two options a way to get the best result of
both worlds? A possible combination would be to partition the application based on one of the
criteria best suited for the application and business, then to multiplex the partitioned pieces.
The first two preceding items are true and feasible most of the time in the case of a business application.
Because there are no specific protocols between clients, there is reliance on a central database server to serialize the
transactions when maximizing the overall throughput and offering a consistent view of the database to all clients.
This means that after the initial configuration, additional clients could be added without much difficulty, therefore
providing increased linear throughput.
 
Search WWH ::




Custom Search