Skip to end of metadata
Go to start of metadata

Hi,

I'd like to share the experiences we had with our Ordina company wiki, which has been upgraded the 11th of May (2009), to Confluence 2.10.3 and ATB 3.3.3. In particular, the menu's and its performance.

Ordina is a consulting firm in the Netherlands, hence we use the wiki for sharing knowledge and collaboration. Currently we have about 1700 users, growing to a 5000.

We started to build the new GUI with aspects from the Adaptavist (v4) in mind. A menubar, with edit and tools menu.

One thing we think is very important: all spaces should be easy accessible to users / colleagues. Users must be encouraged to visit other spaces than just their favorites.

We have about 80 spaces, divided among 11 categories. What we did was putting 6 menus on the menubar, most menus have submenus in order show the 11 categories. Nine categories are visible to everyone, spaces of 2 categories might be restricted.

Menu performance initially
The first attempt was a combination of space labels,

Unknown macro: {wikimenu}

, and the reporting plugin with the space reporter. That was repeated for each space category, 11 times. It was painfully slow initially (on the staging environment, running inside a VMWare instance). Showing a page took easily over 20 seconds.
One of the things that helped was changing the filter for space labels from space-reporting to a collection-filter combined with a text filter. That increased speed to a 4 - 8 seconds per page.

With this settings, we went live...

After tuning
It was quickly obvious that the slow part of the rendering was the menubar - by using a special 'mobile' layout on normal browsers, which didn't have a menubar at all. With that, it seemed so much faster. Thanks again for the tip for adding '?layoutId=MOBIEL&latch=true' to the URL!

With some trial and error, and still wanting to display about 80 spaces in the menu's, it turned out that

  • {compound-menuitem} macro for each space (= menuitem) with custom link is fastest. Probably because it skips the permission checking part (~70 times)
  • for spaces which must be restricted, we use
    {menuitem}[Menu item 1|SPACE1:Home page 1]{menuitem}
    
  • The menubar is not shown when editing a page of newsitem

Other observations

  • The cache macro. Potentially problemsolving! Not, it gave errors on the dashboard, maybe related to importing the menubar code from a special space/page
  • We tried
    \{wikimenu}
    * [Menu item 1|SPACE1:Home]
    ...
    * [Menu item x|SPACEx:Home]
    \{wikimenu}
    
    This wasn't bad, but it turned out that the one we've chosen (above) was about a second faster.

By now, we see pages coming back in a 2 - 4 seconds. This is regarded acceptable, given the desire for 80 spaces in menus...

Regards, Herman.

  • No labels

21 Comments

  1. Unknown User (gfraser)

    You can speed up the menu even more by using static hyperlinks:

    {wikimenu}
     * [space 1|http://something.com/display/space1]
     ... etc ...
    {wikimenu}
    

    If you need to use relative URLs you can do something like this:

     {compound-menuitem:custom|link=/display/space1|caption=Space 1}
    

    We also found that getting the case correct for space keys has an effect, eg. if your space key is "SPACE1" then accessing it via "space1" will be slower depending on the version of Confluence you're using.

    When using the cache macro, ensure it's only caching the links, not the menubar macro - the cache macro has a nasty habbit of breaking any macro that uses JavaScript, eg:

    Good

    {menubar}
     {cache:1d}
      {wikimenu}
        links go here
      {wikimenu}
     {cache}
    {menubar}
    

    Bad

    {cache:1d}
     {menubar}
      {wikimenu}
        links go here
      {wikimenu}
     {menubar}
    {cache}
    
    1. Unknown User (hboer1965)

      Hi,

      does the cache macro work on the dashboard? When placed around a bunch of {compound-menuitem} macro's, what I see on the dashboard is:

      cache: Unexpected program error: java.lang.IllegalArgumentException: Content entity object should not be null
      

      And instead of the menubar, also on the dashboard:

      {builder-hide:action=login,logout} {import:WIKIGUI:Menubalk code} {builder-hide}
      

      Regards, Herman.

      1. Unknown User (gfraser)

        Most third party developers only test their macros on "content entity objects" (wiki pages, blog posts and sometimes comments) however they rarely test them on space level (eg. space admin) or global level (eg. dashboard or search) pages - as a result they'll often break when used in such contexts.

        1. Yes, this is very true ... this also goes for testing from the 'anonymous' context, where even more things are likely to break - for instance attempting to run the atlassian webui link to 'edit profile' will cause a stack-trace when executed from an anonymous context (they just never expected it to be run like that)

        2. Unknown User (hboer1965)

          I discovered when using {include} rather than {import}, the cache macro works for both the dashboard and the menubar (included on all pages and the dashboard).

          Both were initially imported from a wikipage. By changing that into including, the change in behaviour is probably that the page to be included is rendered first, as a content object entity, then incorperated in the calling object.

          It's a change in only two places, so a lot faster than typing this comment (wink)

          1. Unknown User (suedti)

            Hi Herman!

            Can you please specify your "collection-filter" solution more precisely? We have the same problem, but hard-coded menus is not an option because of the complicated permissions.

            thanks

            philipp

            One of the things that helped was changing the filter for space labels from space-reporting to a collection-filter combined with a text filter

            1. Unknown User (hboer1965)

              Hi Philipp,

              Sorry for the late reaction, I was on holiday.

              We improved the performance of our wiki again, over time. Most pages now take 1 to 2 seconds to generate.

              The collection-filter of the reporting plugin is no longer used at our wiki.
              For the 9 space categories without restrictions, we use the wikimenu with the space-reporter in the traditional way, combined with the cache macro (default cache period - 24 hours).

              For the 2 space categories which can have restrictions, we use the wikimenu with the menuitem macro for each item - without caching.

              If we want to improve overall speed even further, we have a few options:

              • upgrade to java 1.6 (and move away from Weblogic 9.2)
              • upgrade to Confluence 3.0
              • new hardware
              • remove most items from the menubar...

              Regards, Herman.

      2. Unknown User (gfraser)

        Adaptavist recently released a new version of the cache macro which works on the Dashboard and other global areas of Confluence (eg. search results, etc).

        1. Unknown User (hboer1965)

          Hi Guy,

          Where can I find that macro or plugin?

          Regards, Herman.

          1. Unknown User (gfraser)

            It's in the plugin repository - from memory it requires at least Confluence 2.10.x, however the mods could be back-ported to an earlier version of the plugin if required.

            The updates we made were part of a performance tuning project we were doing for a customer where we reduced their dashboard loading time from about 60 seconds down to about 2 seconds (smile) The plugin, and our recent mods, is open source.

            1. Unknown User (hboer1965)

              Sorry, I don't see it in the plugin repository. Not in a 2.10.3 and neither in a 3.0 instance. Also not in the plugin exchange...

              Regards, Herman.

              1. Unknown User (gfraser)

                I've just had a chat with the developer and apparently it's not released yet - sorry about that. We'll post an announcement in our open source space when it's released.

                Note: This won't fix issues with other macros (such as include) that were only designed for use on wiki pages. It just fixes some bugs we found within the cache macro itself when using it on the dashboard.

                Apologies for the duplicate posts - our website was being rebooted to fix a sign-up bug and I must have clicked multiple times.

    2. Unknown User (suedti)

      We experienced a massive performace improvement by putting the reports for displaying spaces by teamlabel into single pages (cache 1h.
      Then we include this pages into a wikimenu construct.

      Content of page "menu-studium":

      {cache:1h}{report-list}
      {space-reporter:space=@global}
      {text-filter:space:labels\|include=.*studium*.}
      {text-sort:space:name}
      {space-reporter}{report-body}
      {report-info:space:name\|link=true}
      {report-body}{report-list}
      {cache}
      

      Code for bulder-menu:

      {menu}Studium
      
       {wikimenu}{include:lay:menu-studium} {wikimenu}
      
      {menu}
      
      1. Unknown User (gettes@mit.edu)

        I'm curious - how many total spaces do you have? How many spaces are under the team labels total and on average belonging to each team label? I ask because I am curious what leads people to make such customizations to deal with performance issues.

        thanks

        1. Unknown User (suedti)

          Approx. 10-15 Spaces for every Label. ~40 global Spaces, but ~2000 personal Spaces.

          The problem is not builder but the slow report macro! But I haven´t found a better solution for a dynamic spaces list, that also takes into account the reading permissions.

          1. Unfortunatley there are no wildcards for the team labels search, but list-spaces should be faster than the reporting macro.

            {list-spaces:global|teams=studium}
            
            1. Unknown User (suedti)

              Thanks Alain! This was a great hint! All pages loading now within 400ms (with cache=1h)

              philipp

              1. Unknown User (hboer1965)

                Hi Philipp,

                good times you have there!

                With profiling, we measured that full menubar takes 460ms on average, of which the generation of the view/tools and edit menu takes about 102 ms and 70ms.

                Regards, Herman.

                1. Unknown User (gfraser)

                  At Adaptavist, we use Atlassian's Crowd software for user management and SSO - we found that by upgrading to 2.0 performance across all applications (Confluence, JIRA, etc) was significantly improved due to extremely fast user lookups and permission checking. So always profile the permission checking (eg. if you use Active Directory / LDAP) as that's one of the areas that regularly causes performance issues.

                  1. Yep, it's the permission checking that consumes the most time when doing pretty much anything in confluence however the menulinks are especially heavy on permission checks since each one may have to check several kinds of permission against the content being viewed.

                    We cache the results in the request to avoid them being checked multiple times, however they still need checking the first time and if you have a slow connection to your LDAP/SSO server then this latency will get passed down the line to your confluence install.

                    One great tactic to speeding things up is to remove the menulinks that you dont actually use from the default view/edit menus (as we have done on adaptavist.com), by cutting down on the number of menulinks, you reduce the number of permission checks and everything gets faster.

                    Another is to group menulinks behind a builder-show/hide macro which checks a more broad-based permission, for instance one 'quick fix' might be to wrap the edit menu macro in a single check for edit permission.

                    {builder-show:permission=edit}{editmenu}{builder-show}
                    

                    That will of course mean that people without edit, but with comment permission wont be able see the 'newcomment' link that they would normally see, so you'll need to put this elsewhere in your layout.

    3. One alternative to using the 'custom' menulink to link to pages/spaces/urls is to use a menulink alias ... this means that your 'static' url is defined centrally and can be re-used across multiple layouts.

      It also makes for cleaner markup since rather than 'custom' link-type and a url you can name the link-type to suit. For instance if you were to define the a menulink alias called 'space1' with a target of SPACE1:Home then your markup would look like this:

      {compound-menuitem:space1|caption=Space 1}