Query Performance Testing

Installation and Configuration

Introduction

With the Query Performance Tester, the search performance and expected search hits can be tested automatically and reproducibly. The most important features are:

• Testing with custom search apps
• Creation of test plans (what is searched for, what are the expected results)
• Parameterization of test runs (user, number of parallel searches, number of iterations)
• Monitoring a test run
• Display detailed statistics of a test run

Configuration

Open the tab “Indices” in the menu “Configuration” of the Mindbreeze Management Center. Add a new Service in the “Services” section by clicking on the “Add Service” button. Select the service type “QueryPerformanceTesterService” from the “Service” list.

“Base Configuration”

Setup

Launching a Test Job

You can find the user interface of the Query Performance Tester Service in the Mindbreeze Management Center in the menu "Reporting", submenu "Query Performance Tests".

If you are using CentOS 6, you can add the URL to “Query Performance Tests” via resources.json. By default, this feature is only visible in CentOS7. The URL looks like this:

:8443/index/<YOUR SERVICE BIND PORT>/admin/index.html

You can find the Service Bind Port in ‘Services’ – Settings in the Configuration.

Here you can find the documentation how to add a menu entry: Managementcenter Menu

Adding a Search App

In the “Search Apps” section click on “Add Search App”

Set the name of the search app. If JavaScript code is available for the given app, which transforms the request before sending it, paste it in the text field or upload it from a file using the “Upload Search App” button. For a simple use case the field can be left empty.

Uploading a Test Plan

In the “Test Plan” of the management interface click on “Add Test Plan”. On the dialog you can specify a name for the test plan to be added and you can add some query terms that should be tested.

If more advanced features are needed, like key and property expectations, the test plan source can be manually edited and refined using the “View Source Code” button.

After the test plan is complete, it should be saved and then will be available for a test job launch.

Starting a Test

After a test plan is created you can start a test job by clicking on the “Start Test” button next to the created test plan in the “Test Plans” list.

For starting a test job, the following parameters are required:

Setting up a „User Group”

Click on “Manage User Groups” in the dialog for test starting and set a name for the user group in the “Add User Group” section.

Add users to the created group and finally click on the “Add User Group” button.

After finished, with “Cancel” you can return to the original dialog:

The created user group should be available for selection in the “User group” dropdown list.

If a user group is selected for a test job run, the requests are sent with HTTP header “X-Username” set to the user names included in the user group. For the Client Service to recognize this header, the Request Header Session Authentication must be configured.

If the count of the users set for the test run exceeds the user group size, the remaining user names are set again with the first users of the user group.

Add Environments

Using the “Manage Environments” dialog you can create and save predefined test environments. Environments can be used to define some base settings. These base settings can be applied when starting a test by selecting the defined “Environment” in the “Start test” dialog (see section “Starting a Test”).

The following parameters are required:

Monitoring a Test Run

Start the test run as described in the previous section. Real time monitoring of the current test is available in “Execution (Jobs)”:

Here a real time graph showing the number of queries executed per second and the average request duration. Different colors of the graph mark different iterations.

Test Reports

After the job finished, it is listed in the Job History. By clicking on “Details” a report of the executed job is shown.

On the first page a general report and, if it is the case, a list of errors that occurred during the test job execution is shown.

The following execution parameters are displayed:

Using the “Request Report” view a detailed report of each executed query is shown. The data shown in the table is the minimum, the average and the maximum value of the request parameter chosen. Using the paging controls, one can navigate through all test iterations and show the data.

The following request parameters can be shown:

Example of a Test Plan Execution (Job)

The following example describes the procedure how a job is executed with the following settings:

Settings

1. Testplan (Query Terms):
   1. Active
   2. testing
   3. python
   4. mindbreeze
   5. “mindbreeze search”
   6. mindbreeze AND search
2. Users: 5
3. Iterations: 3
4. User Group
   1. User 1
   2. User 2
   3. User 3

Execution

Since 5 users are configured, 5 users will search concurrently. Because only 3 different users are configured in the “User Group”, the 5 search users will be:

1. User 1
2. User 2
3. User 3
4. User 1
5. User 2

These users will start searching simultaneously, starting with the first configured query term and continuing with the other search terms (“Active”, “testing”, …, “mindbreeze AND search”). When all users completed the searches, the first iteration is finished.

Because 3 iterations are configured, this process will be repeated two more times.

During this process, the test run can be monitored (see section “Monitoring a Test Run”). When all iterations have been completed, the report can be viewed (see section “Test Reports”).