Factors affecting query performance
Managed by | Updated .
Background
Performance of the Funnelback search is tied to a number of factors. Some of these factors are external to Funnelback.
Performance testing
Funnelback’s modern UI default forms can be used to display a report on where time is spent when processing a query.
To access this feature run a query using Funnelback’s modern UI. On the search results page select performance from the drop-down menu located at the bottom right hand corner of the search box.
The performance breakdown will be shown in a popup window.
If modern UI has been customised you can view this information by viewing the XML or JSON interface.
To do this edit your URL so that the URL calls search.xml or search.json instead of search.html.
You will then get the response in XML or JSON format. The relevant section appears in the response packet (/com.funnelback.publicui.search.model.transaction.SearchTransaction/response/performanceMetrics XPath). JSON packet follows the same structure.
Remove layers of integration
A common method of deploying Funnelback is to nest Funnelback search pages within a page on a content management system. The CMS is responsible for handling interaction with the user and relays user queries to Funnelback, and passes the responses back to the user nested inside a CMS page.
This adds a considerable amount of time to the query response because CMS overheads are being added on top of what would occur if the user made the query directly to Funnelback.
The CMS overheads include:
- Additional response time of the user contacting the CMS, and receiving the response from the CMS.
- Additional processing time as a result of the CMS page render time and time to translate the user request and Funnelback server response.
Having a user connect directly to Funnelback can result in a significant speed increase.
Server resourcing
Increasing the RAM and CPU allocation to the Funnelback VM can have a great impact on performance. Increasing available RAM allows Funnelback to load indexes into memory which can see significant improvements in query response time.
Multi-server architecture
Funnelback can be scaled to support multiple servers. This is usually done by having a server responsible for administration and crawling, and one or more servers responsible for serving queries to users. Adding additional servers requires additional Funnelback licences.
Configuration optimisation
There are various configuration options that can also improve performance.
Query time optimisations include:
See: Query processing optimisation
Crawl time optimisations include:
- Increasing the aggressiveness of the crawl – this is a combination of increasing the number of concurrent threads running, and reducing request delays. This can improve crawl performance, but places additional load onto your servers. The exact configuration values depend on the type of collection being crawled but each of the repositories that are part of the current enterprise search have settings for controlling this. Note: this can be controlled on a per domain basis by configuring a site_profiles.cfg. See: https://docs.funnelback.com/more/extra/site_profiles.html
- Increasing the amount of memory allocated to the update (eg. increasing the java heap size).
- Excluding unnecessary content from the crawls.
- For web collections investigate the suitability of defining revisit policies. Note: this can be controlled on a per domain basis by configuring a site_profiles.cfg.