Data caching takes the place of a database call and can be effective if there are a lot of database requests.  You would typically want to do this if you know that a piece of data is very common and unlikely to change. This saves time on one step of the process.

Fragment caching is a little more complicated.  Instead of caching the data that you would input into another process to build a layout (for example), you just cache that layout directly.  This is great for a “featured news” section that changes only once a day and is viewed often.  It would be silly to cache that data and calculate the layout for every view, so instead we would just cache the layout itself. Saves a bunch of work.

Moving on, we have page caching.  Which is the topic which I really want to go over. I have a warning though, page caching is dumb. REAL dumb. But, in that magnificent dumness is speed. Page caching is the most efficient of the three. It takes the gains we get from fragment caching and goes even further. Think about it, we hardly need to do anything—and therein lies the problem, we lose ALL dynamic ability of the page. This is not an issue for a lot of sites; news pages, catalogs, and blogs can all benefit from this method of caching.

. . .

The method I describe here I used allowed a real site to receive 250,000 real page-views in 40 min (~104 requests/sec). I expect you can do much more. (More number towards the end.)

What I haven’t mentioned yet is that I’m using PHP (specifically Joomla). PHP is certainly not the fastest language around, but considering the whole spectrum of issues facing a web developer, script performance is minimal. And since I’m on this rabbit trail, I’ll mention that Javascript/CSS is the first thing to fix, then caching. I don’t need to explain more about this, there are volumes about it already.

. . .

Moving on, the method described for page caching is based on a simple fallback plan. Here is the psudo-code.

If the page requested is in cache
    serve cached version
otherwise
    serve it dynamically
    add result to memcached

. . .

Joomla Plugin

With Joomla we can actually do this very easily. We just need to hook into the onAfterRender event and grab the page data.  You might notice we’re using the database name as the prefix to the URL in the key name. This is just to be friendly to any other sites hosted on the same server (or copies of the same site using a different database).

You also might notice that we’re grabbing the gzipped version of the page. This is just to trim a little off what the user needs to download.

// no direct access
defined( '_JEXEC' ) or die( 'Restricted access' );

jimport( 'joomla.plugin.plugin' );

class  plgSystemFullPageMemcache extends JPlugin
{
    function plgSystemFullPageMemcache(& $subject, $config) {
        parent::__construct($subject, $config);
    }

    function onAfterRender() {
        global $mainframe;
        $config = new JConfig();
        $cache_id= $config->db . ":" . $_SERVER['REQUEST_URI'];

        $data = JResponse::toString($mainframe->getCfg('gzip'));

        $db = new Memcache;
        $db->addServer('127.0.0.1', '11211', true);
        $db->set($cache_id, $data, 1, 3600);
    }
}

Nginx configuration

server {

  listen 80;
  server_name  yourdomain.com www.yourdomain.com;

  # ...

  location ~ \.php$ {
    set $memcached_key "yourdomain:$request_uri";
    memcached_pass 127.0.0.1:11211;

    default_type       text/html;
    error_page 404 405 502 = @cache_miss;
  }

  location @cache_miss {
    fastcgi_pass 127.0.0.1:9002;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /var/www/yoursite/htdocs$fastcgi_script_name;
    include /etc/nginx/fastcgi_params;
  }

  # ...
}

. . .

Here you can see @cache_miss will get called when nginx can’t find anything in the memcache for the given key (the url). This triggers our fallback plan where the cache will fill itself with any missing data. When we do hit the cache, we actually bypass PHP altogether. No initialization wait, no slowness, and no database calls. By educated guess, nginx and memcached in this setup can start serving content in under 15 milliseconds. Compare this with the 50-100 milliseconds we commonly see.

Theoretically you could serve content faster using this system than just using files due to time spent waiting on disk access. In my proof of concept, I was able to serve about 2500 requests/second but I have reason to believe that limit was imposed by the network card. The CPU was at 10% the whole time and I’m sure it could handle more.

Happy caching!

(Downloadable Plugin Coming Soon)

I get passionate about this issue because, really, it’s such an simple thing to change. Reordering a few words, pulling a few out, and generally saying less can have a profound impact—but then, why is it so hard?

Because it’s hard to be honest, and it’s hard to hear honesty.

I’m a perfect example of this.

I make elaborate fabrications to sound well-informed when, really, I don’t have a clue what’s going on. It would be better to admit I’m clueless and move on. But, I could lose my contract, or my credibility! Who would want to work with me!? Well, personally, I would rather work with someone like that . And I can’t be the only one.

I get defensive. I don’t like being put on the spot, I’m sure you can relate. And I’ll come up with some fancy excuse for why I “can’t hang out”, “can’t meet my deadline”, or “won’t share my source code.” This might work for a short while, but I always have the sneaking suspicion that it will catch up to me.

I water down. Do you ever say something and then instantly regret it? I do this all the time. And then in order to cover it up you say all kinds of clever stuff to try and paint it in nicer light. Not cool. Stop it.

Yes, it’s hard to say what you actually mean. But it’s really the only option. The time lost while confusing people is expensive. During a booming economy, that might be overlooked. During an recession, watch out.

Programming is a complicated job. Many people see it as a craft, and as craftsmen, programmers must spend countless hours honing their skills and improving their expertise to reach a level to compete at the level they desire to be at. For example:

• If I want to build web pages at an amateur level, I simply need to know HTML, some CSS, and maybe some jQuery. For every question that might come up, there is usually a hundred answers on Google.
• If I want to do the same thing at an expert level, I must know about usability, cross-browser compatibility, form validation, race-condition debugging, and a host of other things—most importantly, however, I should be able to find answers to problems that are not Google-able.

So if you’re shooting for your “A” game, you need to practice, right?.

But there’s a problem too. If anyone has an issue with repetitiveness, it must be programmers. We have actually been taught that the sole purpose for our job is to reduce repetitiveness. So where does that leave practice and doing things multiple times?

A lot of the programmers I know, who are really good, attribute their success to the fact that they spend hours at home every night building cool stuff or researching—I think the same could be said of artists and writers as well.

This is great, but let’s consider the following quote by Geoffrey Colvin (emphasis added).

For example: Simply hitting a bucket of balls is not deliberate practice, which is why most golfers don’t get better. Hitting an eight-iron 300 times with a goal of leaving the ball within 20 feet of the pin 80 percent of the time, continually observing results and making appropriate adjustments, and doing that for hours every day – that’s deliberate practice.

So let’s make an assumption—perhaps an incorrect one, but bear with me.

Most programmers are not deliberate about what they practice or how they grow. They do not set clear goals, they do not continually measure results, however they are spending the necessary time.

Why are we just like the golfers?—”simply hitting a bucket of balls.”

• Programmers don’t get out enough. In particular with other that practice the same craft.
• It’s still a fairly new craft. Many outsiders (your family, bosses, etc.) still think that we just “know computers” and they come to us for everything relating to computers. To them cleaning viruses and building web-pages are the same thing. So, to cater to their needs, we are often forced to become jacks-of-all-trades.
• The web it too noisy. How do we judge what is important given the thousands of new articles written every day? The best thing we can do is probably unplug from the web and go for a walk.

Here are some possible solutions. Certainly not an exhaustive list, but something to get started with.

• Local user groups. These allow for interaction, they expose people to higher-level talks and foster an environment for learning beyond amateur.
• Set clear learning goals like “I want to understand exactly how Object Oriented CSS works” or “Find out mathematically if database XYZ can scale for a certain use-case”.
• Continually measure results. Progress is important and it might seem daunting that understanding CSS in 13 browsers is a huge task, but every time you check one off, you’ll feel good about it.

And although I don’t follow my own advice fully yet, I’ve determined to move forward with some of my own goals:

• Develop a system for building web UI applications that actually simplifies things.
• Start a user group to empower other developers and designers.
• Build tools that empower people.

This is something different.

As web applications get better, there is more Javascript.

Caching has been a big help to this—even though only effective for about 40-60% of your audience. The problem with caching however, is that when a new version of the code is released the user must download all of it again.

Diffable JS makes this less of an issue becuase the user might only need to download 10KB of changes instead of 200KB. It also sticks close to #1 rule of web developement: make browsers download as few files as possible.

I think this project is awesome and I need to spend some time giving this a proper look-over.

Diffable JS: http://www.stevesouders.com/blog/2010/07/09/diffable-only-download-the-deltas

Beware, this is beta quality software. Use at your own risk.

As we understand already, Joomla doesn’t have relevant searching. It’s a shame since everything else is designed well, but this is a problem regarding implementation. This article explains how to setup sphinx to index your Joomla articles and use my plugin to search using Joomla.

In my own experiments I built a plugin that accomplished this. It works splendidly, and I had all intention of releasing the code to the public, but got distracted. This process is currently unrefined, but it works. I’m a fan of revision anyway, so if you see a way to improve this article, hit me up (email).

So why doesn’t Joomla have relevant searching already? — Unfortunately it doesn’t seem like they had much choice about it. Joomla relies on MySQL. MySQL is just now beginning to get some Full-Text searching mechanisms implemented and those that do exist are spotty. For example, it is only available in recent versions of the MyISAM database engine and not at all for InnoDB. Plus, I’ve heard some complaints about it not even being terribly good at it’s own job.

A system like Sphinx can go beyond what MySQL supports anyway. It can use word stems and substitutions, so I could specify CPP to be used interchangeably with C++ in any search query and it doesn’t get confused about plural or singular versions of words. It also supports weights, so I can tell Sphinx to prefer matches found in titles and move them higher in the search results.

Install & Configure Sphinx

There are a number of good articles on the web about this. I may revisit how to install Sphinx in detail, but for now defer to the follow links:

• Sphinx Homepage — Obviously the first place to start looking is the Sphinx homepage. Good documentation on Sphinx operation and internals.
• Build a custom search engine with PHP — IBM has a great article on using Sphinx in-the-field. This article describes setup of Sphinx as well as testing and integration with PHP.

Here is my configuration I’ve been using for my Joomla Setup. This is basically the same as any configuration setup on IBM’s website, but adapted to Joomla. There are a few things you’ll need to edit though:

• exampleuser — This should be the username you connect with to search your database
• examplepass — This should be the password for the username just described
• exampledb — This is the database sphinx will be searching on.
• Check your paths. I’m making some assumptions here. Your sphinx data should be outside of your web-root and readable/writable by whatever process searchd is running as.

/var/www/website/sphinx/config.conf:

source mywebsite_articles
{
    type            = mysql
    sql_host        = localhost
    sql_user        = exampleuser
    sql_pass        = examplepassword
    sql_db          = exampledb
    sql_sock        = /var/run/mysqld/mysqld.sock
    sql_port        = 3306

    # indexer query
    # document_id MUST be the very first field
    # document_id MUST be positive (non-zero, non-negative)
    # document_id MUST fit into 32 bits
    # document_id MUST be unique

    sql_query = \
        SELECT `id`, `title`, `alias`, `introtext`, `fulltext`, `created`, `modified`, `hits` \
        FROM jos_content ;

    # document info query
    # ONLY used by search utility to display document information
    # MUST be able to fetch document info by its id, therefore
    # MUST contain '$id' macro
    #

    sql_query_info = \
        SELECT * \
        FROM jos_content  \
        WHERE id=$id
}
index mywebsite_articles
{
    source                  = mywebsite_articles
    path                    = /var/www/website/data
    morphology              = none

    min_word_len            = 3
    min_prefix_len          = 0
    min_infix_len           = 3
}

searchd
{
    port          = 3312
    log           = /var/www/website/sphinx/search.log
    query_log     = /var/www/website/sphinx/query.log
    pid_file      = /var/www/website/sphinx/searchd.pid
}

Testing Sphinx

How do we know if Sphinx is setup correctly? We test it!

First we need to generate the index. So fire up your terminal and run the following (assuming your sphinx install lives in /usr/local/sphinx):

/usr/local/sphinx/bin/indexer \
--config /var/www/website/sphinx/config.conf \
--all --rotate

Second we need to start the search daemon. This will process search requests.

/usr/local/sphinx/bin/searchd \
--config /var/www/website/sphinx/config.conf

If you get any errors, I’d recommend going back and reviewing the configuration and re-running the indexer, then start searchd again.

If we don’t have any errors, we can run a test outside of Joomla to see if everything is working correctly. For example:

/usr/local/sphinx/bin/search \
--config /var/www/website/sphinx/config.conf \
"Hello world"

Install & Configure Joomla Plugin

You can download the plugin here (Download) or at the bottom of this article.

Enable the plugin. Be sure to turn off other search modules while you’re at it. It is much easier to determine if your search results are isolated to one plugin.

If you are hosting Sphinx on the same server as your web service, you’ll probably want to keep these similar to what I have. Otherwise, be sure to fill-in the appropriate fields here and configure any firewalls that may be between the web server and the Sphinx server.

You will also want to be careful to use the same name of your index defined in your config file. In my example I’m using mywebsite_articles. This is what I fill-in for Resource Name.

Test Sphinx Plugin

The only thing left to do now is to actually test the thing. Go to your website and do a search!

Completing the solution

There are a few things still missing from this setup that I want you to be aware of.

First, if you don’t update your index periodically, you will only see the content that you indexed the first time. One solution is to setup a scheduled task (or cron) to re-index your content. Notice as well I put --rotate at the end of my indexing operation. Once Sphinx has updated the index, it will begin to use the new index to search with. You don’t need to restart your searchd process, just update the index.

Second, you should be aware that if your server restarts you’ll need searchd to start automatically. An init script would work great, even something as simple as this:

/etc/init.d/searchd

#! /bin/sh
NAME=sphinx
DAEMON=/usr/local/sphinx/bin/searchd
CONFIG=/var/www/website/sphinx/config.conf
[ -x "$DAEMON" ] || exit 0
case "$1" in
  start)
    echo "Stopping any running daemons..."
    $DAEMON --config $CONFIG --stop
    echo "Starting sphinx search daemon..."
    $DAEMON --config $CONFIG
    ;;
  stop)
    echo "Stopping sphinx search daemon..."
    $DAEMON --config $CONFIG --stop
    ;;
  *)
    echo "Usage: $NAME {start|stop}"
    exit 3
    ;;
esac
:

plgSphinxContent-v2.zip (Sphinx Search Plugin)

Downloads: 7 File Size: 13.1 KB

So when Google released their Closure library almost three months ago I thought to myself:

“Huh, that looks pretty cool. A modular, lightweight framework that has great UI tools. What’s not to love!?”

I wanted then to write a post back then detailing how excited I was about it, but enough people wrote good pieces early on ( here, here, and here) and I didn’t want to add to the noise.

In the meantime, I decided to use Google’s Closure in one of my projects. I needed to build an RIA (Rich Internet Application) type website that needed to dynamically pull in a lot of data. Having gotten through most of that project I feel like I can substantiate a review of the framework.

Great for UI, not so great for the basics

I initially got exicited about Closure becuase of the quality of UI elements that Google was distributing with the API. I assumed that everything has this same level of abstraction from the nitty-gritty and would simplify my code.

The failings of Closure exist in the simple tasks not the complicated ones, adding HTML to the DOM, doing an Ajax request, and even element selection. I’ll go into detail about each of these.

HTML Insertion

It’s easy to use element.innerHTML, but some work needs to be done to allow those added element to respond to events in all browsers. For example, IE6 will not register an event fired by an element created via innerHTML. If, however, that innerHTML is applied to an element outside the DOM and afterwards added via appendChild, then it works.

The following is a comparison of the same code:

Raw Javascript (5 steps)

var html = "<ul><li>a</li><li>b</li><li>c</li></ul>";
var el = document.getElementById( 'id_of_element' );
var container = document.createElement( 'div' );
container.innerHTML = html;
el.appendChild( container );

Google Closure (4 steps)

var html = "<ul><li>a</li><li>b</li><li>c</li></ul>";
var el = goog.dom.$('id_of_element');
var fragment = goog.dom.htmlToDocumentFragment( html );
el.appendChild( fragment );

jQuery (2 steps)

$('#id_of_element').html(
    "<ul><li>a</li><li>b</li><li>c</li></ul>"
);

Doing an Ajax Request (specifically JSON):

Here is a quick example of handling an Ajax request w/ some minor JSON validation. You don’t use eval() do you?

Raw javascriptTo be fair I don’t know if this one works

// Assumes we have a valid XmlHttp object via GetXmlHttpObject()
xmlHttp=GetXmlHttpObject();
xmlHttp.open("GET","form.php?format=json",true);
xmlHttp.onreadystatechange = function() {
    if (xmlHttp.readyState == 4) {
        var data = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
	    text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
            eval('(' + text + ')');
        // …
    }
});

Google Closure (4 steps)

goog.net.XhrIo.send( "form.php?format=json", function( event ) {
    if ( event.isSuccess() ) {
        var data = event.target.getResponseJson();
        // ...
    }
);

jQuery (2 steps)

$.getJSON('form.php?format=json', function(data) {
    // ...
});

Element Selection

I’ll admit, this is an unfair test since jQuery will always win this one. But the point is that Google doesn’t even try to make this easier for the programmer. Aside from some convenience functions there is nothing special. In my mind this proves the point that Google is much more focused on solving the complex problems and not the simple ones.

Raw Javascript

var el = document.getElementById('id_of_element');
var myDivs = []; // … just not worth writing this by hand

Google Closure

var el = goog.dom.$('id_of_element');
var myDivs = goog.dom.getElementsByTagNameAndClass('div','menu-item');

jQuery

var el = $('#id_of_element');
var myDivs = $("div.menu-item");

Conclusion

It’s not that Google Closure is bad, it’s not. And don’t discredit it because I don’t want to use it. There are a ton of great applications for it and I am very happy they released it. The main issue as I see it, is that just isn’t designed for rapid development — a feature I put high emphasis on. I don’t want to downplay any of their hard work but from my perspective I don’t see as much value in it as I used to.

If you’ve used Joomla before, you may be aware that there are built-in caching features which you can activate to reduce the number of expensive database calls needed to render a page. This feature is also available to your own custom code, whether that be in the form of components, modules, or plugins.

The actual mileage for this feature may vary due to the speed of the server and what Joomla decides to cache. Personally I think Joomla’s use of caching, specifically how they use it for articles, leaves something to be desired. The downsides include content that doesn’t get flushed out once it has changed or content that has too short of a lifetime to prove useful. Because of this, I don’t think lot of developers realize that you can use it to cache your own components, plugins, and modules reliably and without affecting the user experience in a negative way, all the while in a modest environment (i.e. a server environment that doesn’t have special software like memcached installed.)

You might consider implementing a little caching if:

• Your code is heavy and slow (Don’t take it personally, mine is too sometimes)
• Your code is high-latency requiring network resources that may or may not actually be available
• You have a crazy number of visitors and your database is becoming a significant bottleneck

In my own recent project I was able to improve my access times of some SOAP requests by 500% (~1 second/request down to ~200ms/request).

Let’s get our bearings

Here’s a basic example of some code which initializes a JCache object and get’s some data using it. You’ll notice that there are two functions, one which just generically gets some data getData and another function getDataCached which instantiates the cache and calls getData. We need to do this so that our cache is aware of what the inputs and outputs are, that way it can do a lookup on the cache and return data without ever touching getData.

com_cachetest/cachetest.php:

class CacheTest {
    function getData($url) {
        // ... Get some data

        // in this case, I'm just returning some dummy data instead of
        // downloading a web page which if we plan for the worst case scenario,
        // might not be available.

        $data = $url;

        // send data back
        return $data;
    }
    function getDataCached($url) {

        $group = "cachetest";
        $function = array("CacheTest", "getData");

        // get a cache object and name it something useful
        $cache =& JFactory::getCache( $group );
        $cache->setCaching( 1 ); // enable caching (1 = enabled, 0 = disabled)

        // call our function "getData" through the cache
        $result = $cache->call( $function , $url);

        return $result;
    }
}

$data = CacheTest::getDataCached( "http://example.com" );
var_dump($data); // to see what we actually get

Fault Tolerant Caching

One issue in the above example is that if getData returns some bogus data, it’s going to be stuck in the cache and you won’t realize it until it’s too late. This isn’t a likely scenario for a quick database call but if you have a network request that is waiting and waiting and eventually reaches timeout, the cached data will possibly be empty. This can be problematic but it’s also easily avoided. In the following example we do a quick check to see if the data is invalid, remove the old data and get a fresh copy.

com_cachetest/cachetest.php:

class CacheTest {
    function getData($url) {
        // ... Get some data

        // in this case, I'm just returning some dummy data instead of
        // downloading a web page which if we plan for the worst case scenario,
        // might not be available.

        $data = $url;

        // send data back
        return $data;
    }

    function getDataCached($url) {

        $group = "cachetest";
        $function = array("CacheTest", "getData");

        // get a cache object and name it something useful
        $cache =& JFactory::getCache( $group );
        $cache->setCaching( 1 ); // enable caching (1 = enabled, 0 = disabled)

        // call our function "getData" through the cache
        $result = $cache->call( $function, $url);

        // Check if we get sane data. Depending on your data this
        // could be more than just an empty check
        if ( empty( $result ) ) {

            // find the id to remove data for
            $id = $cache->_makeId( $function, $url );

            // invalidate this entry in the cache
            $cache->remove( $id, $group );

            // call our function again knowing the cache has been fixed
            $result = $cache->call( $function, $url );
        }
        return $result;
    }
}
$data = CacheTest::getDataCached( "http://example.com" );
var_dump($data); // to see what we actually get

In Closing

Joomla’s caching API is simple and, by default, just writes these cache files to disk. Although not the fastest approach the default options are really handy for a less-than-stellar server setup. These caching options are available to even shared hosts. At the same time, I should mention that Joomla has done a fantastic job of integrating support for more advanced caching systems like memcache and xdebug so that the above code can be run even faster without any modifications.

joomla-caching-example.git (Programmatic Caching in Joomla 1.5 with Fault Tolerance)

Downloads: 64 File Size: 0.0 KB

NOISE.

There are tens-of-thousands of people posting blog posts about the same exact thing. For example, recently I needed to write a plugin that would display the results of a search on a page in the content area. I looked it up on google and found thousands of articles on “How to write a wordpress plugin”. Each one describing in nearly the EXACT same words how to accomplish the very first step in writing a widget (and only a widget… certainly no-one would want to write something ELSE!) Nothing more. I was only able to get some success after reading the source code of about 15 other plugins.

While working on a different wordpress site, I was looking for some ways to save time and use a plugin I was SURE someone had made (something that could rename page titles in the menu). But again there are tens-of-thousands of people posting articles on “The top 10 plugins to save you time” and “The 20 plugins every wordpress developer should know about!” Maybe I’m being a little nieve that there are actually people who would be stupid enough to title ther articles that way and actually have USEFUL content. Silly me.

Before I accumulate too many haters though I should validate that WordPress is a good system. I like it. In fact, it seems to be the BEST platform for SEO related functionality and it fits the blog role very well. The themes are funky but there are a lot of options out there and the plugin library is vast, if misleading.

Do the community a favor next time you post an article about your favorite tool. Ask yourself this question “Is this article helpful or am I just adding to the noise?”

The Problem:

Ajax requests don’t seem to be working in IE, but there aren’t any error messages and nothing fails like you’d expect it to—the only real issue is that the content is not updating. Everything works as expected in Firefox, Safari, Chrome, etc.

The Solution:

This problem is because IE has aggressive caching in place for Ajax requests. This is bad. Why is this bad? Because we commonly use Ajax to refresh content and make updates to our data. Unless we make some updates to our code, we will see stale information and mislead our visitors.

We can fix this pretty easily though. Some people claim that by switching our GET requests to POST that we’ll solve the problem at hand. I didn’t have any luck with that. Instead if you assign a header explicitly telling the browser to invalidate the page after viewing it, you can prevent IE from caching the page.

In PHP you do it like this:

Built-in wireless on MacBook (and possibly MacBook Pro) is unable to connect to any wireless devices following an update to OS X (10.5.8 — released Aug 5, 2009)

Connection issues include not being able to connect to a wireless network (“Connection Timeout”) and high amounts of packet loss.

Solution:

Apple released a patch to fix this issue, just run software update (in System Preferences) and make sure you install the package that is like “AirPort performance while on battery power”. This will undo the bug they introduced in the 10.5.8.

That did it for me.