[All Adaptavist Apps]

Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

Whether you've got 20,000+ users or 10,000+ spaces, there's always a way to maintain the performance of your wiki and Theme Builder. This page contains information on the most recent techniques for improving performance of the theme element of your wiki and contains links to performance tips from previous versions of the theme which are still relevant.(warning) Page under construction

We've done some of it for you!

...

... 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...

...

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

...

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 (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.

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

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.

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!

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.
  • 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.
  • Faster processor - A faster processor will, erm..., process things faster! For best results invest in a multi-processor server and use dual- or multi-core processors.

Clustering Confluence

We made Theme Builder 3 clusterable for a reason (wink)

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 your wiki has become mission critical and you need expert advice, check out our Remote Hosting and Confluence Support solutions.

See Also

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