Performance Tuning in Theme Builder 3.x

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.

...

• 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 Java, 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

...

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)!

...

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.

...

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 (see xslt macro), etc.

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

...

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) to name but a few– in fact any scripting language listed here.

Because Scriptix scrips are executed down in the Java kernel, they're really fast. For example, a PHP script will actually run faster in Scriptix than it would on a web server with PHP installed!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.

...

• 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 server and use dual- or 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. If your wiki has become mission critical and you need expert advice, check out our Dedicated Hosting, Remote Hosting and Confluence Support solutionsInstead 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:

...