when to stop buying RAM & disk

From: Terence Kelly <tpkelly@dont-contact.us>
Date: Tue, 11 Jan 2000 02:46:29 -0500 (EST)

I have a question regarding Web cache configuration which is not
fully addressed by the Squid FAQ nor, as far as I know, by the
academic literature on Web caching.

Assume that a Web cache is currently able to satisfy hard performance
requirements (e.g., constraints on service times or throughput).
Furthermore assume that the cache's workload is sufficiently well
known that one can predict the improvements in hit rate and byte hit
rate that will result from the addition of various amounts of RAM
and/or disk capacity. How does one decide 1) whether to purchase
additional memory for the cache, and 2) how much memory to purchase?

Is there a literature, folklore, or accepted wisdom regarding how to
trade memory expenditures for savings in external bandwidth and/or
client latency?

To my knowledge most Web capacity planning literature and admin folk
wisdom is mainly concerned with meeting minimum performance
thresholds. The basic question is, "what system resources are
required in order to serve the expected workload within given
constraints on timing, fairness, etc.?"

I'm interested in a complementary and orthogonal issue: given that
all minimal performance requirements have been met, how do we
determine an optimal level of additional system resources? When the
pointy-haired boss demands to know, for instance, why we decided not
to spend more money on memory in order to conserve expensive external
bandwidth, what sort of business case can we make to justify the
current configuration of our cache? Or let's say PHB asks whether
our expenditure on caching yields returns above the opportunity cost
of capital. Can we give a principled answer to such questions? Or
is it wrong or impossible to consider the question from an economic
or business perspective?

Many thanks in advance for your reply.
Received on Tue Jan 11 2000 - 08:12:28 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:50:18 MST