Collective Wisdom from the Experts 83
a page requiring 1,000 calls (which is not uncommon) will exhibit at least a
10-second response time. Other examples include web-service invocation,
HTTP requests from a web browser, distributed object invocation, request–
reply messaging, and data-grid interaction over custom network protocols.
The more remote IPCs needed to respond to a stimulus, the greater the
response time will be.
There are a few relatively obvious and well-known strategies for reducing
the number of remote interprocess communications per stimulus. One strat-
egy is to apply the principle of parsimony, optimizing the interface between
processes so that exactly the right data for the purpose at hand is exchanged
with the minimum amount of interaction. Another strategy is to parallelize
the interprocess communications where possible, so that the overall response
time becomes driven mainly by the longest-latency IPC. A third strategy is to
cache the results of previous IPCs, so that future IPCs may be avoided by hit-
ting local cache instead.
When you’re designing an application, be mindful of the number of interprocess
communications in response to each stimulus. When analyzing applications
that suffer from poor performance, I have often found IPC-to-stimulus ratios
of thousands-to-one. Reducing this ratio, whether by caching or parallelizing
or some other technique, will pay off much more than changing data structure
choice or tweaking a sorting algorithm.