I can figure 160,000 kb / day but how does that translate into a pipe
size? Yes, but /day is too large a timeframe. What you need to be concerned with is how many concurrent connections will be retrieving that 160Meg, and what's the average response time you're targeting? If all the requests come at 12:01PM, and you're targeting a .7 second response time you'll need a big pipe indeed. I'd do the math this way, how many requests are you targeting per minute (note, you can not take the daily rate and divide by 24*60) and what's the average response time you're targeting in seconds. Once you know requests per minute you know bytes per minute (request size * requests/minute), and therefore bytes/second you'll be generating. With that and the average response time you'll know the pipe you need to achieve that throughput, of course, the pipes not your only limiting factor, and if the CMS can't keep the pipe full the pipe is just wasted anyway.
The CMS that we are using has caching so I would think most of it will end up being treated as static content.
Well, there's static content, and there's dynamically generated static content. <G> W2K3 also support kernel-level caching, so make sure that's turned on, it can help a lot. (It's on by default.) Also, make sure you're sending back the correct cache-control headers on the content. For example, a stylesheet doesn't change often and I've seen lots of systems that don't allow caching of a stylesheet so the browser asks for it on each page -- that's a lot of requests that aren't needed. The same is true of .js files, and navigation icons, and logos...
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.