Date: | April 22, 2016 / year-entry #85 |
Tags: | code |
Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20160422-00/?p=93335 |
Comments: | 16 |
Summary: | What you've got there, my friend, is a WaitForSingleObject stress test. |
A customer designed a client-server system where the client and the server ran on the same machine (but with different security contexts). They were doing some performance tests of the data transfer portion of the system, and one of tests consisted of the following:
When they ran this test, they found that the
If you read the same content 100,000 times, it will quickly become fully cached, and the entire exercise becomes CPU-bound rather than I/O-bound. CPU-bound operation is CPU-bound.
"Yes, we understand that this is an artificial
scenario and that real-world applications will not
use the server in this manner.
The issue is that the
What you've done is taken what is presumably
a complex operation and
stripping it down to just overhead.
Caching the entire workload in memory
means that
the actual work of reading the data is reduced
to a series of Continuing the analogy: If you construct a sample test of your company's shipping system by shipping 100,000 cardboard boxes, each of which contains a single index card, then you're going to draw conclusions like "Tape and shipping labels constitute 5% of the weight!" Well yeah, if you're shipping empty boxes, then tape and shipping labels are going to take up a measureable percentage of the weight, seeing as you are shipping boxes that are practically empty.
What you've got there, my friend, is a
What is more interesting from a performance
standpoint is not the percentage of overhead
that goes to
If you think about it some more,
you may notice that the customer is worried
that the
Assuming that the actual work of determining what memory needs to be transferred to the client is, say, 1% of CPU (this is probably being generous), then that means 93% of the CPU is being spent in application overhead. In the above analogy, the thing you should be noticing is not that tape and shipping labels take up 5% of the weight. What you should be noticing is that cardboard boxes take up 95% of the weight. That's the thing that's determining your shipping weight overhead. If you want to lower your weight overhead for shipping a single index card, don't try to get thinner shipping labels. Work on switching from cardboard boxes to envelopes.
¹ The customer didn't say how many times
|
Comments (16)
Comments are closed. |
Now here’s one of the best computer-related analogies ever!
Raymond’s moonlighting job is apparently working for Amazon, optimizing their Prime shipping.
My guess is that the box’s blame was theirs, and the label’s blame is somebody else’s (in this case, Microsoft’s). And we all know that it is easier to switch blame on the 5% than to make something useful on the remaining 95% you are responsible of. So let’s try to shave that 5%!
So switching from cardboard boxes to envelopes means switching from WaitForSingleObject to something more lightweight?
WaitForSingleObject is the tape. The cardboard box/envelope is the rest of the IPC infrastructure.
I get sick of hearing things like “10 percent of car fatalities are caused by drunk driving” or “20 percent of people die of heart attacks” which is then used as an argument to take some not always well-advised actions.
Death is different to optimisation. It is easy to justify ignoring an optimisation that would save someone an extra five seconds of their day when it takes two hours for the software to do it’s job. It’s not easy to justify ignoring something that could save a single life.
It depends on the probability associated with that “could” and what the corrective action entails (and what other corrective actions might be taken and what they entail).
It rather depends on the cost/benefit tradeoffs of the change.
Making it illegal to use a private car on a journey of less than 30 km would massively reduce deaths in cities (both from pollution and from collisions); and yet I see very little movement towards this, even though it’s trivial to justify the benefits on the numbers, because the cost of the change is too high.
Same applies to optimization, with the difference that the benefits from saving 5 seconds in a 2 hour operation are much, much lower than the benefits of saving 1,000 lives per year per city.
Actually making using cars with less than 30 km distance is not really possible to enforce. If you switch it to – for example – prevent cars from entering cities (or centers of those), you will easily find several cases of already such an enforcement implemented. And many movements actively trying to push similar ones in their cities as well.
It’s trivial to enforce – just require all cars to have a reporting black box that transmits the latest OBDII state back to the police every minute, and track vehicles that travel less than 30 km between two extended time periods (say 5 minutes) with the engine off.
It’s trivial to enforce – just require all cars to have a reporting black box that transmits the latest OBDII state back to the police every minute, and track vehicles that travel less than 30 km between two extended time periods (say 5 minutes) with the engine off.
Then correlate this with blanket ANPR coverage of the road network; you can prevent speeding at the same time, by busting anyone who manages to exceed the designated limit between two ANPR cameras.
The cost is rather high, but it saves lives.
Enforcing such a law would be a nightmare (to know how far people drive would require spying on them). Also, to make people change their behavior, you need to provide them with an alternative at least as good (and probably better to offset the cost of changing). If public transportation is inconvenient, people will want to use private vehicles, regardless of pollution or risk of collision (by the way, collisions in cities are less deadly than collisions on open roads, because speed matters a lot). If environment-friendly vehicles are expensive, people will keep their polluting cars.
I know I’ve ordered a MicroSD card and it’s turned up in a huge box (also stuffed with other marketing material etc.). I do wonder if someone wanted to use a small padded envelope but was overruled because they couldn’t fit the other junk in at the same time.
In a well-tuned singe-computer system, CPU should be at 100% and disk busy time should also be at 100%. It’s hard to achieve that in practice….
I think that would only be true if you always had a constant CPU and disk load over all your tasks. In real life, you want your computer to be able to handle its maximum reasonably common load fairly comfortably, which normally means that the rest of the time it will be cruising on idle.