Information Technology Reference
In-Depth Information
energy management on battery-powered devices such as smartphones and lap-
tops. These questions apply whether the source of contention is the processor,
memory, disk, or network, and so we will revisit them throughout the rest of
this topic.
Scheduling policy is not a panacea. Without enough capacity, performance
may be poor regardless of which thread we run. In this chapter, we will also
discuss how to predict overload conditions and how to adapt to them.
Fortunately, you probably have quite a bit of intuition as to impact of differ-
ent scheduling policies and capacity on issues like response time, fairness, and
throughput. Anyone who waits in line probably wonders how we could get the
line to go faster. That's true whether we're waiting in line at the supermarket,
a bank, the DMV, or at a popular restaurant. Remarkably, in each of these
settings, there is a dierent approach to how they deal with waiting. We'll try
to answer why.
There is no one right answer; rather, any scheduling policy poses a complex
set of tradeoffs between various desirable properties. The goal of this chapter
is not to enumerate all of the interesting possibilities, explore the full design
space, or even to identify specific useful policies. Instead, we describe some of
the trade-offs and try to illustrate how a designer can approach the problem of
selecting a scheduling policy.
Consider what happens if you are running the web site for a company trying
to become the next Facebook. Based on history, you'll be able to guess how
much server capacity you need to be able to keep up with demand and still
have reasonable response time. What happens if your site appears on Slashdot,
and suddenly you have twice as many users as you had an hour ago? If you
aren't careful, everyone will think your site is terribly slow, and permanently
go elsewhere. Google, Amazon, and Yahoo have each estimated that they lose
approximately 5-10% of their customers if their response time increases by as
little as 100 milliseconds.
Would quickly implementing different scheduling policy help, or hurt?
How much worse will your performance be if the number of users doubles
again?
Should you turn away some users so that others will get acceptable per-
formance?
Does it matter which users you turn away?
If you run out to the store and buy a server, how much better will perfor-
mance get?
Do the answers change if you are under a denial-of-service attack by a
competitor?
