.png)
When we use theme builder it takes about 5 seconds to go to different pages. However without theme builder it only takes 2 seconds. Is it normally half as slow when a site uses theme builder?
|
||||
|
||||
Adaptavist Theme Builder Powered by Atlassian Confluence
Comments (3)
Jan 29, 2009
Alain Moran says:
The performance can vary greatly depending on your layout ... if for instance in...The performance can vary greatly depending on your layout ... if for instance in your panels you use lots of macros which take a long time to process then this will have a major impact on performance, as will the html caching options that you have used, also the way that you have defined your menus can affect the speed of page generation. In addition the version of builder that you are using will also play a part ... to be able to give you distinct answers I'm going to need a lot more information about your setup.
If you can start by letting me know which version of builder you are using and attach a copy of your layout settings to the page then I can start highliting the areas that may be causing you problems.
In general we would expect with a 'DEFAULT' layout running on confluence 2.10 or 3.0 that builder will take around 500ms to 1s longer to render than the static confluence theme, this is expected since builder is a dynamic theme and each panel needs to be rendered on every page view ... there are ways to reduce this, for instance using static html in panels instead of wiki markup, you can also use the html caching options to reduce the load on your server.
Jan 30, 2009
David Ay says:
We are using Theme Builder 3.3.2 and confluence 2.9.2 . I attached our layout b...We are using Theme Builder 3.3.2 and confluence 2.9.2 .
I attached our layout backup file. We are using the mercyships layout.
Jan 30, 2009
Alain Moran says:
If you have a slow DB or filesystem then upgrading to 3.3.3 may improve performa...If you have a slow DB or filesystem then upgrading to 3.3.3 may improve performance slightly due to the way it caches internal css files read out of the jar.
Looking at your code you would do well to make more use of menulink aliases, however this should not seriously affect performance but it might clean up your code somewhat, you can also use custom aliases for linking to plugins such as the Gliffy plugin, avoiding an extra macro call - confluence does not deal well with very large numbers of macros - hence us introducing the compound-menuitem which I note you are quite correctly using in preference to the split-apart notation.
The very large menus that you are using are likely to be affecting performance, especially in IE which needs to wait for the page to finish processing before being displayed. Given the incredile slowness of IE's JavaScript engine I would reccomend trying to reduce the size of these menus or if that is not possible use the 'lazy instantiation' checkbox in the menu options tab since that will allow IE to instantiate the submenus on-demand. (aka 'display menus as quickly as possible')
Depending on the content within the {include:spaceKey=NAGeneral|pageTitle=Support Email} page this may also be affecting performance.
Overall it looks like the sheer volume of macros is what is causing your render-time issues, additionaly the size of your menus will be causing browser-side slowdowns in the less capable browsers such as IE.
My initial aproach would be to enable lazy instantation in the menu options tab, I would also take the HTML code that is generated by your 'custom' menulinks and place it into a user-macro since the output of this block will be static for all users ... this will allow you to include that block of html into the menu using the {wikimenu} macro without requiring confluence to render all of those individual macro calls, greatly improving render-time performance.