I have been noticing some issues lately with the site — you may have too. Some posts are not showing up on the main page right away after publishing.

Many of the comments that people are telling me they cannot see I watch from the WordPress Dashboard — I can see they have been published, but it seems to take minutes or hours to show up. This has been especially problematic with comments that get caught in the spam filter — I fish these out regularly, but for whatever reason people still don’t see them for a while.

Similar problems happen when folks switch from mobile to standard site — seems to take a while to revert back

The leading contenders for these are Word Press Snafu, PC Caching issues, or out of date Flash/Plug Ins/Browser.

My money is on the Cache (heh heh), but I have IT looking into WP problems.

If anyone has additional ideas/suggestions, please let me know in comments

Category: Web/Tech, Weblogs

Please use the comments to demonstrate your own ignorance, unfamiliarity with empirical data and lack of respect for scientific knowledge. Be sure to create straw men and argue against things I have neither said nor implied. If you could repeat previously discredited memes or steer the conversation into irrelevant, off topic discussions, it would be appreciated. Lastly, kindly forgo all civility in your discourse . . . you are, after all, anonymous.

10 Responses to “Cache Issue”

  1. MayorQuimby says:

    I vote for nixing the mobile site altogether although I know there are probably some very good reasons for having set it up in the first place.

  2. vhagerty says:

    I work with WP sites quite a bit. Could definitely be local caching on browsers, but I’ve also had issues with caching plugins (the most common are WP Super Cache and W3 Total Cache), which speed up the site with various types of server-side caching. Usually, these plugins won’t serve cached pages to someone logged in as an admin, so that’s why you wouldn’t see it while others would. It also may be that people who aren’t logged in are seeing older content.

    Another potential issue may arise if you’re using a master/slave setup for your database. Essentially, that’s where you have at least two database servers: one (master) is write-only (or read/write) and the other(s) (slaves) are read-only and are simply mirrors of the master and which are where non-admin users read. There is a delay (replication lag) in this mirroring, as new content from the master gets passed to the slave(s). Usually it’s a few seconds but it can take longer.

    Not saying these are causing your issues and I’m certain your IT folks are looking into these as well, but just thought I’d pass it along by way of saying thanks for the great content!

  3. MikeW says:

    Cache is king.

  4. constantnormal says:

    In the February issue of Communications of the ACM, there is an interesting discussion between Vint Cerf, Van Jacobson, Nick Weaver, and Jim Gettys (an article titled: “BufferBloat: What’s Wrong with the Internet?”, the essence of which is that as memory has become cheaper, hardware vendors have elected to compete by piling ever-larger amounts of memory (and larger buffers) into routers, hubs and switches … the outcome being that the mechanism for prompt resolving and adjusting for traffic issues, errors and bottlenecks has been ruined by an ever-increasing inventory of ginormous buffers, which must all be filled before transmission error notifications or flow control adjustments are propagated back to the source.

    This manifests itself mainly as throughput and response time problems, that eventually clear themselves up. Short of getting all equipment manufacturers to use standard buffer management software and replacing or upgrading the firmware in all the existing devices — which seems highly unlikely — the best hope for a resolution is in a change to the architecture of the internet.

    If this turns out to be a part of the problem here, don’t look for a quick solution.

  5. constantnormal says:

    @MikeW

    “Cache is King”

    Actually, Mike, it turns out that there IS such a thing as Too Much of Good Thing. There is an optimal size for buffers, and cache should be allocated dynamically, to minimize contention for Real Memory (as opposed to Virtual Memory) … at least in well-designed software.

    Sadly, quick and dirty has triumphed over well-designed, especially with the ally of advertising and marketing to the novices of single-number metrics for complex systems.

    Sometimes the King can choke on a pork rind, and the solution is either smaller handfuls or smaller pork rinds.

  6. Jojo says:

    I doubt it is a PC cache problem. As I have reported to you, I clear my cache regularly. I use FF as my default browser. But when I experience these problems, I see the problem in IE8 browser also. seeing the same problem displayed in two different browsers would rule out browser cache issues.

    Interestingly, I do have an occasional similar problem with a post not showing up after I make it at another forum site I occasionally participate in. Strangely enough, this is another WP site (however this problem happens a lot more here than there).

    Isn’t the path to a posting trapped in log files that could be examined?

  7. Unix BOFH says:

    “If you only have a hammer, you tend to see every problem as a nail.”
    – Abraham Maslow

    Your problem is almost certainly the WP-Super-Cache plugin you are using. I’d bet my iPad 3 on it.

    The problem is not that you are using caching, the problem is the use of inappropriate caching. When a change is made to the content of your site (posts, comments, etc), that change is stored in a database. The contents of that database are the heart and soul of your site. For every future web request, WordPress will retrieve your sites content from the DB, insert it into the HTML templates you have chosen, and return the assembled HTML page to the web browser that requested it.

    When a person “surfs” your web site, this chain of events happens:

    their browser makes a HTTP request
    the web server (apache, lighttpd, or nginx) receives the request
    and passes it to PHP (via fastcgi or mod_php)
    PHP parses the request and runs the WP application (and its plugins)
    The WP application:
    fetches the content from the database (likely MySQL)
    assembles the HTML page
    returns the formatted HTML page to the client.

    The reason you and/or your IT people installed the WP Super Cache is that the “fetching content from the database” step tends to be expensive. That’s because RDBMS database engines are optimized for data integrity, a very reasonable default. As such, databases typically perform much more slowly than web servers. Thus, when a busy web site starts slowing down, it tends to be the performance of the database that is the first bottleneck.

    A dumb way to solve this problem is to install a WP cache plugin. Rather than hitting the database for every request, WP will cache entire web pages, or tell web browsers to cache the web pages for some defined period of time. During the cache period, the application avoids hitting the database for all but the first HTTP request. This often works well, especially when the web site has very few changes.

    The problem is that most caches work by caching content for periods of time. If they aren’t effective enough, then the admins bump up the cache time, thereby increasing the likelihood of serving stale content. Sometimes that stale content is innocuous. Sometimes it’s problematic.

    Rather than employing dumb caching solutions, a better solution is to tackle performance problems at their source.

    Databases tend to be the weakest performers in the chain above. Especially if the DB engine is being used in its default configuration, as it was supplied on your Ubuntu linux server. A good solution would be to optimize the DB. Making sure the DB tables have appropriate indexes has already been done by the WP folks. All that’s left for your IT team is to tune the MySQL engine. It’s fairly trivial to make a few adjustments to my.cnf and get 10x or even 100x better performance for WP. There’s even a script called mysqltuner.pl that makes the process easy enough that your IT guys could handle it.

    The advantage of using caching in the DB engine (versus PHP, HTTP, or browser) is that the DB is the source of truth. The DB engine knows exactly when the underlying data has changed, and thus, when to expire cached data. Thus, the DB can achieve extraordinarily high levels of cache performance without ever serving up a single stale result.

    The next slowest performer in the chain is the PHP interpreter. For every single web request, your web server must read the PHP code from the scripts, compile the script into bytecode and then run the code. At the expense of some RAM, a PHP accelerator will cache the compiled bytecode and avoid having to compile the PHP for every single request. If high CPU load is a problem on your WP server, installing a PHP accelerator like XCache or eAccelerator is an appropriate solution.

    WordPress as shipped performs sufficiently well for 99% of web sites. WordPress with a properly tuned DB and a PHP accelerator will perform adequately for 99.9% of web sites. But what about that 0.1% of very popular sites that see traffic on the order of thousands, or even tens of thousands of requests per second?

    The most popular sites have highly tuned databases (sometimes using multiple load balanced databases (a real PITA to manage)), employ PHP accelerators, and also employ some form of HTML (dumb) caching. Something (a caching proxy server, HTTP accelerator, WP cache plugin, etc) is inserted in the chain above that caches the entire web page. This level of caching is dumb in that it doesn’t know when the underlying data has changed. The key to using dumb caching is to keep the cache time very, very low. Something on the order of 1 second is long enough to power even the busiest of sites and still be short enough that the effects of dumb caching are never visible to humans.

    PC Caching Problem?

    We can be confident your issue not a PC cache (web browser) problem because web browser caching problems are practically non-existent. Web browsers cache pages in predictable and well understood ways. In general, they honor the cache settings dictated by the web server when it served the page in the first place. Typical cache settings served by a WP blog looks like this:

    Expires: Thu, 19 Nov 1981 08:52:00 GMT
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
    Pragma: no-cache

    Here’s what your HTTP headers look like (with WP Super Cache)

    Cache-Control: max-age=300
    Expires: Sun, 04 Mar 2012 19:52:40 GMT

    You have installed a WP caching plugin that tells web browsers that the site hasn’t updated and they should continue displaying the last version of the page they retrieved for 5 minutes. This is a (very) dumb form of caching. It’s not the browsers (PC cache) fault. Your server told it to cache the page for 5 minutes.

  8. **** ***t!

    wow, BR, you must be doing ‘something’ right..

    this Dude, Unix BOFH, just, gave you *The Answer that most IT ‘Shops’, esp. in NYC (looking to cover their next “‘Cristal’”-night..) would have billed you U$D xxxx.xx (for), minimum..

    GL, with the Solution~

  9. RW says:

    Not sure if its related but in FF your site will spontaneously flip between the Standard and Mobile view — usually this begins in the middle of a session but sometimes even in mid-session — and will not switch back when one of the Site View links is clicked (they show which view is which but clicking on Standard will not change the Mobile view).

  10. olddogDALTX says:

    Congratulations John on parenting well done. In my family, kids have newer model gadgets than I do, all paid for with plastic. Not considered, is asking for one of my working discards.