The central
server, however, in any of these
distributed content schemes, would need to enforce
content integrity, meaning that everytime that someone changed a
node, it would need to send the updated page to every content server. This is a very non-
trivial task, especially since the databased is changed almost constantly. Imagine sending 10 copies of every change out, instead of sending pages as requested. My page reading vs. page modification ratio is probably about 5 to 1, meaning that a system with 10 servers would make my use of the central server double. Normally more servers means less load, because there is very little
syncronization needed, but with
Everything2, there is so much syncronization needed that it may end up using more bandwidth than the original system (we'd have faster
node loads, though)
In all the times I have implemented multiple server configurations, it get amazingly complex, even using pre-written interaction tools. Making Everything2 multi-server would be a nightmare. I am not saying that it couldn't be done, and it certainly has advantages, but I think they are insufficient