Recent Topics

1 Jun 10, 2005 22:50    

This is a MUST feature in my opinion, one that on its own would attract professional webmasters to consider B2evo: a caching system, either a plugin or preferably built-in, so that B2evo can have both the advantages of serving dynamic web pages and none of the down sides (currently B2evo drives servers NUTS when your blog becomes popular, and it's not just the hitlogging activity, but the entire thing).

I believe the only reason for the pro blogs like WeblonsInc or Nick Denton's are using Movable Type is because it serves static pages, and can do PHP with archives, thus achieving a good balance of speed without killing the server.

So that's my wish, a B2Evo Cache Script for high traffic sites.

2 Jun 10, 2005 23:42

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=]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.

3 Jun 13, 2005 05:41

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

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.

5 Jun 25, 2005 04:48

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=]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.

6 Jun 29, 2005 17:32

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!

7 Jul 09, 2005 10:52

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.

8 Jul 11, 2005 18:22

[url=]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=]Simple Cache Hack[/url] I've written.

9 Jul 12, 2005 01:08

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@@
</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.

10 Jul 12, 2005 12:31

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.

Form is loading...