Copyright ©
Mindbreeze GmbH, A-4020 Linz, 2024.
Alle Rechte vorbehalten. Alle Hard- und Softwarenamen sind Markennamen und/oder Warenzeichen der jeweiligen Hersteller.
Diese Dokumente sind streng vertraulich. Die Einreichung und Präsentation dieser Dokumente verleiht keine Rechte an unserer Software, unseren Dienstleistungen und Serviceergebnissen oder anderen geschützten Rechten.
Die Verbreitung, Veröffentlichung oder Vervielfältigung ist untersagt.
Zur besseren Lesbarkeit wurde auf eine Geschlechterdifferenzierung verzichtet. Entsprechende Begriffe und Definitionen gelten im Sinne und Zweck des Gleichbehandlungsgrundsatzes für beide Geschlechter.
Mit dem Query Performance Tester können die Suchperformance und erwartete Suchtreffer automatisiert und reproduzierbar getestet werden. Die wichtigsten Features sind:
Öffnen Sie den Tab „Indizes“ im Menü „Konfiguration“ des Mindbreeze Management Centers. Fügen Sie im Abschnitt „Services“ ein neues Service hinzu, indem Sie auf den Button „Add Service“ klicken. Wählen Sie in der Liste "Service" den Service-Typ „QueryPerformanceTesterService“ aus.
Option | Beschreibung |
Service Bind Port | Der Port, auf dem der Dienst auf Anfragen wartet. |
Die Benutzeroberfläche des Query Performance Tester Service finden Sie im Mindbreeze Management Center im Menü „Reporting“, Untermenü „Query Performance Tests“.
Sollten Sie eine G6 Appliance verwenden, können Sie die URL zu „Query Performance Tests“ über das resources.json selbst hinzufügen. Standardmäßig ist dieses Feature nur in CentOS7 im Menü sichtbar. Die URL dazu sieht wie folgt aus:
:8443/index/<YOUR SERVICE BIND PORT>/admin/index.html
Den entsprechenden Service Bind Port finden Sie in den Services-Einstellungen.
Die Dokumentation, wie Sie einen Menüpunkt hinzufügen können, finden Sie hier: Managementcenter Menü
Klicken Sie im Abschnitt „Search Apps“ auf „Add Search App“.
Geben Sie den Namen der Suchanwendung ein. Wenn für die angegebene App ein JavaScript-Code zur Transformation der Anfrage vor dem Absenden verfügbar ist, fügen Sie ihn in das Textfeld ein oder laden Sie ihn über die Schaltfläche „Upload Search App“ aus einer Datei hoch. Für einfache Anwendungsfälle kann das Feld leer gelassen werden.
Klicken Sie in „Test Plan“ auf „Add Test Plan“. Im geöffneten Dialog können Sie einen Namen für den Testplan angeben und einige Suchbegriffe hinzufügen, die getestet werden sollen.
Wenn erweiterte Funktionen wie Key- und Property-Expectations benötigt werden, kann der Testplanquellcode über den Button „View Source Code“ manuell bearbeitet und verfeinert werden.
Nachdem der Testplan abgeschlossen ist und gespeichert wurde, steht er zum Starten eines Testjobs zur Verfügung.
Nachdem ein Testplan erstellt wurde, können Sie einen Testjob starten, indem Sie in der Liste „Test Plans“ auf den Button „Start Tests“ neben dem erstellten Testplan klicken.
Zum Starten eines Prüfauftrags werden die folgenden Parameter benötigt:
Endpoint | Die URL des Mindbreeze Client Service Such-API-Endpunkts. |
Users | Anzahl der parallelen Suchen |
Iterations | Anzahl der Iterationen über den vorgegebenen Testplan hinweg |
User group | Die Liste der mit der Suche verbundenen Benutzer. Falls nicht verfügbar, können diese mit „Manage User Groups“ eingerichtet werden. |
Job name | Der Name des Jobs |
Search App | Ausgewählte Suchanwendung zur Durchführung des Tests |
Description | Ein Text, der den aktuellen Testauftrag beschreibt |
Klicken Sie im „Start test“ Dialog auf „Manage User Groups“ und geben Sie im Abschnitt „Add User Group“ einen Namen für die Benutzergruppe ein.
Fügen Sie Benutzer zur erstellten Gruppe hinzu und klicken Sie schließlich auf die Schaltfläche "Benutzergruppe hinzufügen".
Nach Abschluss können Sie mit "Abbrechen" zum ursprünglichen Dialog zurückkehren:
Die erstellte Benutzergruppe sollte in der Dropdown-Liste "Benutzergruppe" zur Auswahl stehen.
Wenn für einen Testlauf eine Benutzergruppe ausgewählt wird, werden die Aufträge mit dem HTTP-Header "X-Username" gesendet, der auf die in der Benutzergruppe enthaltenen Benutzernamen gesetzt ist. Damit der Client Service diesen Header erkennt, muss die Request Header Session Authentisierung konfiguriert werden.
Wenn die Anzahl der für den Testlauf eingestellten Benutzer die Größe der Benutzergruppe überschreitet, werden die restlichen Benutzernamen mit den ersten Benutzern der Benutzergruppe gesetzt.
Mit dem Dialog "Manage Environments" können Sie vordefinierte Testumgebungen erstellen und speichern. Umgebungen können verwendet werden, um einige Grundeinstellungen zu definieren. Diese Grundeinstellungen können beim Starten eines Tests durch Auswahl des definierten "Environment" im Dialog "Start test" übernommen werden (siehe Abschnitt "Starten eines Tests").
Die folgenden Parameter sind erforderlich:
Environment Name | Name des Environments |
Endpoint | Mindbreeze Client Service Such-API-Endpunkt, z.B. https://myserver.mycompany.com/api/v2/search |
User Count | Anzahl der parallelen Such-Threads. |
Iteration Count | Anzahl der Testiterationen. |
Starten Sie den Testlauf wie im vorherigen Abschnitt beschrieben. Ein Echtzeitüberwachung für den aktuellen Test ist unter " Execution (Jobs)" verfügbar:
Hier wird ein Echtzeitdiagramm der Anzahl der ausgeführten Abfragen pro Sekunde und der durchschnittlichen Abfragedauer angezeigt. Verschiedene Farben des Diagramms markieren unterschiedliche Iterationen.
Nach Beendigung des Auftrags wird er in der Auftragshistorie aufgeführt. Durch Anklicken von "Details" wird ein Bericht über den ausgeführten Job angezeigt.
Auf der ersten Seite wird ein allgemeiner Bericht und möglicherweise eine Liste der Fehler angezeigt, die während der Ausführung des Testauftrags aufgetreten sind.
Die folgenden Parameter werden angezeigt:
Search App | Der Name der Suchanwendung. |
Testplan | Der Name des Testplans. |
Duration | Die Dauer der Ausführung des Testplans (Job) in Sekunden. |
Average Requets Per Second | Die durchschnittliche Anzahl der ausgeführten Requests pro Sekunde während des Jobs. |
Max. Requests Per Second | Die maximale Anzahl der ausgeführten Requests pro Sekunde während des Jobs. |
Min. Requests Per Second | Die minimale Anzahl der ausgeführten Requests pro Sekunde während des Jobs. |
Job Description | Die Beschreibung des Jobs. |
Endpoint | Die URL des Mindbreeze Client Service Such-API-Endpunkts. |
Start Date | Das Datum, an dem der Job gestartet wurde. |
Average Duration of Search Requests | Die durchschnittliche Dauer einer Suchanfrage in Millisekunden während des Jobs. |
Requests Per Second | Die durchschnittlichen Anforderungen pro Sekunde während des Jobs. |
Iteration Count | Die Anzahl der Such-Iterationen. |
Status | Der Status der Aufträge (running, finished, canceled, queuing). |
Usercount | Die Anzahl der gleichzeitig suchenden Benutzer. |
Über die Ansicht " Request Report" wird ein detaillierter Bericht zu jedem ausgeführten Request angezeigt. Die in der Tabelle angegebenen Daten sind der minimale, der durchschnittliche und der maximale Wert des gewählten Request Parameters. Mithilfe der Seitennavigation kann durch alle Testiterationen navigiert werden und die Daten anzeigen werden.
Die folgenden Request Parameter können angezeigt werden:
Duration | Dauer des Requests in Millisekunden |
Count | Anzahl der Suchergebnisse für die angegebene Query |
Estimated Count | Geschätzte Anzahl der Suchergebnisse für die angegebene Query |
Answer Count | Anzahl der NLQA Antworten für die angegebene Query |
Das folgende Beispiel beschreibt die Vorgehensweise bei der Ausführung eines Jobs mit den folgenden Einstellungen:
Da 5 Benutzer konfiguriert sind, werden 5 Benutzer gleichzeitig suchen. Da in der "User Group" nur 3 verschiedene Benutzer konfiguriert sind, werden die 5 Benutzer, welche die Suchen ausführen, folgende sein:
Diese Benutzer starten die Suche gleichzeitig, beginnend mit dem ersten konfigurierten Suchbegriff und weiter mit den anderen Suchbegriffen (“Active”, “testing”, …, “mindbreeze AND search”). Wenn alle Benutzer die Suche abgeschlossen haben, ist die erste Iteration abgeschlossen.
Da 3 Iterationen konfiguriert sind, wird dieser Prozess zwei weitere Male wiederholt.
Während dieses Vorgangs kann der Testlauf überwacht werden (siehe Abschnitt "Überwachen eines Testlaufs"). Wenn alle Iterationen abgeschlossen sind, kann der Bericht eingesehen werden (siehe Abschnitt "Testberichte").