Search Performance

There are multiple ways to set up both a datasource and your search that will affect the overall performance of your Logscape installation today we're going to walk you through some. Below is a run through of how you can make your searches more efficient, to configure Logscape to run more efficient searches, check out theTechnology section.


Summary Indexing:

Summary Indexing will store search results for later use, to make use of summary indexing you need to pre-build your search results through uses of a scheduled search. By default Summary Indexed searches make use of a 10 minute bucket size.

Pro: Very Fast, suitable for long, historic searches, low performance penalty
Con: Requires schedules tasks to execute summary.index(write). Uses disk space. Doesnt support faceting, Requires maintenence tasks

To write to the summary index you need to make use of 'summary.index(write)' in your search, we reccomend you set up an alert to fire this search. You can do this by using any schedule you wish, and then configuring your search as the alert trigger.

Once the index has been wrote you can reference the index by using the same search, but changing the summary syntax to 'summary.index(read)'


Indexed Fields

An Indexed Fields search makes use of the ability to evaluate fields at index-time, rather than search time, the main scenarios this improves performance for is groovy-script as well as geo-ip lookups, however any scenario whereby the user is performing significant field manipulation would benefit greatly from having fields evaluated at index.

Pros: Improves performance by 40%+
Cons: Required reindexing if the field script is changed


Keyword Filter

Keyword filtering is simply making use of keywords before the | in your search syntax, this works to improve search performance by pruning the files that need to be search before search execution.

Pro: Improves search performance and reduces search overhead
Con: Requires knowledge of what you are currently searching for



Basic

A basic search is a search that does not make use of any of the above techniques, and generally utilises a * operator.

Pro: Good for adhoc analysis
Con: Performance heavily dependant upon OS and Logscape configuration. Will struggle with large historic searches. May require an overwrite of the default TTL which can be performed by including ttl(X) in your search.