I think that our solutions would work well, but both are optimised for different kinds of sites.
For sites which frequently update the content of several areas your method would require a generation run every few minutes which would put a lot of strain on the database servers. If the site isn't updated that frequently, or if you don't mind waiting perhaps a few hours for the content to be updated then I agree that your method is a good one.
But then looking at it from the other direction, the suggestion was that we take a database driven site, convert it to a static site and serve it from a huge number of normal servers - the requirements would indeed be very different and by the time such a site has scaled to 5,000 servers it's likely that we'd have several hundred database servers already.
Now people will argue that a server is not scalable either, but you can always have 5000 servers serving up that same static data. You really can't expect 5000 servers to access a single database and expect the database to survive.
Of course other people may argue that the solution would be to take those 5000 servers and divide them up: run a database service across a few hundred of them, have a few thousand web servers that do the real request processing and then let the rest of the machines be web-facing machines that cache the results for a few seconds to decrease load on the real webservers.
Slashdot Mirror
I think that our solutions would work well, but both are optimised for different kinds of sites. For sites which frequently update the content of several areas your method would require a generation run every few minutes which would put a lot of strain on the database servers. If the site isn't updated that frequently, or if you don't mind waiting perhaps a few hours for the content to be updated then I agree that your method is a good one.
But then looking at it from the other direction, the suggestion was that we take a database driven site, convert it to a static site and serve it from a huge number of normal servers - the requirements would indeed be very different and by the time such a site has scaled to 5,000 servers it's likely that we'd have several hundred database servers already.
Now people will argue that a server is not scalable either, but you can always have 5000 servers serving up that same static data. You really can't expect 5000 servers to access a single database and expect the database to survive.
Of course other people may argue that the solution would be to take those 5000 servers and divide them up: run a database service across a few hundred of them, have a few thousand web servers that do the real request processing and then let the rest of the machines be web-facing machines that cache the results for a few seconds to decrease load on the real webservers.