Having spent some time in the deep guts of s9y (though perhaps not as much as Garvin for example) looking for potential optimizations, I have a few suggestions for users if they want to tweaking out their s9y install to get it going faster:

If you run S9y on a hosting service or similar

Your optimization options are somewhat limited, but there are still some things you can do:

Don't use many markup plugins

The less markup plugins the better. Consider using a WYSIWYG editor instead, and use the markup plugings sparingly. Emoticate is a particularly nasty markup plugin.

If you do use markup plugins, use the cache if you can.

The entry properties plugin allows you to cache the output transformation of entries, which can be a big bonus. It isn't compatible with some other plugins, so you will have to experiment, but the potential savings could be quite something, especially if you depend on some of the heavier transformation plugins.

Optimize the stylesheet

I go into details about this Here. It does take some massaging, and if you add a new plugin, sometimes you have to edit your main stylesheet or everything goes wonky. The chief benefit here is that you can get some cache benefits from including static stylesheets through @import, and plugins that parse the stylesheet to add their own styles have significantly less text to parse through.

But if you are a control freak...

Opcode Cache

This is the single biggest thing you can do to improve S9ys speed. APC is my favorite.

Cache Control

Use the apache modules for cache control and set it up to cache css and image files in your templates directory, and perhaps even your uploads directory.

Assuming that you are using the Expires module for apache 1.3, you would want something like this:

    ExpiresActive on
    ExpiresDefault "now"
    <Directory /var/www/jonnay.net/blog/templates>
        ExpiresByType image/gif  "access plus 4 days"
        ExpiresByType image/jpeg "access plus 4 days"
        ExpiresByType image/png  "access plus 4 days"
        ExpiresByType text/css   "access plus 4 days"
    </Directory>

The "access plus 4 days" really depends on your needs, you might want to change that to 2 weeks, or even 2 months. It depends on how often you re-design, and when you plan on a redesign next.

Been working with winkiller on optimizing serendipity (the software that runs my blog). Optimizing code is hard work. So far the results are: It is hard work finding what needs to be optimized, and it is even harder work optimizing what can be optimized.

Before I start, a few caveats:

• Most of the numbers here are pulled out of my ass. For instance, the 80/20 rule is invoked. The 8 second load time is the load time it took for s9y to execute on my slow-server.
• I don't really know much about the PHP internals, especially with regards to conditional includes (include_once for instance). All my suggestions from from my understanding of what Rasums says about conditional including.
• Most of this is just guesswork

A few of the things that I have found so far though:

• A large part of the performance problem lies in what I would call the 'sub-resources' of serendipity. The fact that loading the stylesheet and the css loads the entire S9y framework makes a big difference. Optimizing this means re-thinking the dynamic nature of the javascript and stylesheets. It would be the biggest and best optimization S9y could make, but also, the hardest. This would require a break in backwards compatibility. Not a bad thing, but not something to do lightly either. As it stands, if it takes 8 seconds to parse and execute s9y, it takes 32 seconds to actually fully load the front-page of the blog.
• Some performance could be gained in how includes are included. Mostly by removing include_once wherever possible, and using a straight include. (this also counts for conditional includes as well). This would be especially true when using an opcode cache.
• Related, would be how plugin loading and instantiation is handled. The loading of plugins could be handled at the initialization of s9y, again, in a non-conditional manner. Perhaps the best way to do this would be to keep a list of plugin files to load, and on plugin addition or removal, turn the list into a short PHP include that includes the required plugins. The speed increase may be especially significant for users with opcode caches.
• Any other optimizations would be small and numerous, but would have an overall net effect of raising the speed. Sadly, it appears (at least to my untrained eye) that 80% of the code would need to be optimized to gain a 20% speed increase.

In conclusion, the direction of S9y optimization really depends on how S9y is going to handle it sub-resources in the future. If S9y is going to be optimized further, either the sub-resources need to be modified so they do not load the entire monolith that is s9y, or, the 80% of code that I alluded to needs to be optimized, so that we can see a 60% gain. (20% gain, * 3 requests). Obviously it is better to make the sub-resource only take 1 second (for a total of 10 seconds loading the page, 8 for the main s9y, 1 for each sub-resource) rather then make everything load 2 seconds slower (for a total of 18 seconds load time).

John Lim over at PHPEverywhere has a good guide on squeezing code with xdebug.

Upgrade S9y from 0.8 to 0.9.

Asside from a wierd password meef that happens about every time I upgrade (and I don't know why), everything worked like a charm.

Damn, dispite its warts (SLOW!) I love this software.

Bam.

Supa easy.

Overwrite files, it says "Okay, you're upgraded. All good".

Bam.

Except this pasword thing, it always defaults back to my old DB password. It might hav eto do with the fact that I never changed it through the S9y interface. No biggie however, I just edited the config file and all was good.

Distpite the warts, I love S9y.

Another freetag plugin beta for all'y'all. (Previous beta was Here)

I've modified the tag list on the entry screen to be a little more user friendly, modified the RSS output a tad, and changed the output of the default css to be a little friendlier, especially when using my CSS optimization.

Tag intersections should be coming soon, I am really craving them. I just have to hack on the SQL a little more. Right now It is looking like a really massive (and bad) left join query that gets worse as you intersect more tags.

Install Instructions

• Un-tar to your plugins directory
• Go to your plugin administration, and configure the sidebar plugin. If your database needs to be upgraded, it will happen automagickally
• Bask in taggy goodness!

One of the most annoying things about S9y is the fact that the main stylesheet is a PHP script, which includes the bulk of the S9y codebase itself. Not only does this make retrieving the stylesheet a non-trivial operation, but it also means that the stylesheet itself cannot be cached. The reason why the S9y developers chose to do this is so that plugins can check to see if any styles are defined for particular classes, and if they are not provide reasonable defaults.

As an aside, a better method might be to call the main css file statically, and have each plugin provide its own static css file. It is trivial to check to see if 'my_plugin_name.css' exists in the current theme dir. All this could be done in the head block.

In the meantime, for any S9y theme authors, or even anyone who just wants to make their S9y installation just a little faster, here is a great fix:

1. In the current theme you are using, copy the style.css to main.css.
2. Change style.css to this: @import "/templates/your-theme-dir/main.css;.
3. View the text of http://yourblogdomain/serendipity.css. Ideally you should just have the @import directive.
4. If you don't that means that some plugins are defining their own default styles. To make sure the directives in your /main.css override them properly, you can just put the name of the class in a comment. For instance, I override the defaults of the FreeTag and searchQuery plugins in my style.css. So, my main css looks like this:

   @import "/templates/midibuffer/main.css";
   /*
   .serendipity_searchQuery {}
   .serendipity_freeTag {}
   */

There ya go. hopefully that will speed you up a little.

Technorati have finally gotten back to me about how to set multiple tags in the RSS/Atom feeds. Horray! The long and short of it is here: Technorati Developer Tag Help.

So the next step is to make the freetag plugin integrate with the RSS feeds. I'd also like to get some kind of 'tag definition' and 'tag tagging' happening. Tag definitions are easy, it would be a text description of a tag. Tag tagging would let you tag tags with other tags... which is to say, I could tag 's9y' with 'php'; tag 'php' and 'scheme' with 'code', and they would all link together. (so by tagging something with 's9y', it would automagickally fill in 'php' and 'code' for me).

All this is leading up to a better tag page. Right now hen you go to the page for my homo tag, you are presented with a list of related tags, and all posts that are related to "homo". In the future, It should give the tag defenition, any 'meta-tags' associated with it, and grab some other tagged media. flickr pictures, del.icio.us links being the first two, but ideally it should be sub-plugin-based, so that one could easily integrate Technorati, colr, or even freesound

If you want to help beta test the plugin, it is available Here. Just un-tar to your plugins directory.