ExcludeCount and performance


I am doing some load testing on an HPRM dataset containing 16 million records.  Response times from our web clients were not great, depending on which search query I used of course.  I really wanted to improve this.


A ServiceAPI parameter not often mentioned is ExcludeCount (otherwise known as resultsOnly).  This has the effect of committing the SearchTitle and TotalResults properties from the response.  Total results in particular can degrade performance on a large dataset as it calculates the total number of records matched by the query.

ServiceAPI Example


WebDrawer Example

Setting ExcludeCount as the default in WebDrawer will result in the search results page no longer displaying the search title.  To do this add the 'resultsOnly' attribute in the Record route defaults, as seen below.  Ensure you set this on the route named Record with the model named Records.


The outcome

On my large dataset ExcludeCount more than halved the response time on many requests.

The Cost

In WebDrawer the cost is that the page number links no longer work.  This post examines a solution to the broken paging problem.

Optimising the performance of the WebDrawer details page


WebDrawer is designed to show more rather than less of what a user may wish to see.  Being a simple HTML application it does not aim to do anything as sophisticated as on demand loading of data.  The cost of this approach is that a Record details page contains a lot of information and can be quite slow to load.  If your users typically do not need to see all of this information then you can remove it and improve the load time of this page significantly.

Try It Out

This video demonstrates removing the bulk of the properties displayed on a Record details page and improves load of the page from around 4 seconds to just over 1 second.  I hope you enjoy the soothing sounds of children playing in the background on this video.

Make it more maintainable

While the above will improve the performance of the Record details page it will make it more difficult to upgrade WebDrawer.  One way to improve this situation is to not edit the Razor files that ship with WebDrawer but to copy them and use your own.  This way your changes will not be overwritten by an upgrade. In the picture below I have created a folder called 'MyViews' within which I have made a copy of WDRecordDetails.cshtml (renamed MyRecordDetails.cshtml) and a shared folder in which I have a copy of detailsView.cshtml (renamed MyDetailsView.cshtml).  To use the MyRecordDetails View I had to specify it in the 'template' property of the routeDefault element in hptrim.config.


Some important things to remember:

  • the routeDefa
  • .cshtml file names must be unique even across different folders, ServiceAPI/WebDrawer has no way to locate a particular .cshtml file in a specific folder,
  • your 'MyViews' folder (or folders) must be a child of the standard Views folder,
  • the Shared folder is only a convention, shared .cshtml files may be placed in any folder below 'Views',
  • the hptrim.config is overwritten by the WebDrawer upgrade, you must backup and restore it manually to preserve any changes, and
  • as a precaution backup the entire WebDrawer folder prior to any upgrade.


These views and hptrim.config modified in this sample are, these are samples only, they worked on my HPRM 8.11 (Patch 2) instance but I offer no guarantees to anyone else.