github-mirrors/elasticsearch
1
0
Fork 0
mirror of https://github.com/elastic/elasticsearch.git synced 2025-06-28 17:34:17 -04:00
Code Issues Projects Releases Packages Wiki Activity

[DOCS] Typo in Search speed (#91934)

Browse source 
* [DOCS] Typo in Search speed

The PR https://github.com/elastic/elasticsearch/pull/89782 introduced some broken tags to leak in the text

* Fix tags

* Make all headings discrete

Co-authored-by: Abdon Pijpelink <abdon.pijpelink@elastic.co>
This commit is contained in:
Luca Belluccini 2022-11-28 12:55:47 +00:00 • committed by GitHub
parent 3a223d933a
commit 7c5b6483a1
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

12
docs/reference/how-to/search-speed.asciidoc
View file

@ -10,7 +10,7 @@ goes to the filesystem cache so that Elasticsearch can keep hot regions of the
index in physical memory. index in physical memory.
[discrete] [discrete]
tag::readahead[] // tag::readahead[]
=== Avoid page cache thrashing by using modest readahead values on Linux === Avoid page cache thrashing by using modest readahead values on Linux
Search can cause a lot of randomized read I/O. When the underlying block Search can cause a lot of randomized read I/O. When the underlying block
@ -35,7 +35,7 @@ as a transient setting). We recommend a value of `128KiB` for readahead.
WARNING: `blockdev` expects values in 512 byte sectors whereas `lsblk` reports WARNING: `blockdev` expects values in 512 byte sectors whereas `lsblk` reports
values in `KiB`. As an example, to temporarily set readahead to `128KiB` values in `KiB`. As an example, to temporarily set readahead to `128KiB`
for `/dev/nvme0n1`, specify `blockdev --setra 256 /dev/nvme0n1`. for `/dev/nvme0n1`, specify `blockdev --setra 256 /dev/nvme0n1`.
end::readahead[] // end::readahead[]
[discrete] [discrete]
=== Use faster hardware === Use faster hardware
@ -358,7 +358,7 @@ PUT index
} }
-------------------------------------------------- --------------------------------------------------
tag::warm-fs-cache[] // tag::warm-fs-cache[]
[discrete] [discrete]
=== Warm up the filesystem cache === Warm up the filesystem cache
@ -372,7 +372,7 @@ depending on the file extension using the
WARNING: Loading data into the filesystem cache eagerly on too many indices or WARNING: Loading data into the filesystem cache eagerly on too many indices or
too many files will make search _slower_ if the filesystem cache is not large too many files will make search _slower_ if the filesystem cache is not large
enough to hold all the data. Use with caution. enough to hold all the data. Use with caution.
end::warm-fs-cache[] // end::warm-fs-cache[]
[discrete] [discrete]
=== Use index sorting to speed up conjunctions === Use index sorting to speed up conjunctions
@ -424,6 +424,7 @@ be able to cope with `max_failures` node failures at once at most, then the
right number of replicas for you is right number of replicas for you is
`max(max_failures, ceil(num_nodes / num_primaries) - 1)`. `max(max_failures, ceil(num_nodes / num_primaries) - 1)`.
[discrete]
=== Tune your queries with the Search Profiler === Tune your queries with the Search Profiler
The {ref}/search-profile.html[Profile API] provides detailed information about The {ref}/search-profile.html[Profile API] provides detailed information about
@ -438,6 +439,7 @@ Because the Profile API itself adds significant overhead to the query,
this information is best used to understand the relative cost of the various this information is best used to understand the relative cost of the various
query components. It does not provide a reliable measure of actual processing time. query components. It does not provide a reliable measure of actual processing time.
[discrete]
[[faster-phrase-queries]] [[faster-phrase-queries]]
=== Faster phrase queries with `index_phrases` === Faster phrase queries with `index_phrases`
@ -446,6 +448,7 @@ indexes 2-shingles and is automatically leveraged by query parsers to run phrase
queries that don't have a slop. If your use-case involves running lots of phrase queries that don't have a slop. If your use-case involves running lots of phrase
queries, this can speed up queries significantly. queries, this can speed up queries significantly.
[discrete]
[[faster-prefix-queries]] [[faster-prefix-queries]]
=== Faster prefix queries with `index_prefixes` === Faster prefix queries with `index_prefixes`
@ -454,6 +457,7 @@ indexes prefixes of all terms and is automatically leveraged by query parsers to
run prefix queries. If your use-case involves running lots of prefix queries, run prefix queries. If your use-case involves running lots of prefix queries,
this can speed up queries significantly. this can speed up queries significantly.
[discrete]
[[faster-filtering-with-constant-keyword]] [[faster-filtering-with-constant-keyword]]
=== Use `constant_keyword` to speed up filtering === Use `constant_keyword` to speed up filtering