I've just added the following warning to the description:
This hack is not designed for a multi-server setup. So unless the data on the filesystem is being updated on the fly its not recommended to install this.

Thanks for helping with your feedback.

In fact, your hack is designed ESPECIALLY for separate web and database servers. :) It saves a lot of interserver traffic.

A good workaround is to make sure each time you edit settings in AdminCP the datastore is automatically rebuild. The problem is not multi-server, but multi-web server = when the datastore is rebuild, it only gets rebuild on the ONE web server. Trying to sync it in real-time won't be easy. :)

I'm using these comments as delimiters right now and additionally these comments are in the file by default now. The delimiting comments ensure, that nothing is being replaced, if the regex itself fails, instead of messing up the whole file, causing more problems than it solves.

Yeah, you're right. I've changed multi-server to multi-webserver in the description. Thanks :)

anyone confirm if this works on 3.0.6 without obvious problems?

arn

WFM

I've upgraded to vB 3.0.6 Wednesday evening and I had no problems so far.

btw: The backup feature may be removed in future version. I usually implemented it, so you could restore a previous version, if something went wrong, but since rebuild_dscache.php works perfectly, these backups are no longer needed.

Yes, I got it working on 3.0.6 too. :) But I don't currently use it.

Is anyone running this on a forum that has Ushop?

I got it working with my version of ushop - you basically need to add the ushop variables to datastore templates too.

Ok, I have a few questions before I decided whether to risk sticking it on my production forum. It installed fine on my beta test and appeared to cut the page loading time down from 25/30seconds to 15.

My server has been hit hard by vB3's agressive database load and the unserialize() bug, hence the obvious difference. However, some aspects confuse me, for example:

My site (e.g: blahblah.co.uk) calls a database (e.g: db001.hosting.co.uk) thats given its own domain name by the same web host, but I'm worried about the above quote.

1) When do you actually need to run the 'rebuild' process? Judging by the data - only when you change an option in the admin CP or add/edit one of your forums/category names & options. Does it need to be rebuilt after every new post or is it just doing the more static data?

2) Can I remove the admincp/rebuild....php script from the server when not needing to be used or does something require it to be there?

3) If I need to take my forums offline to change the options, then (as per above) will this corrupt my database? I'm confused about how this can be prevented as admins always need to update options/add forums etc. now and then. Do you take it offline, run the rebuild, update the options, run the rebuild, put it online and then run the rebuild again? Am a little confused ;) .

-----------

Otherwise, can I just say, this is an excellent idea. If your database gets a lot of load and your actual webserver is still fast, then calling the key settings/forum names+details from the file system instead of the database (I think that's how it works?) saves a lot of DB pressure.

This may be more obvious to those on shared hosting, when vB3's heavy load can become a pain.