× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.