Theme Builder is now used on some extremely large and popular wikis - both behind corporate firewalls, on the public Internet and even the world's largest privately owned hospital ship! As your wiki becomes more widely adopted, things that used to work quickly may start to become bottlenecks and your configuration of Theme Builder is no exception.

Performance Tuning in Theme Builder 3.x

Page under construction

We've done some of it for you!

...

• The average theme design now only uses 8 5 external JavaScript files instead of 11
• Several More resources (such as Custom CSS) will now be cached by the web browser for up to one year or until they are next modified (whichever is soonerare using Cache Expire (1 year)
• Theme layouts contain much more intelligent caching on the server to reduce processing time
• The default View and Edit menus are 3 times faster thanks to compound items
• We've waded through the HTML, JavaScript and CSS with all manner of diagnostic tools and made huge numbers of improvements throughout the plugin
• We've refactored huge swathes of the Java code used in the plugin to make it cleaner, faster and more maintainable

... more to follow ...

Use fewer macros

It turns As a result of Theme Builder 2.x, we found out that every macro has an overhead caused by the work Confluence has to do to process it... A surprisingly large overhead which quickly mounts up if you're using lots and lots of macros on every page!

The more macros you add in to your theme layouts, the slower the theme will be regardless of how fast those macros are. Before a macro is even executed, Confluence has to do all kinds of work (parsing parameters, wiki rendering the macro body, etc) so you need to use macros carefully and sparingly.

Remember that when you add macros to layout panels, they'll be executed for every user on every view of every page that uses that layout. That's going to hammer your server.

However, you probably wouldn't be adding macros to the layout if there wasn't a need for them. So what can you do to solve this dilemma? Well, there are a number of solutions...

Use the cache macro

The cache macro allows you to cache the output of a macro. On subsequent views of the same page, if a cache is found then it's used instead of reprocessing the macro (or other wiki notation encapsulated by the cache macro).

...

• builder-show macro and builder-hide macro
• show-to macro and hide-from macro
• show-if macro and hide-if macro

Use compound menu items

If you use the menuitem macro, menulink macro and menuicon macro a lot, try converting your markup to use the new compound-menuitem macro which can reduce the number of macros used by one thirdtwo thirds (from 3 to 1)!

...

The default menu notation output by the viewmenu macro and editmenu macro has been updated in Theme Builder 3.0 and above, however if you've altered the notation or moved links out in to other locations, etc., you should certainly consider converting your notation over to the new compound format.

Likewise, if you've imported a theme designed in an earlier version of Theme Builder, it'll be using the old menu notation that used a lot more macros.

See Also: View Menu 3.x and Edit Menu 3.x

Avoid CSS imports

In earlier versions of Theme Builder, it was difficult to have one master CSS file that would be used across multiple spaces so many of our clients created a css file and imported it in to the Custom CSS using the CSS @import directive.

...

You can now add CSS that's specific to the child layout and it will be output along with the CSS from the parent layout (the parent CSS is output first allowing the child CSS to override bits of the parent CSS if desired).

Go Low Level

Macros and wiki notation are effectively high-level elements - they sacrifice performance in order to be easier to use.

If you want to gain performance, you're going to have to use something a little more complex...

HTML, XSLT, etc

There are a range of macros that take advantage of widely used technology such as HTML (see html macro and html-include macro) and XSLT etc.

These generally require that you understand the syntax of whatever technology they offer, but require far less processing time on the server.

User Macros

Confluence allows you to create "User Macros" in the Administration Console. These allow you to more safely add raw HTML content to your wiki and also allow you to take advantage of the Velocity engine to perform basic scripting, etc.

Scriptix

Note: This plugin requires the latest production version of Java (version 6) – which is not yet officially supported by Atlassian for use with Confluence. That being said, we're now using it on several sites.

Adaptavist's Scriptix plugin allows you to create server-side scripts in languages such as JavaScript, PHP (Quercus), Python (Jython) – in fact any scripting language listed here.

Because Scriptix uses Java 6, it enables much tighter integration with Java and even allows compilation to byte code of PHP scripts – giving the potential to run even faster than mod_php.

Extreme Measures

If you've got a huge wiki with lots of Spaces and content, or if you've got huge numbers of users accessing your wiki, you'll need to start looking at the server hardware and Confluence itself to take performance tuning to the next level.

Server Hardware

The easiest way to boost performance is to upgrade bits of your server (or even just buy a shiny new one):

• RAM - Java applications like Confluence love RAM. It's a very quick way to squeeze some more performance out of an existing server that's struggling under the workload. If you have over 1GB of RAM in your heap and you're still running out of memory – profile the dumps for memory leaks.
• Faster disk drives - if you use macros that make heavy use of the search index (you'd be surprised how many do this!) or database then investing in a faster disk drive will help boost performance. We generally use 2 or more 7200RPM SATA drives in RAID 1/5 configuration via a hardware RAID controller.
• Faster processor - A faster processor will, erm..., process things faster! For best results invest in a multi-processor 64-bit server with modern multi-core processors.

Clustering Confluence

We made Theme Builder 3 clusterable for a reason If you are following these guidelines, you need to cluster will mainly come from the desire for high availability to reduce the risk from hardware failure.

Other Options

There are a vast array of other options, including changing or optimising your application container (eg. Tomcat or Resin), operating system, database and cache settings.

If you host or access the database and/or file system on another server using something like NAS, you'll likely be adding a huge amount of latency, compared to local storage, as a result. Instead of using remote file storage, look at pushing the attachments into the database and taking manual backups – this will substantially reduce the amount of size needed for the Confluence home directory (potentially multiple TB reduced to under a 100 MB).

See Also

Most of the content of earlier performance tutorials are still applicable to Theme Builder 3.x:

• Performance Tuning 1.x
• Performance Tuning 2.x
• Menu Performance Tuning