This site is intended to continue support for the legacy 2.x line of the phpBB2 bulletin board package. If you are a fan of phpBB2, please, by all means register, post, and help us out by offering your suggestions. We are primarily a community and support network. Our secondary goal is to provide a phpBB2 MOD Author and Styles area.

I added a lot of caching to phpBB2, including tables like the config table, smilies, flags, and other items that change very rarely. One thing to understand is you're exchanging one form of I/O for another. Take the config table for an example. If that table is queried on every single page, and changes very seldom, you can write the config file out as an array and simply read it in. That means disk I/O occurs on every page load.

Alternatively, you have to run a query against the database, which would (you would think) require first a database call, and then the database has to go retrieve the information from where it is stored on disk. That would imply that caching the file to disk and reading it directly should be more efficient because it skips the database call.

But if the database is smart and the table is small, then the config table contents are permanently loaded into the database cache which is in memory. Now what is faster: reading direct from disk, or querying the database which is reading from RAM instead?

Ultimately I went ahead and cached the file to disk, but I never really answered that question to my satisfaction. Other small tables (smilies and flags as mentioned above) are treated the same way._________________phpBBDoctor Blog

That's true, for simple queries like 'select * from phpbb_config' probably letting mysql do it's job and cache it would be faster... well, in that case that would be true if that table didn't include the rand_seed that is changed often (I moved it to a separate table).

Just slightly. I'm currently working in two new themes/templates made from scratch for my phpbb forum (one for mobile), once they are finished (one month or so) I'll adapt them to be used in the fork, then I'll continue work in the fork project.