Search Service Multithreading and Simplification

Author: Eric Houghland

Updated: November 2024

Search Service Multithreading and Simplification

Enhancements Search Service 6.4.2

This release's enhancements to the Search Service significantly improve search performance and user experience. Through query optimization and multithreading, we have achieved faster search results, reduced resource consumption, and a more responsive system.

Key Improvements:

• Multithreading: Implemented multithreading for Search Service/OpenSearch queries, significantly improving query performance and overall search speed.
• Simplified Search: Optimized search queries to reduce unnecessary data retrieval and minimize memory and request sizes between Jama Connect and Search Services.
• Performance Optimization: These enhancements have resulted in faster search results, decreased resource consumption, and a more responsive user experience.

Benefits:

• Faster Search Results: Users will experience significantly quicker search response times.
• Reduced Resource Consumption: Optimized queries and multithreading have reduced the memory footprint and network traffic, improving system performance.
• Improved User Experience: The streamlined search process and faster results create a more efficient and satisfying user experience.

Technical Details:

• Multithreading Implementation: We are improving embedded smart filters. Previously, this was done sequentially, one search page at a time. With multithreading, search pages are processed in parallel. An individual thread handles each page. Threads are taken from a pool with a default value of 5. The recommended pool size is 2

• Query Simplification: The strategy creates a new path using only IDs and types. This new method will retrieve only IDs from the hits instead of all the hit data, which are documents returned by ElasticSearch. The simplification takes place between the Search Service and Jama Connect.
• Performance Metrics: When embedded filters are queried, smartFilterSvc.facetedSearch.dwr will take less time. 

Understanding Smart Filter Data Results

• When working with embedded smart filters, the data results are typically divided into pages. Each page represents a separate call to the search service. This approach helps manage large datasets and improve performance.

Optimizing Page Size

• The optimal page size for your application depends on several factors, including the size of your data, the complexity of your filters, and the capabilities of your search service. If pages are too small, filters may take a long time to load. Conversely, Elasticsearch might time out with error messages if pages are too large.
• To configure the page size, adjust the jama.system.subquery.pagesize property. Please review the Subquery Page Size Timeout and Page Sizes documentation for guidance on setting this value. 

Managing Thread Pool Size

• The jama.system.subquery.threadPoolSize property controls the size of the thread pool used to fetch data pages. A larger thread pool allows for more concurrent page requests, potentially improving performance. However, excessive threads can consume system resources and may not always yield significant benefits.
  • For example, with a thread pool size of 10 and 10 pages to retrieve, each page can be fetched in a separate thread. If the thread pool size is reduced to 5, only five pages can be fetched simultaneously, while the remaining five pages must wait for the first 5 to finish.

Using the Root Admin menu:

1. Login as admin user
2. go to the “System Properties” tab
3. go to the “General Properties” tab
4. ProcClick on the “Edit” button
5. Change the properties value
6. Click on the “save” button

Method 2

Update the property through the API. The tenant API allows you to create new system properties by sending a POST request to the specified endpoint:

$ curl --location --request POST <BASE URL>rest/tenant/<TEANANT ID>/systemproperty' --header 'Content-Type: application/json' <AUTHORIZATION> --data-raw '{"propertyName": "jama.system.subquery.threadPoolSize", "propertyValue": "<SIZE>"}'
The Property name must be exactly: jama.system.subquery.threadPoolSize. Hitting this endpoint will evict whatever old page size is cached automatically; no other changes must be made.

Method 3

Update the DB and Manually Clear the Cache (Used for On-prem)
Query the database to Update or Insert the Property Entry:
First, check if the property exists already:
Select * from propertyentry where propertyName = "jama.system.subquery.threadPoolSize"
If it already exists, then we update:

update propertyentry set propertyValue = 10 where propertyName = "jama.system.subquery.threadPoolSize";
If not, then we insert:

Insert into propertyentry (createdBy, createdDate, modifiedBy, modifiedDate, refId, scope, propertyName, propertyType, propertyValue) Values (<created user id>, '<created date>,' <modified user id>, '<modified date>,' 0, 1, 'jama.system.subquery.threadPoolSize', 2, '<new thread pool size>');
After changing the page size in the database, log in to the root admin menu, access the 'Cache Statistics' tab, and clear the cache for system properties.

Subquiery thread pool 

Documentation

• Jama Support Docs - Search Service Multithreading and Simplification
  • The above link is hosted in Jamaland