Just thinking in terms of minimizing the number of directions we've got to go when mirroring and synchronizing things across servers... We currently keep page data in a database, but also cache some rendered pages on the local filesystem. We keep information about TeX fragments in a database, but cache the rasterized images in the local filesystem. Uploaded files are a little different: we keep track of them in a database, but the essential files themselves cannot be reconstructed from the database alone. Thus if we run multiple web servers from one database, they fight over the files, needing either a shared networked filesystem -- inaccessible if the server dies -- or for all but one to be read-only and periodically update from the live site. Transparent load-balancing will require that any web server that you stumble upon should be as good as any other and provide the same stuff, so locking off all but one (as we've done from time to time when experimenting with a second 'en2' access point) is less than ideal. Hypothetically we could have a notification system where the server that makes a change sends updates to all other servers, but this raises a question of resynchronization if a member of the cluster is taken out of service and brought back in -- or if two make conflicting changes simultaneously. It might be the simplest thing to just store uploads directly as blobs in the database. When a request comes to serve an uploaded file, we can cache it in the local filesystem (or memory) if we like to speed access and allow read-only access with the db server down. This allows resynchronization by checking cache time validity, and lets images be backed up along with the rest of the db. Terrible idea? Good idea? Anyone have experience doing this kind of thing? Typical files are in the tens or low hundreds of kilobytes, with some ranging up to the maximum allowed 2MB. The total size of uploads we have is comparable to the total size of the current-version page texts, and much smaller than the total old-revision page texts we've already got in the db. -- brion vibber (brion @ pobox.com)