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. Again, with a ZEO clusters the bottleneck/SPOF would be the ZSS, but that _could_ be worked aorund, and has nothing to do with 'sections' of a website. Beyond that, your bottleneck would be networking. Whether yoour individual BE servers responded directly to the web browser, or whether they were channeled through a single/multiple FrontEnd servers. The decision to implement a BE->Client vs. a BE->FE->Client topology has not been discussed, as it is irrelevent to the discussion. In fact, come to think of it, I have noticed many sites redirect a /foo/bar usr to a foo.domain.com or bar.domain.com.
EddieWare does do 'intellgient' caching
eddieware is on my list of option to try out next month... Ill keep you posted
Cool. -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password.