Skip to:

bbpress and memcache?

  • Can someone tell me what’s the status with bbpress and memcache? I see backpress is meant to unify memcache in both installations but is there a working beta to get both working? I currently using version two of the object-cache on my wordpress and unfortunately i suppose that is what is causing the problem with the bbpress integration plugin. Any clues or more info?

    Thank you.

Viewing 25 replies - 1 through 25 (of 34 total)
  • @usera

    Instead of memcache, output caching might be a better option for non-logged in user. Something like WordPress’ SuperCache plugin.

    More information can be found about this discussion here:

    Essentially, a lot of people would love the SuperCache plugin to be converted for use with bbPress … but no one has yet committed to performing the work needed to convert the plugin :(

    for my requirements memcache is more reliable and less messy. Besides you do not supercache a forum. I do not think you understand.

    Sam had some thoughts on how bbPress 1.0/Backpress enabled the WordPress memcached plugin here:

    _ck_ also had some thoughts on how memcached would or wouldn’t increase performance (although it sounds like performance isn’t your main goal in making the switch):

    Good luck – and keep us posted on how it goes!

    Olaf Lederer


    @johnhiler, his concerns are more about setup problems by unexperienced php user and hosting requirements.

    Actually, I don’t like the super cache module for WP, because it’s only powerful for blogs with a lot of page views. Memcache would be better for bbpress in my opinion. I know a lot of people using memcache for several types of applications and they are very glad to use it.

    I don’t think that memcache should be a part of bbpress, but it would be helpful that the API is compatible to use it.

    I think there is some mistake on what the intent of my post was about. My post is never meant that I wanted a feature to “cache” the forum. I wanted the bbpress integration to work with memcache for a seemless login but currently it’s done by the cookie path.. I think I once again got confused on who to contact to get that feature added since not everyone uses cookies but than I suppose it is a problem when you set session handling to memcache by master value.

    Olaf Lederer


    so it’s possible to store user sessions with memcache? this is cool.

    do you know some reference material about this function?

    Ruby on Rails has some stuff to allow memcached storage of user sessions:

    @finalwebsite – _ck_ is a female developer. :-) I was referring to her statements that “the performance boost will be trivial, almost non-existent for a single server setup” and ” Memcache is only beneficial for multi-server systems, it’s why it was invented in the first place.” But ymmv!

    Sam Bauers


    We don’t use memcache to store user sessions, user sessions are stored in the browser cookie.

    There is a memcache capable object cache though which is built in to bbPress via BackPress. To enable it (with default memcache settings) all you need to do is add this to your bb-config.php:

    define( 'BB_OBJECT_CACHE_TYPE', 'memcached' );

    Note that this will not work if you are using the memcache object cache in WordPress, and you have WordPress deep integrated into bbPress.

    you are a lifesaver sambauers. I am using object cache but it’s not deeply integrated . The only other question is do you happen to know if you have to set a key (if you can set a key) to prevent object sharing. I know this is a problem with wordpress mu. I wish this was documented somewhere.



    Memcache is only useful for multi-server installations otherwise it has too much overhead.

    Eaccelerator, APC and Xcache have shared memory solutions that are significantly faster than memcache on a single server setup. But on a single server, it’s also been demonstrated a proper mysql cache can be faster than an object cache in some cases.

    Eaccelerator, APC and Xcache can already store server session data in shared memory, you just have to compile with the option and turn it on in PHP.

    There are plugins for wordpress that could be ported to bbPress 1.0 for the object cache but IMHO it’s a waste of time unless you have a very slow or overwhelmed mysql server.

    Sam Bauers



    You can setup a new memcached instance to avoid clashes with wordpress, but if you are sharing user tables then it shouldn’t matter.

    If you add another memcached instance on a different port you can point bbPress to it by adding this to bb-config.php (default IP and port shown here)…

    $memcached_servers = array( 'default' => array( '' ) );

    Ryan Hellyer


    Hmm, showing my total ignorance of caching here …

    I assumed memcaching was the best way to improve the performance of bbPress and WordPress on a server even if it was only on a single server. So if I have a VPS, what specifications should I request to make sure it runs at maximum efficiency?

    I”ve been contemplating moving to a 512 MB VPS and requesting they install mem cache on it for me. But juding by _ck_’s comments above that would be a stupid thing to do.

    Any opinions?



    Let’s review this from scratch.

    WordPress and bbPress 1.0 has what we call an object cache. That is simply a pool of users, forums,topics, and posts and meta as they are passed between mysql and the application (wordpress/bbpress). It’s just another layer between mysql and bbpress.

    Typically these “objects” are lost after every page load because they are no longer in regular short-term computer memory and have to be fetched again from mysql.

    On a single computer system with a fast mysql server and fast disk cache, this typically is not a big problem. As a site has to scale this does become a problem because there is only one mysql source and everything has to be fetched from it.

    Using a poorly configured WordPress or bbPress system with badly written or improperly running plugins, if each page load requires 30-40 queries, and you have 1000 users connected simultaneously at once, that’s a huge problem.

    Memcache is a common pool of memory that doesn’t go away after each page load. It’s centralized on one server so multiple servers can all find it easily. It was invented by LiveJournal after they hit a growth limit with mysql.

    The Memcache to Object Cache interface plugin for WordPress/bbPress 1.0 allows the fetching from mysql to be skipped IF the user/forum/topic/posts happen to be in the previously accessed pool in that centralized memory. Every time a query is made, the resulting data is saved in the collective memory which is retained inbetween page loads. It’s a common, shared memory.

    However Memcache was written to talk over tcp/ip between MULTIPLE servers. For a single server setup it’s pointless and stupid and way too much overhead.

    Now, on a single server, you could still use a persistent object cache with one of the other lesser known plugins that mimic what the memcache interface does. There is one for Eaccelerator, one for APC and one for Xcache.

    However, all of these caches do almost the same thing as MySQL’s cache. They are all tied to the particular kind of query that is done and if it matches the previous set of data. The object cache still has to de-serialize data if it’s serialized.

    MySQL on a single server system does not use tcp/ip to communicate with bbPress if it’s properly configured (and most are unless your host is greedy and stupid and uses a central mysql server separate from your regular server). So MySQL with a properly configured cache is almost as fast on a single server setup than a persistent object cache (unless MySql is overloaded in the first place).

    So in conclusion, if you are on a shared host, object caching is not a viable solution for you because you can’t get any of the persistant memory options installed anyway. If you are on a single server setup but not dealing with a large number of connections, the mysql cache is probably going to be near the performance of a persistent object cache, and the real memcache would never be used in the first place.

    Memcache was meant for large, inefficient installs like serves many thousands of people simultaneously from many different servers. It uses several dozen queries per page load. It absolutely cannot just rely on the mysql cache, even with dedicated mysql servers. The average wordpress/bbpress user does not face these problems typically.

    If you have your own VPS or dedicated server you should be installing an opcode cache like Eaccelerator, APC or Xcache and turning on the shared memory pool option (typically during compile). Then you should make sure your mysql cache is ON and setup properly. Then you should make sure your pages are not using too many queries. If you’ve done all that and you have so many simultaneous visitors that your mysql is running too high a load and your pages are still too slow, then you can look at one of the persistent object cache modules for wordpress and port them to bbpress.

    None of the bbPress installs in the Top 10, are using memcache or any kind of object cache for that matter (including which is using bbPress 0.9). So I sincerely question the need of anyone else using an object cache just yet unless they have made their install extremely inefficient somehow or have a horrible host.

    Sam Bauers


    “[] uses several dozen queries per page load.”

    Thanks to memcache the average blog front page on uses only a handful of queries, sometimes as few as one.

    “It absolutely cannot just rely on the mysql cache, even with dedicated mysql servers.”

    From memory, doesn’t use MySQL query cache at all as it would need to be invalidated many times every second. We also would need to invalidate all slaves as well as the masters.

    I think it’s important to say that you should only setup and enable any caching if you actually need it. Most people don’t and shouldn’t, all you do is add another potential point of failure into your site.



    Because of mysql replication, using the mysql cache is probably impossible on

    Once you move beyond a single mysql server, things get complicated fast.

    But that’s specifically the environment memcache was written for, not single server systems.

    (by the way, how large is the memcache pool? I bet it’s massive)

    However I find the MySQL cache has not been turned on for many VPS/dedicated servers. That’s a performance showstopper and makes a huge difference when the same queries are being done over and over on a typical bbPress install. A PHP opcode cache is the next largest performance improvement.

    Here is the typical breakdown for MySQL vs Memcached performance:

    Cache Type 	 Cache Gets/sec  (higher is better)
    Array Cache 365000 (this is local memory, fastest possible)
    APC Cache 98000 (this is common memory via apc/eaccelertor/xcache)
    File Cache 27000 (this is using the local disk cache)
    Memcached Cache (TCP/IP) 12200 <<<<====---
    MySQL Query Cache (TCP/IP) 9900
    MySQL Query Cache (Unix Socket) 13500 <<<<===--- (local mysql server, with cache)
    Selecting from table (TCP/IP) 5100 (remote mysql server, no cache)
    Selecting from table (Unix Socket) 7400 (local mysql server, no cache)

    I think you may be confused _ck_. memcache has it’s uses like php op_code. It does not take alot for it to have a benefit and the same applies to memcache. However I am not asking for a suggestion on avoiding memcache. I would like to see a better handling of objects in the same way you create a prefix for a database. If you set a large pool for memcache say 1gb. The idea of setting another instance and monitoring it with startup script gets a little bothersome especially when an array can be used to mitigate the possibility of one failed instance to drive your site down. In short I should say you don’t usually start another mysql to house a database nor would it be useful to do that with memcache.

    Thanks samhaurs again. I just want to be sure there weren’t objects that are generically named that can be seen across bbpress installations like administrative or personal details that should be separate that some are improperly written to cache much like wordpress mu does at the moment.

    nevermind. seems the objects are overly generic. i’ll have some patch it up to work.

    Ryan Hellyer


    Hmm, well this all sounds promising’ish.

    I asked Sam Bauers at WordCamp NZ how bbPress would compare speed-wise and server resource wise to other standard forum softwares like phpBB, SMF, vBulletin etc. He said that the others were probably faster on a shared hosting environment, but when mem-caching is running that bbPress leaps ahead in performance. Sam, perhaps you were referring to forums which REQUIRE mem-cache (ie: super large forums) running better on bbPress than the other softwares?

    At any rate it sounds like for my purposes that I shouldn’t worry about these things too much and just stick with using it straight out of the box.



    Interesting, my opinion would actually be the opposite.

    bbPress is probably faster in a shared environment than the others (if tuned).

    SMF and Vbulletin already take advantage of shared memory like eaccelerator/apc/xcache out of the box and have different levels of caching. Vbulletin is very bulky though.

    The magic to bbPress is not performance, it has an “acceptable” rating in performance for 1.0, but what you can do with it and how quickly. You can customize bbPress like no other forum I’ve seen with quite a bit of ease, not just the look/theme but the actual functionality.

    Simon Wheatley


    CK Said:

    On a single computer system with a fast mysql server and fast disk cache, this typically is not a big problem. As a site has to scale this does become a problem because there is only one mysql source and everything has to be fetched from it.

    Interestingly we’re running a WP install with two load balanced app servers and two DB servers… our host has the MySQL tuned up so well that we’re seeing absolutely no advantage when we installed memcached as an object cache. The lesson is: don’t assume, test. Check your queries AND page gen time, then install your proposed enhancements (APC, memcached, whatever) and check your queries and page gen time again… seeing an improvement? Keep the changes, otherwise drop them.



    Glad to see what I am saying confirmed with independent realword proof.

    BTW, just how big is your site that you require multiple db servers?

    I don’t know of a single WordPress+bbPress install, other than Automattic’s that are using multiple db servers.

    (unless of course you are running other apps that have heavy db use or maybe for backup replication)

    Ben L.


    When I have memcache enabled on my local server, bbPress loads an average of 20ms faster (a lot for local execution in my opinion), although I haven’t put anything together to test this yet. Memcache works well simply because hard drives are generally slower than RAM.



    It only loads faster because several parts of 1.0 are still not optimized yet and use too many queries.

    The point is a proper mysql cache, especially if it’s on the local machine, is as fast as memcached unless you have an overloaded mysql server (that is also typically external to the webserver).


    There does appear to be an option that everyone is overlooking … and that’s Output Caching.

    We’ve talked about memcache, optcode caching and mysql query caching … but truly the most effective is simply perform Output Caching for non-logged in users.

    In case someone is not aware, Output Caching is saving to disk the generated HTML. That way, instead of memcache where you have to make a call to the memcache server, or in mysql you’re still making the database call or in optcode caching, it’s simply pre-compliling the PHP … Output Caching is by far the fastest because it essentially just serving up pre-generated HTML straight from disk.

    Hey Frooyo – I think you mention output caching every change you get. :-) Your comments about it are the first comment on this thread…

Viewing 25 replies - 1 through 25 (of 34 total)
  • You must be logged in to reply to this topic.
Skip to toolbar