Nick's Hotaru CMS Blog

Thinking About Speed

Rate this Entry

3 Comments

Nick

on 01-15-2010 at 03:40 PM (450 Views)

I've updated the demo site to v.1.0.2 (coming soon to the SVN trunk), but it's feeling really sluggish compared to these forums. I'm just not sure why.

Hotaru uses caching quite extensively, especially from the second page view. Here are the stats from the home page of the demo site:

52 database queries and a page load time of 1.8 seconds. This page used 6.9 MB bytes of memory. [Hotaru CMS v.1.0.2]

But it feels more like 6 seconds. Two processes which you would expect to strain the server are (1) checking plugin hooks, and (2) finding and merging all the CSS and JavaScript files from plugins. But...

1) When a plugin is installed, the hooks it uses are saved in the database's pluginhooks table. The pluginHook function queries this table and caches the results for 12 hours, unless a new plugin is installed. So using the cached results should be lightning fast.

2) Hotaru uses PHP's file_exists function to find the CSS and JavaScript files and check their last modified dates. If a file has been modified, all the files are merged into one and archived as a single file which is used until anothermerger is necessary. Apparently, file system access is faster than using a database, so this should be pretty quick, too...

Hmm....

Hold on! How about this:

Even though we know which plugin functions to call at each pluginHook, Hotaru still has to create a new object for every plugin function called. Come to think of it, even the main Hotaru class itself creates new objects for all the functions it redirects to. Perhaps this is the cause of the sluggishness?

Any ideas? Or maybe the demo loads pretty fast for you?

Tags: cache, demo, slow, speed

Categories: Core Development

Email Blog Entry

« A Few Goodies in the Works Main All's Quiet At HotaruCMS »

Comments

Nick - 01-16-2010 07:45 AM

Funny, I was trying to log how long some functions take, but I couldn't get it to work right. Hotaru's constructor was getting triggered three times for every page load... *light bulb* perhaps that's what's causing the site to take about three time longer to load than the forums do? I've narrowed the problem down to the CSS and JavaScript include functions. The SCRIPT tags that get put in the theme's header to include the archived CSS and JavaScript files calls Hotaru once for each, making three times total! Now I just have to find a workaround and we could be looking at a much zippier CMS... maybe...

Edit: I moved it up the code a bit, but it's not made any noticeable improvement.
JonH - 01-17-2010 07:41 AM

Have you visited the demo site with FireBug on the "Net" tab or used FireBug with ySlow? I just tried it out with my browser cache disabled and it's showing the html of the demo to load quicker than this blog page. Analyzing the demo with Yslow, it's showing an "F" grade on ETags - http://www.think-press.com/332/yslow...ty-tags-etags/ and also gzip not enabled but Yslow doesn't report gzip correctly and I'm not sure but isn't Hotaru's caching is similar to gzip?

Expires Headers is another htaccess tweak and would utilize the browsers cache more, but not sure how that can be packaged with the CMS.

Hotaru's HTML is loading around 2 seconds for me and this blog page HTML is around 4 sec.
Nick - 01-18-2010 03:00 AM

Interesting stuff Jon, thanks. I confess I don't know anything about gzip and had forgotten about it! Hmm... there are a couple of things it could work with. I'll investigate that and Expires Headers, too. We might have to leave ETags since the link suggests you cut them out altogether, which we can't do because we use them.

Glad to hear the demo is loading faster than this page for you! It seems to fluctuate for me. As for Firebu, I rarely use it because everything just grinds to a snails pace with it enabled (for me anyway). I might check out ySlow.