Did you notice the settings page for each blog has an option for "static" page?
And also, a link in the blogs tab to generate the static pages?

Also, there's [url=http://forums.b2evolution.net/viewtopic.php?t=1564]this page[/url] that tells you how to direct traffic to the appropriate page with a .htaccess file.

That being said, it would be really nice to be able to generate cached pages for each permalink, and auto-regenerate those pages when someone posts a comment, so that they show up automatically.

Another drawback is that hitlogging doesn't happen when you load a static page, so you don't know what people are looking for when they reach your site. It would be good if, instead of simply redirecting to a .html, it loaded the content from the .html without any processing (which is very fast and non-server-intensive) and then log the hit.

Thank you Isaac for your answer, yes I am aware of the static page, but that page only takes care of the first page, not the rest of the site... the one thing that prompted me to ask for this feature or plugin is that I've been kicked out of too many hosts already for overusing processes... even though I have eliminated the hitlog counter that drives servers crazy, and implemented some of the suggestions user Nir suggested here.

The plugin I'm thinking about has already been done for WordPress, and I guess adapting it could be a way (although I don't know any programming otherwise I'd try my hand at it). The author of the plugin explains why would someone need it:

Do I really need to use this plugin?

Some reasons you may want to use it:

* If your site gets Slashdotted
* If you’re on a very slow server
* If you’ve had a complaint from your host about performance

http://mnm.uib.es/gallir/wp-cache-2/

WP-Cache is an extremely efficient WordPress page caching system to make you site much faster and responsive. It works by caching Worpress pages and storing them in a static file for serving future requests directly from the file rather than loading and compiling the whole PHP code and the building the page from the database. WP-Cache allows to serve hundred of times more pages per second, and to reduce the response time from several tenths of seconds to less than a millisecond.

Since B2evo and WP have a common origin, perhaps this could be adapted... the ability to serve pages at nearly static speed, retaining the advantages of a dynamic page generating system is really what busy websits need.

Maybe someone can check out the author's site, and look at the code and see how difficult a b2evo adaptation would be.

I've just posted a [url=http://forums.b2evolution.net/viewtopic.php?t=4551]Simple Cache Hack[/url] that implements an automatic cache system. However, it uses the cache age to update pages and doesn't take into account any change made to the page.

Yep, I think we're going to need something like the WP-Cache 2.0 for b2. Everytime my page gets hit my CPU usage jumps to nearly 20% which is unacceptable on a shared server and my host informed me of this. I took the site offline for a while, then went to work on the htaccess referer spam blocking to try and kill off some of the hits before they got to php, but my webserver was still taking a beating. I've moved my site for the time being to a different server but it can't stay that way for ever and something needs to be done to reduce CPU usage. I'm thinking the next step is to implement some sort of smart caching system. I found [url=http://b2evolution.net/news/2003/06/28/p269]this thought by Francois[/url] to be an interesting thought. Do you think we can tackle a block caching system for b2? Is anyone willing to help? I'm not a super programmer so I need a leader but I'm more than happy to pitch in.

I would repost the Block-Cache concept and rationale as written by Francois here, for folks who are lazy enough not to follow the link:

Web application caching English (US)
by Francois PLANQUE · Categories: Technology

Blogs, as most current web applications, need to address the server-side caching issue in order to reduce webserver load.

It looks like most people are quite happy with caching static versions of their pages for some defined amount of time. This method has often been called something like ~`half-baked/half-fried'~ in reference to t[b]he long running baked (static) versus fried (dynamic) discussion.[/b]

I'd actually call it ~`baked on demand'~... but regardless of what name we use, I would not be satisfied with this.

I have actually done some experiments caching my blog homepages which is enough to significantly reduce load, but this really makes them too static for me. I do want to log some stuff in realtime, I do want new user comments to show up instantly, and most of all: I do want the page to be customized for each user: display new posts since last visit, display his personal choice of categories, etc... Caching a whole page for every possible combination seems plain stupid. (And it is! :>> )

Actually, the only smart caching mechanism one can be satisfied with in high-end web-applications is block-caching. As a matter of fact, a web page can actually almost always be considered as an assembly of different blocks. Some are static, some are dynamically updated several times a day, some are related to the user himself and some are so dynamic they change everytime the page is displayed, no matter what! By caching each of these blocks individually when it makes sense and rebuilding only those necessary at a given time, you can then reconstruct your whole page dynamically significantly faster than if you had to reconstruct all blocks from scratch everytime.

And there you have it: performance and functionality. Yeah, Okay, I know... it's also much more complex to implement than any other caching mechanism... ;D

Hello EdB, are you out there? I would like your thoughts on this... the issue of b2evo driving servers crazy will be more frequent, as blogsites mature and attract more and more visitors... you can get the dreaded email from your hosting provider pretty soon, it doesn't take that many visitors for b2evo to drive the shared server nuts!

I'm a newbie, but... oh, this is going to sound weird...

It would seem to me that caching can be handled dynamically. It would work a lot like Templates tab in admin. Everytime something new is added (comments, new blog entry, trackbacks) to the page, it would be re-cached.

On the surface, it doesn't seem to me that it would be so difficult to implement, but I haven't played around with b2evo enough (or any blog app for that matter) to be able to confidently tackle this. I would think that the Static page "Gen!" function for the individual blogs/stubs would work if automatically implemented throughout the system.

I'm probably missing something obvious, though... I am a noob.

[url=http://b2evolution.net/news/2003/06/28/p269]François' idea of a blocks-based cache system[/url] can be achieved using either JavaScript to load blocks dynamically (by the client's web browser on static page load), either using <iframe> (X)HTML tag to include external (and fully dynamic) pages into a static (X)HTML. In both cases, a static pages mechanism caches blogs pages referencing dynamic content pages.

I reduced by about 40-60% my server CPU load by using a [url=http://forums.b2evolution.net/viewtopic.php?t=4672]Simple Cache Hack[/url] I've written.

kwa aka ralphy,

You could also do block-caching using something like your simple cache hack, but a bit less "simple."

It would cache each chunk of the page as a different file, and then just read and concatenate the files for display. Things that are not very dynamic (like html at the top of the skin) would almost never change and thus could almost always be retrieved from cache. Other things, like comments, could be re-checked each time, or simply have a very quick time-out.

It would be something like this:

Find out what skin the user wants.
Check to see if the skin's "base" has been cached. (Something like "<html><head><title>@@TITLE@@</title></head><body>@@POSTHEADER@@
@@POSTCONTENTS@@
</body></html>", but with a bit more content than that.)
Replace the tokens in the skin's base cache with other things that might be cached, or, if not found, generated on the fly.

isaac wrote:

[...]
You could also do block-caching using something like your simple cache hack, but a bit less "simple."

It would cache each chunk of the page as a different file, and then just read and concatenate the files for display. Things that are not very dynamic (like html at the top of the skin) would almost never change and thus could almost always be retrieved from cache. Other things, like comments, could be re-checked each time, or simply have a very quick time-out.
[...]

You're right, that's doable, but I'm afraid accessing several files is going to slow down the whole thing a lot. However it's worth testing. I'm going to check that in the next few days.