An application can be made more efficient on a single system a multitude of ways. Chapter 11 covers many of them. For single-system scaling we want to discuss the main aspects of work distribution, both offloading to the client application and usage of multiple execution threads within the service.
Offload Processing to Client One of the first aspects that affect scalability is the work distribution between the client and the server. In general, increasing the per- centage of a transaction that can be executed on the client will allow a server to han- dle more transactions. Figure 10.3 shows the effect that moving work to the client can have, even in the presence of additional overhead. This leads to deciding on a thin client or thick client architecture. Thick clients are assumed to perform some application processing that would be done on a server in a thin client model. This means that the application designed for a thick client architecture will allow the
More work on single system
More systems working Multithread Multiprocessor Thick client Fast transaction Multimachine Multisite n-tier architecture Replicated services
servers to handle more transactions (the right side of Figure 10.3) than an equiva- lent thin client application.
But enterprise software is never about optimizing just one aspect of the overall sys- tem to the exclusion of all other aspects. Thick clients require that more software be deployed on the client system. In a large enterprise environment the additional cost of controlling and managing a software application installed on 20,000 or 200,000 systems may overwhelm the value associated with the application. Also, the tech- nique of splitting the work between the client and the server might be used to increase the number of servers that can be effectively applied to the work.
Today’s main approaches to thin-client computing are browser-based applications and server-based computing (for example, Windows Terminal Server and Citrix WinFrame.) Browser-based applications separate the display of the application from the business logic portion by having the server deliver HTML to the client browser
10 20 30 40 50 60 70 80 90 100 110 100 90 80 70 60 50 40 10 0 30 20
Client share of base transaction cost (%)
Number of transactions required to saturate server
Server share of total transaction cost (%)
Server shares Transactions
Base transaction cost = 1, Server capacity = 10 Additional server overhead cost = 10% of client cost
for rendering. The advent of ActiveX and Java applet support in the browsers also enables a distribution of additional work to the browser. Server-based computing is in many ways a return to the time-sharing systems of the past. In this case the appli- cation actually executes on a server, with the user connected using a generalized cli- ent. The main advantage of server-based computing is easier management of a centralized computing environment. Browser-based thin clients have an advantage in terms of their ability to support both a heterogeneous environment—browsers exist for all clients—and by not requiring the installation of application-specific software on the client. These advantages are critical when an application needs to grow beyond the enterprise and reach out into the Internet.
Multithreading and Multiprocessor Systems Another scalability technique is the support of multiple execution threads and exploitation of multiprocessor systems. We use the term thread as a generic term for executable work. Threads are operating- system-dependent and have different names by operating system; they are called
threads on Windows NT and Windows 2000, processes on Unix systems, and tasks on OS/390. Threads improve scaling on single-processor systems by allowing work to be done on one transaction while another transaction is waiting for I/O to complete or for some external event to occur. Threads are required to exploit multiprocessor systems, since what good are multiple-execution engines if you can only keep one busy? The easiest way to support multiple threads is to create small transactions that can be executed within an environment that exploits multiprocessing. By using small serv- lets and a Web application server, for example, you can get significant multiprocessor exploitation. However, it is critical that the servlets be designed so that multiple cop- ies can execute without causing them to conflict in accessing resources. Chapter 11, Performance Characteristics, covers the types of problems that can arise in multi- threaded programs.
Algorithm Choice Another program characteristic that can prevent single-system scaling is an algorithm that cannot handle the largest number of data elements. The work associated with most algorithms can be represented as a mathematical formula. For example, the bubble sort algorithm takes the order of n2 operations to sort n ele- ments. The heap sort algorithm requires n•(log2n) operations. Between the two
algorithms, heap sort is a better choice for sorting even a moderate number of ele- ments. Table 10.1 shows the time required to run bubble, insert, and heap sorts against different numbers of elements. (The code used to generate the table is included on the CD.)
But how does an application designer choose between two algorithms that require the same order of operations? This requires a deeper understanding of how the algo- rithm actually works. Each algorithm has both a fixed setup cost and a variable multi- plier. For example, one algorithm might take 100 seconds of setup and 0.1 seconds as a multiplier and another algorithm might have 1 second of setup and 0.2 seconds as
its multiplier. As is evident from Figure 10.4, the first algorithm is better for a large number of elements, while the second algorithm is better for a small number of ele- ments, with the crossover point being 1,000 elements. Software that needs to work well at both ends of the usage spectrum may need to choose which algorithm to use based on the number of elements being processed.
Table J.1 Time required for sorting (1000 is about 1 second)
Bubble Insert Hea
p 1,000 10 0 0 5,000 350 130 10 10,000 1,763 671 20 50,000 48,800 20,279 120 100,000 21,6362 91,822 270 1 10 100 1000 10000 2500 2000 1500 1000 0 500 Number of elements T ime in seconds
Comparison of high fixed cost algorithm versus high variable cost algorithm
High fixed cost High variable cost