interprocess communication affects application Response time

interprocess communication affects application Response time

Randy Stafford

RESPONSE time is CRiTiCAL to software usability. Few things is as frustrating as waiting for some software system to respond, especially when we interaction with the SOF Tware involves repeated cycles of stimulus and response. We feel as if the software is wasting our time and affecting our pro-ductivity. However, the causes of poor response time is less well appreciated, especially in modern applications. Much Performance management literature still focuses on data structures and algorithms, issues this can make a Differ-enc E In some cases but is far less likely to dominate performance in modern multitier enterprise applications.
When performance was a problem in such applications, my experience have been that examining data structures and algorithms I SN ' t the right place to look for improvements. Response time depends most strongly on the number of remote interprocess communications (IPCS) conducted in Response to a Stimulus. While there can is other local bottlenecks, the number of the remote interprocess communications usually dominates. Each remote interprocess communication contributes some nonnegligible latency to the overall response time, and these Indi Vidual contributions add up, especially when they is incurred in sequence.
A Prime example is ripple loading in an application using object-relational mapping. Ripple loading describes the sequential execution of many database calls to select the data needed for building a graph of Objects (see Lazy load* in Martin Fowler ' s Patterns of Enterprise application Architecture [Addison-wesley Professional] ). When the database client was a Middle-tier application server rendering a Web page, these database calls is usually execut Ed sequen-tially in a single thread. Their individual latencies accumulate, contributing to the overall response time. Even if each database call takes only milliseconds,
* http://martinfowler.com/eaaCatalog/lazyLoad.html
Things every Programmer should Know
???
??????????????? A page requiring calls (which is not uncommon) would exhibit at least a 10-second response time. Other examples include Web-service invocation, HTTP requests from a Web browser, distributed object invocation, Request–r Eply messaging, and Data-grid interaction over custom network protocols. The more remote IPCs needed to respond to a stimulus, the greater the response time would be.
There is a few relatively obvious and well-known strategies for reducing the number of the remote interprocess communications Per stimulus. One strat-egy is to apply the principle of parsimony, optimizing the interface between processes so that exactly the righ T data for the purpose at hand are exchanged with the minimum amount of interaction. Another strategy is to parallelize the interprocess communications where possible, so, the overall response time becom ES driven mainly by the longest-latency IPC. A third strategy is to cache the results of previous IPCs, so then future IPCs could be avoided by hit-ting local cache ins Tead.
When you ' re designing a application, be mindful of the number of interprocess communications in response to each stimulus . When analyzing applications this suffer from poor performance, I had often found ipc-to-stimulus ratios of thousands-to-o Ne. Reducing this ratio, whether by caching or parallelizing or some other technique, would pay off much more than changing Data structure choice or tweaking a sorting algorithm.

interprocess communication affects application Response time