Matrix Performance Report - Asset Listing Page

01 Jan 2014

Squiz Matrix's Asset Listing Page is a favourite for many implementers and with dozens of features it is certainly one of the heftiest. But with so much functionality it can be difficult to determine how best to create the set up that you want. Squiz Labs has developed a unique performance testing system to track and investigate the performance of key features within Matrix. With this tool, we are exploring the Asset Listing Page asset like never before, to sort out its weaknesses from its strengths.

The performance tests in this article were performed on version 4.0.3 of Squiz Matrix.

Asset Statuses to List

On an Asset Listing, users can specify the asset statuses to list. If no statuses are selected, all applicable assets will be listed. Certain statuses, however, cannot be listed on the Asset Listing for public users, for example, assets that are Under Construction. Tests were run to determine how these unlisted asset statuses affect the performance of the Asset Listing and how status selection can be optimised to enhance these results.

Tests were run on an Asset Listing with 500 listed assets, 250 of those with a status of Under Construction and 250 with a status of Live. The performance results of a listing with Live status selected was compared to those of a listing with no statuses selected (both returning 250 Live assets only).

The results of these tests indicated that selecting to list only Live assets on the Asset Listing improved performance by 60.77%.

These results are expected as although Under Construction assets are not displayed for public users, they are still processed by the system to check permissions as they will be shown to users who have write access to them.

Subsequent tests indicated that when unlisted assets are not involved, selecting asset statuses does not cause any major impact on the performance of the listing. On a listing with 500 Live assets, selecting the asset statuses did not significantly impact performance. These results remained consistent when testing a listing with a combination of Live and Up For Review assets.

These test results encourage the use of asset status selection on listings that contain unlisted assets, as long as there is no need to show these unlisted assets to editors or administrators.

Asset Types to List

In addition to selecting the listed asset statuses, users can also specify the asset types to list on the Asset Listing. Similarly with the asset status field, if no asset types are selected, all applicable assets will be listed. An inherit option is also available to include all child types of the selected asset type.

To determine the performance effect asset type selection has on a listing, tests were run on an Asset Listing with both single and multiple asset type selection and compared to a listing with no asset types selected. The performance of a listing using the inherit option was also tested and the results compared to a listing not using this option.

The results of these tests indicated that the performance of the Asset Listing remained consistent, regardless of the asset type selections.

There was no significant difference in the performance of the listing when asset types were selected compared to when they were not. The inherit option also has little effect on performance.

These results are expected as the asset type filtering happens inside the main database query for the asset listing and does not require additional processing for each selected asset type.

Root Nodes

The Root Nodes option of an Asset Listing allows users to select which parts of their system the listing should source the assets being listed. Users can specify any number of root nodes and complex Asset Listing implementations may contain large numbers of them. So what effect does multiple root node selection have on performance?

Tests were run on the Asset Listing's Root Nodes option, selecting ten, twenty and thirty root nodes. The results of these tests were then compared to the performance of the Asset Listing when listing just one root node.

Please note that these configurations returned no results to list, so the figures quoted below are focused on the performance of the Root Node option only. Performance will change once the implementation of the Asset Listing has been completed.

The results of these tests are as follows:

Number of Specified Root Nodes Performance Decrease
1 -
10 244.57%
20 502.71%
30 747.85%

As expected, the performance of the Asset Listing decreases as additional root nodes are added. Drops of approximately 250% are seen in each subsequent test, when ten additional root nodes are added.

These results are simply due to the system having to do more work. With each additional root node, the system must call the getChildren query to access the asset's children to check permissions and determine which assets to print on the Asset Listing. Naturally, the more root nodes added, the greater the hit to performance.

These tests suggest that the amount of root nodes selected on an Asset Listing should be kept to as few as possible. Users should consider the implementation structure in order to attempt to use the least number of root nodes on the listing to limit the impact on performance.


Large numbers of listed assets can cause a strain on the performance of an Asset Listing. A common method of combating this issue is through the use of pagination - dividing the listed assets under multiple pages to reduce the loading time of the listing.

A series of tests was run to investigate how pagination affects the performance of an Asset Listing and to determine whether there are an optimal number of assets to list per page. These tests were run on an Asset Listing with 500 assets, with various pagination settings. The results were then compared against the performance of a listing with 20 assets listed per page.

The results of these tests are as follows:

Assets Per Page % of Total Assets Performance Increase Time Improvement per % of Total Assets
500 (no pagination)         100%             -           -        
400           80%           17.88%           0.73%        
300         60%           42.78%           0.74%        
200           40%           82.82%           0.79%         
100           20%           151.17%           0.81%        
80           16%           173.53%           0.74%         
60           12%           199.29%           0.77%         
40           8%           228.51%           0.74%         
20           4%           263.49%           0.76%         

These results confirm that pagination does indeed provide a significant improvement to the performance of listings with large numbers of assets. An increase in performance of 263% can be seen on the listing with 20 assets per page compared to the listing where no pagination was used.

The tests also indicate that pagination provides a consistent time improvement, approximately a 0.7% increase per percentage of total assets. This means that decreasing the number of assets per page will always provide a stable increase in performance; there is no optimal number of assets to list.

When an Asset Listing is loaded, the format of each asset is printed on the listing. This can take a significant amount of time, especially when printing large numbers of assets. Printing fewer assets will naturally increase the performance of the listing, as corroborated in the test results.

Pagination is certainly a viable alternative when dealing with Asset Listings with a substantial number of listed assets. It is recommended to display the fewest possible number of assets per page to provide the best performance on your listing.

Asset Sorting

Asset Listing pages allow users to define the default sort order of the listed assets. There are a number of options available to sort by, including attribute info, creation or publication date, or metadata field values. Tests were run to determine how asset sorting affects the performance of the Asset Listing and how the results differed over the various sorting options available.

An Asset Listing of 500 assets was tested with various sorting options. The results of these tests were compared with one another and with the default performance of a listing without sorting.

The results of these tests are as follows:

Sort-by Performance Decrease
None             -         
Name             5.69%            
Created Date             5.84%            
Asset Type             6.28%            
Keyword: Asset Name             25.83%            
Metadata Field Value             146.96%            

The results of these tests indicate that the standard attribute sorting options cause the least significant impact to the performance of the Asset Listing. The Name, Created Date and Asset Type sort-by options show a decrease in performance of only 5-6%. A larger drop of 25% can be expected when using the asset name keyword replacement to sort the listing, approximately five times that of the standard name sorting option, which would return the same results on the listing.

These results are due to sorting by keyword requiring the entire asset to be loaded before calling the keyword replacement function. Standard asset field sorting simply queries the required tables in the database resulting in only a minor impact on performance.

More significant performance drops of up to 150% can be expected when using a metadata field value to sort the listing. This is due to the system having to individually access the metadata file of each asset on the listing.

While it is tempting to jump straight into using metadata and keyword sorting, these test results suggest that standard attribute sorting should be utilised whenever possible, over these more performance heavy sorting options.

Dynamic Root Nodes

Dynamic parameters on the Asset Listing Page allow you to dynamically source alternate root nodes for the listing based on GET, POST or SESSION variables; the current asset, user or site; and set or global values.

A series of tests was run to inspect the performance of dynamic root node selection in comparison to that of a static root node. These tests included dynamic root nodes sourced from GET parameters, including a structured root node set up, and a nested Asset Listing using the current asset dynamic root node setting.

The results of these tests indicated that there was no significant difference in performance amongst the dynamic parameter settings available. We also found no difference when comparing these results to the performance of a listing using a static root node.

Dynamic root nodes only require minimal additional processing to grab the parameter value (assetid) of the replacement root node and check that it is a child of the listing's static root node, accounting for the low variance in performance.

Asset Grouping

Asset grouping allows you to categorise listed assets on an Asset Listing. While it is expected that grouping assets will decrease the performance of an Asset Listing, tests were run to investigate exactly how performance is affected over the various grouping options available and the number of groups returned.

In these tests, an Asset Listing of 500 assets was grouped under the various grouping options available. The performance of these grouping options when returning both one group and four groups was recorded. The results of these tests were compared with one another and with the default performance of a listing with no grouping.

The results of these tests are as follows:

Grouping Performance Decrease
1 Group Returned 4 Groups Returned
None - -
Standard Asset Field: Asset Status 10.33% 11.68% 
Standard Asset Field: Asset Name 10.33%  11.62% 
Keyword: Asset Status Colour  37.29%      38.70% 
Keyword: Asset Name 36.97%  38.70% 
Asset Metadata 420.09%       444.29%   
Parent Asset 629.14% 645.76%
Parent Asset (Direct Parent Only) 17.84% 22.79%

These results show that there is only a small decrease in performance when grouping by standard asset fields. A drop in performance of 10% and 11% can be seen when listing by 1 and 4 groups, respectively. A further decrease is seen when grouping by keywords, approximately three to four times that of the comparable asset field grouping tests (returning the same listed assets).

A larger performance hit can be expected when grouping by asset metadata or parent asset due to the additional system operations required.

Grouping by asset metadata will require the system to access the metadata file of each individual asset on the listing and can show a drop in performance of over 400%.

Similarly, the parent grouping option can cause a decrease of over 600%, using the getLinkLineages query to determine the parent assets of each asset in the listing. Selecting the Direct Parent Only option when grouping by parent asset can limit the drop in performance to around 20%. This is because the getLinkLineages query is not run; the direct parents of assets are cached in earlier processing.

Grouping assets into four groups did not provide a substantial decrease in performance in comparison to grouping under one group.

This lack of difference can be attributed to the similar number of loaded assets for each test. The slight variance in performance is caused by the system's group calculation process, thus a minor decrease will be seen with each additional group on the listing.

These results advocate the use of standard asset field grouping whenever possible. Users should refrain from using asset metadata and parent asset grouping unless necessary.

Alternate Implementation: the list_current_asset_id Session Variable

As seen in the previous grouping tests, grouping by parent asset can cause a significant hit to performance. An alternative to using the parent asset grouping option is to have an Asset Listing nested within another listing, utilising the list_current_asset_id session variable as a dynamic root node. The assets listed in the nested (or child) listing are grouped under the assets listed in its parent listing. This is effectively the same as using the grouping by parent asset option on a standard listing.

We set out to determine if creating a comparable setup of grouping by  parent asset using the list_current_asset_id session variable would  improve the performance of the Asset Listing.

A nested Asset Listing set up was tested to group 500 assets into four groups. The results of these tests were compared with the results of the grouping by parent asset options from the previous set of grouping tests.

The results of these tests are as follows:

Set up Performance Increase
Grouping by Parent Asset           -         
Grouping by Parent Asset (Direct Parent Only)  507.37%
Nested Asset Listing within listing           495.24%          

These results indicate a major performance improvement when using the list_current_asset_id setup to create a comparable listing when compared to grouping by parent asset. This is due to eliminating the use of the getLinkLineages query call that is required when grouping by parent asset. These results are similar to the grouping by direct parents only option, which also eliminated the getLinkLineages query call.

These results suggest that the direct parents only option should be enabled where possible. If not, users should consider using a nested asset listing setup utilising the list_current_asset_id dynamic root node to group their assets by their parent.

Keyword Replacements

Keyword Replacements are used widely throughout Squiz Matrix for a number of implementation purposes. On an Asset Listing, keyword replacements are predominately used to print information on the listed assets. As a listing can have any number of listed assets, exactly how do keyword replacements affect the performance of a listing? Furthermore, with the asset sorting and asset grouping tests exhibiting a substantial hit to performance when dealing with asset metadata, how do standard attribute keyword replacements compare to those sourced from asset metadata?

A series of tests were carried out on the Type Format Default bodycopy of an Asset Listing with 250 News Items, using both standard attribute and metadata keyword replacements. The results of these tests were then compared against a listing with no keyword replacements and against one another.

The results of these tests are as follows:

Number of Keyword Replacements Printed Performance Decrease
Standard AttributeMetadata
0 - -
2 62.98% 110.18% 
4 95.21%  127.06% 
6 121.56%      145.32% 
8 148.13%  157.59% 
10 176.68%       173.98%   

The results of these tests confirm that metadata keyword replacements do initially cause a more substantial effect on performance when compared to standard attribute keywords. A decrease in performance of 110% can be seen, compared to just 63% for attribute keyword replacements.

What is interesting, however, is that as the number of keywords rises, metadata keyword replacements become increasingly more efficient than their counterpart. In fact, despite a large variance in the performance of the two keyword types initially, the performance of the metadata keywords eventually met and surpassed that of the attribute keywords.

These results are due to the system having to only access the individual metadata file of each asset once when dealing with metadata keyword replacements. While this initially causes a large decrease in performance, each subsequent keyword sees a much less drastic hit to performance. Standard attribute keywords, on the other hand, query each asset on the listing for each keyword replacement printed. This explains the larger and more consistent drops in performance.

It is important to note, however, that not all metadata keyword replacements return performance results on par with those mentioned  above. The individual key and value keyword replacements of a Metadata Select field  (e.g. %asset_metadata_<field>_key%) generate a substantial drop  in performance of over 800% when compared to two standard metadata  keyword replacements. It is recommended that these key and value keyword  formats not be used unless absolutely necessary.

These findings suggest that although asset attribute keyword replacements may initially provide better performance on the Asset Listing, using metadata keywords becomes increasingly beneficial as a greater number of keywords is used. It is recommended to utilise metadata keywords on bodycopies that require large numbers of keyword replacements (10 or more). Furthermore, if a metadata keyword is needed, consider replacing any additional standard attribute keywords with metadata keyword replacements.

Let Us Know What You Think

Let us know if you spot any errors or if you have any ideas on how we can improve the Matrix Community Website.

Contact Squiz for Demo

Let us show you the true power of Squiz Matrix by giving you a personalised demonstration.