The Admin UI - Performance section was added to Site Administration page in XNAT 1.8.9 to better support very large instances. To get to these controls, go to Administer > Site Admininistration in the top navigation and click on the Performance tab.
XNAT operates well in most use cases without modifications to this section. This section was added to allow administrators to tweak some functionality for especially large instances ( > 1,000,000 datasets). If you are experiencing performance issues on a server with less then 1 million datasets, fine-tuning the configurations for PostgreSQL and Tomcat are the place to start. See: Postgres Tuning for XNAT Installations
If you have a very large dataset stored in your XNAT, tweaking these settings can improve performance and prevent system issues.
One of the largest performance factors in large listings is the aggregating of values, such as counts of experiment types as a column in a data table. These are often managed via Display Document configurations and should be removed from those <DisplayVersion> tags if performance continues to be an issue after modifying these Search Performance settings.
Search Performance Settings
Search Listings should be sorted by default
Sorting of tables can add several seconds onto larger queries. On small instances, this isn't an issue. But on servers with millions of entries, this can impact performance. This setting determines whether all data listings are sorted by default (on initial access). Set to 'Disabled' on large instances.
Project data listings include summary counts
Aggregate functions are costly on large systems (i.e. millions of rows). Disabling count fields can improve performance. This setting determines whether count fields (like MR Count) should be included in project level listings (like Subjects). If Enabled, counts of child objects will be automatically included in project data listings. If Disabled, counts of child objects will only be available if display documents are manually configured to add them. Note: This doesn't effect site-wide listings, which are managed entirely by display documents.
Site-wide config properties can be accessed via REST at
Site-wide config properties can be access programmatically in Velocity via