Web caching System Design Checklist
[DESIRE]
[DESIRE Web cache]
[Web cache Architecture]
This is a short checklist version of a longer detailed Web caching Architecture Document
We recommend that you
- use Harvest-based software
We have tested Squid extensively and found it very good
- if in Norway, use our Squid-package for Linux and SAMSON
We recommend that you
Be aware that only Netscape offers a fallback mechanism (yet).
We recommend that you
- always place webcaches close to where the traffic flows
- place caches on your side of network bottlenecks
First level cache
We recommend that you place your first-level Web cache
- as close as possible to your external Internet connection
- close to users
- if you have several first-level: where networks come together
Upper-level Web cache
We recommend that you place your upper-level Web caches
- where networks join
- on or close to a national Internet exchange point
- on or close to an international Internet exchange point
We recommend that you
- allow access to your Web cache server only for those you have set up an agreement with
- always ask the administrator before you set a Web cache as you parent or neighbor
- go to NLANR registration database, find potential neighbors and parents in your area
- contact you Internet Service Provider
We recommend that you
- keep logs unavailable unless anonymized
- rotate and process logfiles once a day (or more) due to their large size
- keep the large size of the log files in mind if you write programs to
analyze them
- keep the privacy of your users in mind when you publish results of
log file analyzing
- find out what kind of statistics you want from your server, or you'll
drown in numbers
We recommend that you
- register your server
- contact your Internet Service Provider before setting up parents outside your network
- observe your Acceptable Use Policy (if you have one)
- keep logs and statistics unavailable unless anonymized
If you are an Internet Service Provider, we recommend that you
- establish peering agreements with other providers, this is very important within a country/language zone
- investigate your routing agreements with connection providers
Toplevel server
We recommend that you either have
- more than one big strong UNIX server (dedicated), if you have one, be prepared to buy another
- or a farm of smaller specialized servers (dedicated)
Local server
Depending on your user community we recommend
- Linux, if you have a reasonable amount of users (low cost equipment)
- any UNIX-system with
- good I/O
- lots of disk if you have many users
- lots of memory if you have lots of disk
Ingrid Melve