Google Git
Sign in
apache / lucenenet-site / 5ff971ba7cc570e29ca8a7f21ffcd5b2651be54b / . / docs / 4.8.0-beta00010 / api / benchmark / Lucene.Net.Benchmarks.ByTask.html
blob: ec21fbca75abae8dfcccaa3249a9f7118ce2999a [file] [log] [blame]
<!DOCTYPE html>
<!--[if IE]><![endif]-->
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<title>Namespace Lucene.Net.Benchmarks.ByTask
| Apache Lucene.NET 4.8.0-beta00010 Documentation </title>
<meta name="viewport" content="width=device-width">
<meta name="title" content="Namespace Lucene.Net.Benchmarks.ByTask
| Apache Lucene.NET 4.8.0-beta00010 Documentation ">
<meta name="generator" content="docfx 2.56.0.0">
<link rel="shortcut icon" href="https://lucenenet.apache.org/docs/4.8.0-beta00009/logo/favicon.ico">
<link rel="stylesheet" href="https://lucenenet.apache.org/docs/4.8.0-beta00009/styles/docfx.vendor.css">
<link rel="stylesheet" href="https://lucenenet.apache.org/docs/4.8.0-beta00009/styles/docfx.css">
<link rel="stylesheet" href="https://lucenenet.apache.org/docs/4.8.0-beta00009/styles/main.css">
<meta property="docfx:navrel" content="toc.html">
<meta property="docfx:tocrel" content="benchmark/toc.html">
<meta property="docfx:rel" content="https://lucenenet.apache.org/docs/4.8.0-beta00009/">
</head>
<body data-spy="scroll" data-target="#affix" data-offset="120">
<div id="wrapper">
<header>
<nav id="autocollapse" class="navbar ng-scope" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target="#navbar">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="/">
<img id="logo" class="svg" src="https://lucenenet.apache.org/docs/4.8.0-beta00009/logo/lucene-net-color.png" alt="">
</a>
</div>
<div class="collapse navbar-collapse" id="navbar">
<form class="navbar-form navbar-right" role="search" id="search">
<div class="form-group">
<input type="text" class="form-control" id="search-query" placeholder="Search" autocomplete="off">
</div>
</form>
</div>
</div>
</nav>
<div class="subnav navbar navbar-default">
<div class="container hide-when-search">
<ul class="level0 breadcrumb">
<li>
<a href="https://lucenenet.apache.org/docs/4.8.0-beta00009/">API</a>
<span id="breadcrumb">
<ul class="breadcrumb">
<li></li>
</ul>
</span>
</li>
</ul>
</div>
</div>
</header>
<div class="container body-content">
<div id="search-results">
<div class="search-list"></div>
<div class="sr-items">
<p><i class="glyphicon glyphicon-refresh index-loading"></i></p>
</div>
<ul id="pagination"></ul>
</div>
</div>
<div role="main" class="container body-content hide-when-search">
<div class="sidenav hide-when-search">
<a class="btn toc-toggle collapse" data-toggle="collapse" href="#sidetoggle" aria-expanded="false" aria-controls="sidetoggle">Show / Hide Table of Contents</a>
<div class="sidetoggle collapse" id="sidetoggle">
<div id="sidetoc"></div>
</div>
</div>
<div class="article row grid-right">
<div class="col-md-10">
<article class="content wrap" id="_content" data-uid="Lucene.Net.Benchmarks.ByTask">
<h1 id="Lucene_Net_Benchmarks_ByTask" data-uid="Lucene.Net.Benchmarks.ByTask" class="text-break">Namespace Lucene.Net.Benchmarks.ByTask
</h1>
<div class="markdown level0 summary"><!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<p>Benchmarking Lucene By Tasks.
<div><p>
<p> This package provides &quot;task based&quot; performance benchmarking of Lucene. One can use the predefined benchmarks, or create new ones. </p>
<p> Contained packages: </p>
<table border="1" cellpadding="4">
<tr>
<td><strong>Package</strong></td>
<td><strong>Description</strong></td>
</tr>
<tr>
<td><a href="stats/package-summary.html">stats</a></td>
<td>Statistics maintained when running benchmark tasks.</td>
</tr>
<tr>
<td><a href="tasks/package-summary.html">tasks</a></td>
<td>Benchmark tasks.</td>
</tr>
<tr>
<td><a href="feeds/package-summary.html">feeds</a></td>
<td>Sources for benchmark inputs: documents and queries.</td>
</tr>
<tr>
<td><a href="utils/package-summary.html">utils</a></td>
<td>Utilities used for the benchmark, and for the reports.</td>
</tr>
<tr>
<td><a href="programmatic/package-summary.html">programmatic</a></td>
<td>Sample performance test written programmatically.</td>
</tr>
</table>
<h2 id="table-of-contents">Table Of Contents</h2>
<ol>
<li><a href="#concept">Benchmarking By Tasks</a> 2. <a href="#usage">How to use</a> 3. <a href="#algorithm">Benchmark &quot;algorithm&quot;</a> 4. <a href="#tasks">Supported tasks/commands</a> 5. <a href="#properties">Benchmark properties</a> 6. <a href="#example">Example input algorithm and the result benchmark report.</a> 7. <a href="#recscounting">Results record counting clarified</a> </li>
</ol>
<h2 id="benchmarking-by-tasks">Benchmarking By Tasks</h2>
<p> Benchmark Lucene using task primitives. </p>
<p> A benchmark is composed of some predefined tasks, allowing for creating an index, adding documents, optimizing, searching, generating reports, and more. A benchmark run takes an &quot;algorithm&quot; file that contains a description of the sequence of tasks making up the run, and some properties defining a few additional characteristics of the benchmark run. </p>
<h2 id="how-to-use">How to use</h2>
<p> Easiest way to run a benchmarks is using the predefined ant task: * ant run-task </p>
<ul>
<li>would run the <code>micro-standard.alg</code> &quot;algorithm&quot;. * ant run-task -Dtask.alg=conf/compound-penalty.alg </li>
<li>would run the <code>compound-penalty.alg</code> &quot;algorithm&quot;. * ant run-task -Dtask.alg=[full-path-to-your-alg-file] </li>
<li>would run <code>your perf test</code> &quot;algorithm&quot;. * java org.apache.lucene.benchmark.byTask.programmatic.Sample </li>
<li><p>would run a performance test programmatically - without using an alg file. This is less readable, and less convenient, but possible. </p>
<p>You may find existing tasks sufficient for defining the benchmark <em>you</em> need, otherwise, you can extend the framework to meet your needs, as explained herein. </p>
<p>Each benchmark run has a DocMaker and a QueryMaker. These two should usually match, so that &quot;meaningful&quot; queries are used for a certain collection. Properties set at the header of the alg file define which &quot;makers&quot; should be used. You can also specify your own makers, extending DocMaker and implementing QueryMaker. </p>
</li>
</ul>
<blockquote><p><strong>Note:</strong> since 2.9, DocMaker is a concrete class which accepts a ContentSource. In most cases, you can use the DocMaker class to create Documents, while providing your own ContentSource implementation. For example, the current Benchmark package includes ContentSource implementations for TREC, Enwiki and Reuters collections, as well as others like LineDocSource which reads a &#39;line&#39; file produced by WriteLineDocTask.</p>
</blockquote>
<p> Benchmark .alg file contains the benchmark &quot;algorithm&quot;. The syntax is described below. Within the algorithm, you can specify groups of commands, assign them names, specify commands that should be repeated, do commands in serial or in parallel, and also control the speed of &quot;firing&quot; the commands. </p>
<p> This allows, for instance, to specify that an index should be opened for update, documents should be added to it one by one but not faster than 20 docs a minute, and, in parallel with this, some N queries should be searched against that index, again, no more than 2 queries a second. You can have the searches all share an index reader, or have them each open its own reader and close it afterwords. </p>
<p> If the commands available for use in the algorithm do not meet your needs, you can add commands by adding a new task under org.apache.lucene.benchmark.byTask.tasks - you should extend the PerfTask abstract class. Make sure that your new task class name is suffixed by Task. Assume you added the class &quot;WonderfulTask&quot; - doing so also enables the command &quot;Wonderful&quot; to be used in the algorithm. </p>
<p> <u>External classes</u>: It is sometimes useful to invoke the benchmark package with your external alg file that configures the use of your own doc/query maker and or html parser. You can work this out without modifying the benchmark package code, by passing your class path with the benchmark.ext.classpath property: * ant run-task -Dtask.alg=[full-path-to-your-alg-file] <font color="#FF0000">-Dbenchmark.ext.classpath=/mydir/classes </font> -Dtask.mem=512M <u>External tasks</u>: When writing your own tasks under a package other than <strong>org.apache.lucene.benchmark.byTask.tasks</strong> specify that package thru the <font color="#FF0000">alt.tasks.packages</font> property. </p>
<h2 id="benchmark-algorithm">Benchmark &quot;algorithm&quot;</h2>
<p> The following is an informal description of the supported syntax. </p>
<ol>
<li><p><strong>Measuring</strong>: When a command is executed, statistics for the elapsed
execution time and memory consumption are collected.
At any time, those statistics can be printed, using one of the
available ReportTasks.</p>
</li>
<li><p><strong>Comments</strong> start with &#39;<font color="#FF0066">#</font>&#39;.</p>
</li>
<li><p><strong>Serial</strong> sequences are enclosed within &#39;<font color="#FF0066">{ }</font>&#39;.</p>
</li>
<li><p><strong>Parallel</strong> sequences are enclosed within
&#39;<font color="#FF0066">[ ]</font>&#39;</p>
</li>
<li><p><strong>Sequence naming:</strong> To name a sequence, put
&#39;<font color="#FF0066">&quot;name&quot;</font>&#39; just after
&#39;<font color="#FF0066">{</font>&#39; or &#39;<font color="#FF0066">[</font>&#39;.</p>
</li>
</ol>
<p>Example - <font color="#FF0066">{ &quot;ManyAdds&quot; AddDoc } : 1000000</font> -
would
name the sequence of 1M add docs &quot;ManyAdds&quot;, and this name would later appear
in statistic reports.
If you don&#39;t specify a name for a sequence, it is given one: you can see it as
the algorithm is printed just before benchmark execution starts.</p>
<ol>
<li><strong>Repeating</strong>:
To repeat sequence tasks N times, add &#39;<font color="#FF0066">: N</font>&#39; just
after the
sequence closing tag - &#39;<font color="#FF0066">}</font>&#39; or
&#39;<font color="#FF0066">]</font>&#39; or &#39;<font color="#FF0066">&gt;</font>&#39;.</li>
</ol>
<p>Example - <font color="#FF0066">[ AddDoc ] : 4</font> - would do 4 addDoc
in parallel, spawning 4 threads at once.</p>
<p>Example - <font color="#FF0066">[ AddDoc AddDoc ] : 4</font> - would do
8 addDoc in parallel, spawning 8 threads at once.</p>
<p>Example - <font color="#FF0066">{ AddDoc } : 30</font> - would do addDoc
30 times in a row.</p>
<p>Example - <font color="#FF0066">{ AddDoc AddDoc } : 30</font> - would do
addDoc 60 times in a row.</p>
<p><strong>Exhaustive repeating</strong>: use <font color="#FF0066">*</font> instead of
a number to repeat exhaustively.
This is sometimes useful, for adding as many files as a doc maker can create,
without iterating over the same file again, especially when the exact
number of documents is not known in advance. For instance, TREC files extracted
from a zip file. Note: when using this, you must also set
<font color="#FF0066">doc.maker.forever</font> to false.</p>
<p>Example - <font color="#FF0066">{ AddDoc } : *</font> - would add docs
until the doc maker is &quot;exhausted&quot;.</p>
<ol>
<li><p><strong>Command parameter</strong>: a command can optionally take a single parameter.
If the certain command does not support a parameter, or if the parameter is of
the wrong type,
reading the algorithm will fail with an exception and the test would not start.
Currently the following tasks take optional parameters:</p>
<ul>
<li><p><strong>AddDoc</strong> takes a numeric parameter, indicating the required size of
added document. Note: if the DocMaker implementation used in the test
does not support makeDoc(size), an exception would be thrown and the test
would fail.</p>
</li>
<li><p><strong>DeleteDoc</strong> takes numeric parameter, indicating the docid to be
deleted. The latter is not very useful for loops, since the docid is
fixed, so for deletion in loops it is better to use the
<code>doc.delete.step</code> property.</p>
</li>
<li><p><strong>SetProp</strong> takes a <code>name,value</code> mandatory param,
&#39;,&#39; used as a separator.</p>
</li>
<li><p><strong>SearchTravRetTask</strong> and <strong>SearchTravTask</strong> take a numeric
parameter, indicating the required traversal size.</p>
</li>
<li><p><strong>SearchTravRetLoadFieldSelectorTask</strong> takes a string
parameter: a comma separated list of Fields to load.</p>
</li>
<li><p><strong>SearchTravRetHighlighterTask</strong> takes a string
parameter: a comma separated list of parameters to define highlighting. See that
tasks javadocs for more information</p>
</li>
</ul>
</li>
</ol>
<p>Example - <font color="#FF0066">AddDoc(2000)</font> - would add a document
of size 2000 (~bytes).</p>
<p>See conf/task-sample.alg for how this can be used, for instance, to check
which is faster, adding
many smaller documents, or few larger documents.
Next candidates for supporting a parameter may be the Search tasks,
for controlling the query size.</p>
<ol>
<li><strong>Statistic recording elimination</strong>: - a sequence can also end with
&#39;<font color="#FF0066">&gt;</font>&#39;,
in which case child tasks would not store their statistics.
This can be useful to avoid exploding stats data, for adding say 1M docs.</li>
</ol>
<p>Example - <font color="#FF0066">{ &quot;ManyAdds&quot; AddDoc &gt; : 1000000</font> -
would add million docs, measure that total, but not save stats for each addDoc.</p>
<p>Notice that the granularity of System.currentTimeMillis() (which is used
here) is system dependant,
and in some systems an operation that takes 5 ms to complete may show 0 ms
latency time in performance measurements.
Therefore it is sometimes more accurate to look at the elapsed time of a larger
sequence, as demonstrated here.</p>
<ol>
<li><strong>Rate</strong>:
To set a rate (ops/sec or ops/min) for a sequence, add
&#39;<font color="#FF0066">: N : R</font>&#39; just after sequence closing tag.
This would specify repetition of N with rate of R operations/sec.
Use &#39;<font color="#FF0066">R/sec</font>&#39; or
&#39;<font color="#FF0066">R/min</font>&#39;
to explicitly specify that the rate is per second or per minute.
The default is per second,</li>
</ol>
<p>Example - <font color="#FF0066">[ AddDoc ] : 400 : 3</font> - would do 400
addDoc in parallel, starting up to 3 threads per second.</p>
<p>Example - <font color="#FF0066">{ AddDoc } : 100 : 200/min</font> - would
do 100 addDoc serially,
waiting before starting next add, if otherwise rate would exceed 200 adds/min.</p>
<ol>
<li><strong>Disable Counting</strong>: Each task executed contributes to the records count.
This count is reflected in reports under recs/s and under recsPerRun.
Most tasks count 1, some count 0, and some count more.
(See <a href="#recscounting">Results record counting clarified</a> for more details.)
It is possible to disable counting for a task by preceding it with <font color="#FF0066">-</font>.</li>
</ol>
<p>Example - <font color="#FF0066"> -CreateIndex </font> - would count 0 while
the default behavior for CreateIndex is to count 1.</p>
<ol>
<li><strong>Command names</strong>: Each class &quot;AnyNameTask&quot; in the
package org.apache.lucene.benchmark.byTask.tasks,
that extends PerfTask, is supported as command &quot;AnyName&quot; that can be
used in the benchmark &quot;algorithm&quot; description.
This allows to add new commands by just adding such classes.</li>
</ol>
<h2 id="supported-taskscommands">Supported tasks/commands</h2>
<p> Existing tasks can be divided into a few groups: regular index/search work tasks, report tasks, and control tasks. </p>
<ol>
<li><p><strong>Report tasks</strong>: There are a few Report commands for generating reports.
Only task runs that were completed are reported.
(The &#39;Report tasks&#39; themselves are not measured and not reported.)</p>
<ul>
<li><p><font color="#FF0066">RepAll</font> - all (completed) task runs.</p>
</li>
<li><p><font color="#FF0066">RepSumByName</font> - all statistics,
aggregated by name. So, if AddDoc was executed 2000 times,
only 1 report line would be created for it, aggregating all those
2000 statistic records.</p>
</li>
<li><p><font color="#FF0066">RepSelectByPref prefixWord</font> - all
records for tasks whose name start with
<font color="#FF0066">prefixWord</font>.</p>
</li>
<li><p><font color="#FF0066">RepSumByPref prefixWord</font> - all
records for tasks whose name start with
<font color="#FF0066">prefixWord</font>,
aggregated by their full task name.</p>
</li>
<li><p><font color="#FF0066">RepSumByNameRound</font> - all statistics,
aggregated by name and by <font color="#FF0066">Round</font>.
So, if AddDoc was executed 2000 times in each of 3
<font color="#FF0066">rounds</font>, 3 report lines would be
created for it,
aggregating all those 2000 statistic records in each round.
See more about rounds in the <font color="#FF0066">NewRound</font>
command description below.</p>
</li>
<li><p><font color="#FF0066">RepSumByPrefRound prefixWord</font> -
similar to <font color="#FF0066">RepSumByNameRound</font>,
just that only tasks whose name starts with
<font color="#FF0066">prefixWord</font> are included.</p>
</li>
</ul>
<p>If needed, additional reports can be added by extending the abstract class
ReportTask, and by
manipulating the statistics data in Points and TaskStats.</p>
</li>
<li><p><strong>Control tasks</strong>: Few of the tasks control the benchmark algorithm
all over:</p>
<ul>
<li><p><font color="#FF0066">ClearStats</font> - clears the entire statistics.
Further reports would only include task runs that would start after this
call.</p>
</li>
<li><p><font color="#FF0066">NewRound</font> - virtually start a new round of
performance test.
Although this command can be placed anywhere, it mostly makes sense at
the end of an outermost sequence.</p>
</li>
</ul>
</li>
</ol>
<p>This increments a global &quot;round counter&quot;. All task runs that
would start now would
record the new, updated round counter as their round number.
This would appear in reports.
In particular, see <font color="#FF0066">RepSumByNameRound</font> above.</p>
<p>An additional effect of NewRound, is that numeric and boolean
properties defined (at the head
of the .alg file) as a sequence of values, e.g. <font color="#FF0066">
merge.factor=mrg:10<span class="emoji" shortcode="100">💯</span>10:100</font> would
increment (cyclic) to the next value.
Note: this would also be reflected in the reports, in this case under a
column that would be named &quot;mrg&quot;.</p>
<pre><code>* &lt;font color=&quot;#FF0066&quot;&gt;ResetInputs&lt;/font&gt; - DocMaker and the
various QueryMakers
would reset their counters to start.
The way these Maker interfaces work, each call for makeDocument()
or makeQuery() creates the next document or query
that it &quot;knows&quot; to create.
If that pool is &quot;exhausted&quot;, the &quot;maker&quot; start over again.
The ResetInputs command
therefore allows to make the rounds comparable.
It is therefore useful to invoke ResetInputs together with NewRound.
* &lt;font color=&quot;#FF0066&quot;&gt;ResetSystemErase&lt;/font&gt; - reset all index
and input data and call gc.
Does NOT reset statistics. This contains ResetInputs.
All writers/readers are nullified, deleted, closed.
Index is erased.
Directory is erased.
You would have to call CreateIndex once this was called...
* &lt;font color=&quot;#FF0066&quot;&gt;ResetSystemSoft&lt;/font&gt; - reset all
index and input data and call gc.
Does NOT reset statistics. This contains ResetInputs.
All writers/readers are nullified, closed.
Index is NOT erased.
Directory is NOT erased.
This is useful for testing performance on an existing index,
for instance if the construction of a large index
took a very long time and now you would to test
its search or update performance.
</code></pre><ol>
<li><p>Other existing tasks are quite straightforward and would
just be briefly described here.</p>
<ul>
<li><p><font color="#FF0066">CreateIndex</font> and
<font color="#FF0066">OpenIndex</font> both leave the
index open for later update operations.
<font color="#FF0066">CloseIndex</font> would close it.</p>
</li>
<li><p><font color="#FF0066">OpenReader</font>, similarly, would
leave an index reader open for later search operations.
But this have further semantics.
If a Read operation is performed, and an open reader exists,
it would be used.
Otherwise, the read operation would open its own reader
and close it when the read operation is done.
This allows testing various scenarios - sharing a reader,
searching with &quot;cold&quot; reader, with &quot;warmed&quot; reader, etc.
The read operations affected by this are:
<font color="#FF0066">Warm</font>,
<font color="#FF0066">Search</font>,
<font color="#FF0066">SearchTrav</font> (search and traverse),
and <font color="#FF0066">SearchTravRet</font> (search
and traverse and retrieve).
Notice that each of the 3 search task types maintains
its own queryMaker instance.</p>
</li>
<li><p><font color="#FF0066">CommitIndex</font> and
<font color="#FF0066">ForceMerge</font> can be used to commit
changes to the index then merge the index segments. The integer
parameter specifies how many segments to merge down to (default
1).</p>
</li>
<li><p><font color="#FF0066">WriteLineDoc</font> prepares a &#39;line&#39;
file where each line holds a document with <em>title</em>,
<em>date</em> and <em>body</em> elements, separated by [TAB].
A line file is useful if one wants to measure pure indexing
performance, without the overhead of parsing the data. </p>
<p>You can use LineDocSource as a ContentSource over a &#39;line&#39;
file.</p>
</li>
<li><p><font color="#FF0066">ConsumeContentSource</font> consumes
a ContentSource. Useful for e.g. testing a ContentSource
performance, without the overhead of preparing a Document
out of it.</p>
</li>
</ul>
</li>
</ol>
<h2 id="benchmark-properties">Benchmark properties</h2>
<p> Properties are read from the header of the .alg file, and define several parameters of the performance test. As mentioned above for the <font color="#FF0066">NewRound</font> task, numeric and boolean properties that are defined as a sequence of values, e.g. <font color="#FF0066">merge.factor=mrg:10<span class="emoji" shortcode="100">💯</span>10:100</font> would increment (cyclic) to the next value, when NewRound is called, and would also appear as a named column in the reports (column name would be &quot;mrg&quot; in this example). </p>
<p> Some of the currently defined properties are: </p>
<ol>
<li><p><font color="#FF0066">analyzer</font> - full
class name for the analyzer to use.
Same analyzer would be used in the entire test.</p>
</li>
<li><p><font color="#FF0066">directory</font> - valid values are
This tells which directory to use for the performance test.</p>
</li>
<li><p><strong>Index work parameters</strong>:
Multi int/boolean values would be iterated with calls to NewRound.
There would be also added as columns in the reports, first string in the
sequence is the column name.
(Make sure it is no shorter than any value in the sequence).</p>
<ul>
<li><font color="#FF0066">max.buffered</font></li>
</ul>
</li>
</ol>
<p>Example: max.buffered=buf:10:10<span class="emoji" shortcode="100">💯</span>100 -
this would define using maxBufferedDocs of 10 in iterations 0 and 1,
and 100 in iterations 2 and 3.</p>
<pre><code>* &lt;font color=&quot;#FF0066&quot;&gt;merge.factor&lt;/font&gt; - which
merge factor to use.
* &lt;font color=&quot;#FF0066&quot;&gt;compound&lt;/font&gt; - whether the index is
using the compound format or not. Valid values are &quot;true&quot; and &quot;false&quot;.
</code></pre><p> Here is a list of currently defined properties: </p>
<ol>
<li><p><strong>Root directory for data and indexes:</strong></p>
<ul>
<li>work.dir (default is System property &quot;benchmark.work.dir&quot; or &quot;work&quot;.)</li>
</ul>
</li>
<li><p><strong>Docs and queries creation:</strong></p>
<ul>
<li><p>analyzer</p>
</li>
<li><p>doc.maker</p>
</li>
<li><p>doc.maker.forever</p>
</li>
<li><p>html.parser</p>
</li>
<li><p>doc.stored</p>
</li>
<li><p>doc.tokenized</p>
</li>
<li><p>doc.term.vector</p>
</li>
<li><p>doc.term.vector.positions</p>
</li>
<li><p>doc.term.vector.offsets</p>
</li>
<li><p>doc.store.body.bytes</p>
</li>
<li><p>docs.dir</p>
</li>
<li><p>query.maker</p>
</li>
<li><p>file.query.maker.file</p>
</li>
<li><p>file.query.maker.default.field</p>
</li>
<li><p>search.num.hits</p>
</li>
</ul>
</li>
<li><p><strong>Logging</strong>:</p>
<ul>
<li><p>log.step</p>
</li>
<li><p>log.step.[class name]Task ie log.step.DeleteDoc (e.g. log.step.Wonderful for the WonderfulTask example above).</p>
</li>
<li><p>log.queries</p>
</li>
<li><p>task.max.depth.log</p>
</li>
</ul>
</li>
<li><p><strong>Index writing</strong>:</p>
<ul>
<li><p>compound</p>
</li>
<li><p>merge.factor</p>
</li>
<li><p>max.buffered</p>
</li>
<li><p>directory</p>
</li>
<li><p>ram.flush.mb</p>
</li>
</ul>
</li>
<li><p><strong>Doc deletion</strong>:</p>
<ul>
<li>doc.delete.step</li>
</ul>
</li>
<li><p><strong>Spatial</strong>: Numerous; see spatial.alg</p>
</li>
<li><p><strong>Task alternative packages</strong>:</p>
<ul>
<li>alt.tasks.packages<ul>
<li>comma separated list of additional packages where tasks classes will be looked for
when not found in the default package (that of PerfTask). If the same task class
appears in more than one package, the package indicated first in this list will be used.</li>
</ul>
</li>
</ul>
<p>For sample use of these properties see the *.alg files under conf. </p>
</li>
</ol>
<h2 id="example-input-algorithm-and-the-result-benchmark-report">Example input algorithm and the result benchmark report</h2>
<p> The following example is in conf/sample.alg: <font color="#003333"># -------------------------------------------------------- # # Sample: what is the effect of doc size on indexing time? # # There are two parts in this test: # - PopulateShort adds 2N documents of length L # - PopulateLong adds N documents of length 2L # Which one would be faster? # The comparison is done twice. # # -------------------------------------------------------- </font> <font color="#990066"># ------------------------------------------------------------------------------------- # multi val params are iterated by NewRound&#39;s, added to reports, start with column name. merge.factor=mrg:10:20 max.buffered=buf<span class="emoji" shortcode="100">💯</span>1000 compound=true analyzer=org.apache.lucene.analysis.standard.StandardAnalyzer directory=FSDirectory doc.stored=true doc.tokenized=true doc.term.vector=false doc.add.log.step=500 docs.dir=reuters-out doc.maker=org.apache.lucene.benchmark.byTask.feeds.SimpleDocMaker query.maker=org.apache.lucene.benchmark.byTask.feeds.SimpleQueryMaker # task at this depth or less would print when they start task.max.depth.log=2 log.queries=false # -------------------------------------------------------------------------------------</font> <font color="#3300FF">{ { &quot;PopulateShort&quot; CreateIndex { AddDoc(4000) &gt; : 20000 Optimize CloseIndex &gt; ResetSystemErase { &quot;PopulateLong&quot; CreateIndex { AddDoc(8000) &gt; : 10000 Optimize CloseIndex &gt; ResetSystemErase NewRound } : 2 RepSumByName RepSelectByPref Populate </font> </p>
<p> The command line for running this sample:<br><code>ant run-task -Dtask.alg=conf/sample.alg</code> </p>
<p> The output report from running this test contains the following: Operation round mrg buf runCnt recsPerRun rec/s elapsedSec avgUsedMem avgTotalMem PopulateShort 0 10 100 1 20003 119.6 167.26 12,959,120 14,241,792 PopulateLong - - 0 10 100 - - 1 - - 10003 - - - 74.3 - - 134.57 - 17,085,208 - 20,635,648 PopulateShort 1 20 1000 1 20003 143.5 139.39 63,982,040 94,756,864 PopulateLong - - 1 20 1000 - - 1 - - 10003 - - - 77.0 - - 129.92 - 87,309,608 - 100,831,232 </p>
<h2 id="results-record-counting-clarified">Results record counting clarified</h2>
<p> Two columns in the results table indicate records counts: records-per-run and records-per-second. What does it mean? </p>
<p> Almost every task gets 1 in this count just for being executed. Task sequences aggregate the counts of their child tasks, plus their own count of 1. So, a task sequence containing 5 other task sequences, each running a single other task 10 times, would have a count of 1 + 5 * (1 + 10) = 56. </p>
<p> The traverse and retrieve tasks &quot;count&quot; more: a traverse task would add 1 for each traversed result (hit), and a retrieve task would additionally add 1 for each retrieved doc. So, regular Search would count 1, SearchTrav that traverses 10 hits would count 11, and a SearchTravRet task that retrieves (and traverses) 10, would count 21. </p>
<p> Confusing? this might help: always examine the <code>elapsedSec</code> column, and always compare &quot;apples to apples&quot;, .i.e. it is interesting to check how the <code>rec/s</code> changed for the same task (or sequence) between two different runs, but it is not very useful to know how the <code>rec/s</code> differs between <code>Search</code> and <code>SearchTrav</code> tasks. For the latter, <code>elapsedSec</code> would bring more insight. </p>
<p></div>
<div> </div></p>
</div>
<div class="markdown level0 conceptual"></div>
<div class="markdown level0 remarks"></div>
<h3 id="classes">Classes
</h3>
<h4><a class="xref" href="Lucene.Net.Benchmarks.ByTask.Benchmark.html">Benchmark</a></h4>
<section><p>Run the benchmark algorithm.</p>
</section>
<h4><a class="xref" href="Lucene.Net.Benchmarks.ByTask.PerfRunData.html">PerfRunData</a></h4>
<section><p>Data maintained by a performance test run.</p>
</section>
</article>
</div>
<div class="hidden-sm col-md-2" role="complementary">
<div class="sideaffix">
<div class="contribution">
<ul class="nav">
<li>
<a href="https://github.com/apache/lucenenet/blob/docs/4.8.0-beta00010/src/Lucene.Net.Benchmark/ByTask/package.md/#L2" class="contribution-link">Improve this Doc</a>
</li>
</ul>
</div>
<nav class="bs-docs-sidebar hidden-print hidden-xs hidden-sm affix" id="affix">
<!-- <p><a class="back-to-top" href="#top">Back to top</a><p> -->
</nav>
</div>
</div>
</div>
</div>
<footer>
<div class="grad-bottom"></div>
<div class="footer">
<div class="container">
<span class="pull-right">
<a href="#top">Back to top</a>
</span>
Copyright © 2020 Licensed to the Apache Software Foundation (ASF)
</div>
</div>
</footer>
</div>
<script type="text/javascript" src="https://lucenenet.apache.org/docs/4.8.0-beta00009/styles/docfx.vendor.js"></script>
<script type="text/javascript" src="https://lucenenet.apache.org/docs/4.8.0-beta00009/styles/docfx.js"></script>
<script type="text/javascript" src="https://lucenenet.apache.org/docs/4.8.0-beta00009/styles/main.js"></script>
</body>
</html>