Support » Requests and Feedback » Caching main view into serialized string

  • Resolved qingshuo

    There have been lots of requests (even back in b2) for building static HTML front pages so sites with many hits to the front page can get a performance bonus.
    While I do believe avoiding trips to the database for common views such as the main page is a good idea, I find the flat HTML concept a but archiac (and MT/CGI-ish!) since comment counts clearly are too dynamic to be “flattened” and it also prevents other dynamic applications from working on the front page short of a complex SSI framework.
    I suggest using object serialization to cache data. Once the front page’s worth of posts has been retrieved from the database, WordPress can create a cache file and write the serialized resultant object into that file. On next access, WordPress will identify the hot cache, pull out and unserialize the string and boom! all of the recent post data is in memory without going through a database search. This method allows comment counts to stay purely dynamic AND other dyanamic applications keep working.
    Suggested implementation —————————
    In blog.header.php, the last line says
    $posts = $wpdb->get_results($request);
    We want $wpdb->get_results() to be able to detect if a front-page-non-specific view is being used (by looking at the query string and making sure select-modifying variables are empty()). If it is a front page view, get_results() will attempt to look for a hot cache file, read its string, and return the unserialized value.
    There will need to be a function that does the actual front-page query and populate the cache file (not too tough right?). This function needs to be triggered upon new post and edit post. Function should check the time stamp of the new/edited post and compare it with the last timestamp of the cached posts.
    If the WordPress team likes this idea, I can work on this over the next 2 days and send in code bits of my implementation (unless you think you’ve got it down ;-).
    If anyone thinks thereis a better way besides using serialization…well YOU’RE WRONG! j/k 😉 Correct me!

Viewing 4 replies - 1 through 4 (of 4 total)
  • One thing I’ve played with in the past (actually had it working if I remember correctly) is buffering the entire output of the index page and storing it in a “cache” table. Check the date/time of the cache version against the latest comment/post date/time and update the cache version if it neededs it – if not, just show the cached version.
    Doing this took my page load time from 2.4 seconds to .3 seconds. Maybe I’ll resurrect that code (if I still have it) and play with it some more.

    That method is similar to generating a full static HTML page. Problem is
    1. Comment counts update quite often, and it may not be worth it to cache those, but that varies per page.
    2. Other dynamic PHP applications running on the same page will fail. Namely, if I have a miniboard/shoutbox or a mood-meter or a mini-calendar, it will get cached by WordPress and WordPress obviously has no way of looking inside other apps data to see if they need updating..
    3. Checking against the lastest comment/post date/time causes yet another database query. Update should be triggered by events such as new post or edit post and not “checkups” that eat up performance themselves

    For #2, the performance of getting a new cache page is the same as the current page loading – so it didn’t bother me. Some people get faster performance, some get the current performance. The performace difference is HUGE even with the checking you refer to #3, but I tend to agree with you in general. The reason I stopped working on my hack was because the Smarty caching features (Donncha implemented them in b2++ and he is part of the WP team) are supposed to take care of a lot of these issues.

    I’m thinking another idea would be to seperate the b2 loop into a different file and cache that individually as raw text output, then use PHP to send it back. (PHP’s drawing and include functions are sooooo fast people can hardly feel the difference between a flat HTML and a frankensteined PHP page). But that method is really a hack on the index page. In the end, I think serialization is the most elegant method since it requires NO changes to be done on the user end.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Caching main view into serialized string’ is closed to new replies.