Table 10-15. Average response time for RESTful scenarios (cached response)
Average response time
2 summary requests 60 ms
10 summary requests 270 ms
The overhead in making the call remains constant, so there is little difference in the response
time for the summary cases. The 1- and 5-year full scenarios are left with only the time to
transmit the data, which is significantly less than the previous case where the data needed to
be calculated and marshalled. In general, this case can afford to return a lot of possibly un-
needed data to the client without much performance penalty.
NETWORKING ISN'T WHAT IT USED TO BE
Not to sound too much like an old crank, but I used to connect to remote networks via a 300-baud
modem. (Fortunately, I did not have to walk 5 miles to school through 4-foot snow drifts.) There
is an inherent bias in that situation against making too many network calls.
Today, I will sit at my browser, and every time I type a few characters, it will make a remote call
to a Google server, which will respond with a small amount of text to aid me in my searches.
Google has calculated that if this can be done in 200 ms or less, I won't notice the lag time.
As networks get faster and faster, the trade-offs I've discussed in this section may seem less and
less important. On the other hand, my smartphone is lucky if it gets a fast 3G signal much of the
time, and a few times a year, I'm fortunate enough to be in the middle of the ocean connecting to
the Internet via satellite. Throwing faster hardware (or networks) at applications always helps per-
formance, but don't take that as a substitute for performant designs. If the application can detect
that it is on a fast network and make quick, fine-grained network calls, then that is a great optional
feature to include. Just make sure that the application can work well no matter where it is de-