Java Reference
In-Depth Information
same with long business forms. Other times, poor distribution of work can be
a case of a facade or command doing too much work. If a command's granu-
larity is too coarse, then meaningful reuse is significantly reduced. Figure 10.7
shows the impact of partitioning combined with specialization. In this case,
we've dedicated half of our service queues to managing large loads, and we've
partitioned the larger, 10-unit job into two smaller jobs.
1
1
1
1
1
1
5
5
Figure 10.7
With dedicated odd job service queues (here, Q1 and Q2), workload
partitioning can add balance to a system. This may be as simple as adding
commits to a longer transaction, if the application can tolerate the unit-of-
work implications.
1
1
1
1
Q
1
Q
2
Q
3
Q
4
Of course, we should reserve partitioning the workload for cases where the
partitioning makes sense structurally. Readability and ease of maintenance are
prices too high to pay for a slight improvement in performance. Also, transac-
tion partitioning should not break transactional integrity. For instance, let's
consider a business transaction—a bank account transfer, for example. A trans-
fer consists of a debit and a credit transaction. We should not partition the
transfer transaction into two because both things should succeed or fail in a
transactional unit. If either succeeds while the other fails, the bank or the cus-
tomer (or both) will not be happy with the results.
10.4.2
True load balancing
True load balancing involves distributing workload intelligently, based on an
individual system's capacity, workload, and performance, as well as the band-
width to the server. Earlier we mentioned round-robin scheduling. These dis-
patchers have been popular for three reasons:
The nature of web applications has been primarily static content, so the
jobs have been relatively uniform. With a uniform collection of identi-
cally configured servers, this type of algorithm does a decent job of uni-
form work distribution.
Round-robin load balancers are very fast. The same has not always been
true of more sophisticated true load-balancing dispatchers.
In general, job durations have been very short. In these instances, dis-
patchers have needed to make very fast decisions to avoid creating a
