OpenSearch

History

Jay Modi 7520a107be Optionally require a valid content type for all rest requests with content (#22691 ) This change adds a strict mode for xcontent parsing on the rest layer. The strict mode will be off by default for 5.x and in a separate commit will be enabled by default for 6.0. The strict mode, which can be enabled by setting `http.content_type.required: true` in 5.x, will require that all incoming rest requests have a valid and supported content type header before the request is dispatched. In the non-strict mode, the Content-Type header will be inspected and if it is not present or not valid, we will continue with auto detection of content like we have done previously. The content type header is parsed to the matching XContentType value with the only exception being for plain text requests. This value is then passed on with the content bytes so that we can reduce the number of places where we need to auto-detect the content type. As part of this, many transport requests and builders were updated to provide methods that accepted the XContentType along with the bytes and the methods that would rely on auto-detection have been deprecated. In the non-strict mode, deprecation warnings are issued whenever a request with body doesn't provide the Content-Type header. See #19388		2017-02-02 14:07:13 -05:00
..
src/main	Optionally require a valid content type for all rest requests with content (#22691 )	2017-02-02 14:07:13 -05:00
README.md	Add client-benchmark-noop-api-plugin to stress clients even more in benchmarks (#20103 )	2016-08-26 09:05:47 +02:00
build.gradle	Remove `modules/transport_netty_3` in favor of `netty_4` (#21590 )	2016-11-17 12:44:42 +01:00

README.md

Steps to execute the benchmark

Build client-benchmark-noop-api-plugin with gradle :client:client-benchmark-noop-api-plugin:assemble
Install it on the target host with bin/elasticsearch-plugin install file:///full/path/to/client-benchmark-noop-api-plugin.zip
Start Elasticsearch on the target host (ideally not on the same machine)
Build an uberjar with gradle :client:benchmark:shadowJar and execute it.

Repeat all steps above for the other benchmark candidate.

Example benchmark

In general, you should define a few GC-related settings -Xms8192M -Xmx8192M -XX:+UseConcMarkSweepGC -verbose:gc -XX:+PrintGCDetails and keep an eye on GC activity. You can also define -XX:+PrintCompilation to see JIT activity.

Bulk indexing

Download benchmark data from http://benchmarks.elastic.co/corpora/geonames/documents.json.bz2 and decompress them.

Example command line parameters:

rest bulk 192.168.2.2 ./documents.json geonames type 8647880 5000

The parameters are in order:

Client type: Use either "rest" or "transport"
Benchmark type: Use either "bulk" or "search"
Benchmark target host IP (the host where Elasticsearch is running)
full path to the file that should be bulk indexed
name of the index
name of the (sole) type in the index
number of documents in the file
bulk size

Bulk indexing

Example command line parameters:

rest search 192.168.2.2 geonames "{ \"query\": { \"match_phrase\": { \"name\": \"Sankt Georgen\" } } }\"" 500,1000,1100,1200

The parameters are in order:

Client type: Use either "rest" or "transport"
Benchmark type: Use either "bulk" or "search"
Benchmark target host IP (the host where Elasticsearch is running)
name of the index
a search request body (remember to escape double quotes). The TransportClientBenchmark uses QueryBuilders.wrapperQuery() internally which automatically adds a root key query, so it must not be present in the command line parameter.
A comma-separated list of target throughput rates