Loading Profile...
Size of stored Scaffold data on the page
Is there a limit on the size of stored Scaffold data on the page?
In our case, a page contains 90 records of repeating-data. Each record consists of 9 data fields (date, list, text,number). The page with the data is loaded about 3 minutes.
What is the problem? Help
In our case, a page contains 90 records of repeating-data. Each record consists of 9 data fields (date, list, text,number). The page with the data is loaded about 3 minutes.
What is the problem? Help
I’m sad
1
person has this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
-
Inappropriate?Hi Sheella,
There is no artificial limit on scaffold data, but keep in mind that some types of data can be expensive if you run them 90 times on a page, particularly when editing. If you post your wiki markup I might be able to suggest some places where performance is suffering.
David -
Inappropriate?{show-if:action=edit}
{repeating-data:Release}
{table:width=100%|class=tab_release|cellpadding=0|cellspacing=1}
{tr}
{th:width=21%}Organization / Country / City{th}
{th:width=17%}Training dates{th}
{th:width=20%}Course title{th}
{th:width=15%}Location \\ Responsible person{th}
{th}Attendee\\{th}
{th}Position{th}
{th}Duration \\ (in days){th}
{tr}
{tr}
{td}
{replace-and-render}{replace-body}{list-data:Organization|type=select|width=90%|blank=true}%org%{list-data}{replace-body}{replace-item:%org%}{report-on:data:Organization|source=Catalogue|injected=true}\{list-option}{report-info:organization_data}\{list-option}{report-on}{replace-item}{replace-and-render} \\ \\
{replace-and-render}{replace-body}{list-data:Country|type=select|width=90%|blank=true}%count%{list-data}{replace-body}{replace-item:%count%}{report-on:data:Country|source=Catalogue|injected=true}\{list-option}{report-info:country_data}\{list-option}{report-on}{replace-item}{replace-and-render} \\ \\
{replace-and-render}{replace-body}{list-data:City|type=select|width=90%|blank=true}%count%{list-data}{replace-body}{replace-item:%count%}{report-on:data:City|source=Catalogue|injected=true}\{list-option}{report-info:city_data}\{list-option}{report-on}{replace-item}{replace-and-render}
{td}
{td}
{date-data:training_begin|format=dd MMM yy|minYear=2006|maxYear=+15}\\ \\{date-data:training_end|format=dd MMM yy|minYear=2006|maxYear=+15}
{td}
{td}
{replace-and-render}{replace-body}{list-data:Course|type=select|width=90%|blank=true}%cur%{list-data}{replace-body}{replace-item:%cur%}{report-on:data:Course|source=Catalogue|injected=true}\{list-option}{report-info:course_data}\{list-option}{report-on}{replace-item}{replace-and-render}
{td}
{td}
{replace-and-render}{replace-body}{list-data:Location|type=select|width=95%|blank=true}%loc%{list-data}{replace-body}{replace-item:%loc%}{report-on:data:Location|source=Catalogue|injected=true}\{list-option}{report-info:location_data}\{list-option}{report-on}{replace-item}{replace-and-render} \\ \\
{list-data:Person|type=select|required=false|blank=true|width=95%}{user-options:groups=confluence-users}{list-data}
{td}
{td}
{text-data:report_alias|type=line|width=150px} \\ \\ {list-data:report|type=select|multiple=false|width=150px|blank=true}{attachment-options}{list-data}
{td}
{td}{text-data:position|type=line|width=150px}{td}
{td}{number-data:duration|type=line|width=30px}{td}
{tr}
{table}
{repeating-data}
{show-if}
{show-if:action=view}
{section}
{column:width=100%}
{table-plus:columnTypes=S,S,S,D,S,S,S,S,I}{cache:refresh=1d|showRefresh=true|showDate=true}
{table:class=tab_release|cellpadding=0|cellspacing=1}
{tr}
{th:width=14%}Organization{th}
{th:width=7%}Country{th}
{th:width=7%}City{th}
{th:width=10%}Training dates{th}
{th:width=20%}Course title{th}
{th:width=15%}Location \\ Responsible person{th}
{th:width=12%}Attendee{th}
{th}Position{th}
{th:width=5%}Duration \\ (in days){th}
{tr}
{report-block}
{local-reporter:data:Release}{local-reporter}
{report-body}
{tr}
{td}*{report-info:Organization}*{td}
{td}{report-info:Country}{td}
{td}{report-info:City}{td}
{td}{report-info:training_begin|format=dd MMM yy} - \\ {report-info:training_end|format=dd MMM yy}{td}
{td}*{report-info:Course|render=wiki}*{td}
{td}{report-info:Location|render=wiki}\\{report-info:Person|link=true|render=wiki}{td}
{td}{report-info:report_alias}\\
{replace-and-render}
{replace-item:%link%}{report-info:report}{replace-item}
{replace-body}
{attachment:Training feedback|%link%}
{replace-body}
{replace-and-render}
{td}
{td}{report-info:position}{td}
{td}{report-info:duration}{td}
{tr}
{report-body}
{report-block}
{table}{cache}
{table-plus}
\\
{column}
{section}
{show-if} -
Inappropriate?Ok, a couple of further questions based on the above:
1. Which is slower - viewing or editing? Particularly given the caching you have enabled I'm guessing it's editing that's slow.
2. How many users do you have in your server?
A couple of small initial suggestions:
1. Remove the 'injected=true' unless you are actually injecting %key% values inside that item. There are several {report-on} blocks in particular which inject but don't actually have anything to inject. This will make some small performance improvements.
2. You might consider rearranging your {replace-and-render} blocks. Instead of having one for each {list-option} set you are creating, you could try putting a single {replace-and-render} around the whole {repeating-data} and move the {replace-item} macros you have into that block, rather than having the 5 or 6 internal ones you currently have. Again, not a big improvement most likely, but it may help.
Honestly, my guess is that a lot of the load time is actually simply due to the fact that you have a lot of HTML being generated. For every row, there will be a fair bit of HTML output, particularly if you have a lot of users. At some point it will simply become a problem of byte transfer speed. -
Inappropriate?Hi, David
Thanks for reply.
1. Both are equally slow - viewing and editing :(
2. Over 200 users
I corrected the code for all your suggestions. But no significant performance improvements.
I guess that the problem with slow loading pages can be linked to upgrade the Reporting plugin
Our version Confluence 2.10.2, Reporting Plugin - 3.2.0
Before update the plugin on the page were 60 entries and was loaded much faster. -
Inappropriate?Well, technically Reporting 3.2.0 only supports Confluence 3.0+, although most stuff will still work in 2.10.x.
The next thing to do would be to try and narrow down what is slowing it down the most. A chief suspect would be the {user-options} macro. If you remove that list box, how does it effect the performance?
EMPLOYEE
