On Wed, 19 Jul 2000 10:07:30 -0600, Bill Anderson <bill@libc.org> wrote:
Toby Dickenson wrote:
On Tue, 18 Jul 2000 16:08:48 -0600, Bill Anderson <bill@libc.org> wrote:
I might be reading more into his words than was intended, but I think this demonstrates the problem. Distributing multiple requests for one section across multiple servers is (what I consider to be) undesirable.
You can actually do it either way. Curtis (AIUI) complained that the method described meant your site depended upon each of th esection's servers being up, that there was no redundancy. So I described a way of doing it with redundancy.
What you described doesn't scale up to having 1000's of sections (which I was assuming, and I think Curtis was too). If this isn't a problem, then your solution is great.
I don't understand why you think it doesn't. DNS has clearly demonstrated the ability to handle 'thousands', and the entire scalability of a cluster is the addition of machines. You appear to be desirous of having a machine handle a section. Thus, for thousands of sections, you have thousands of machines.
DNS scales up to one machine per section, but a typical budget doesnt. Fortunately it doesnt need too. Even if we have 10000's of sections, I would expect only 10's to be active over a period of a few minutes. Another way of looking at the issue is that it is similar to using in-memory Sessions. You have to ensure that each user's requests are routed to the machine that holds their session. The main difference is that it is a performance, not correctness issue. I don't want to think about handling Sessions using DNS and one machine per user ;-)
EddieWare does do 'intellgient' caching
eddieware is on my list of option to try out next month... Ill keep you posted
Cool.
Toby Dickenson tdickenson@geminidataloggers.com