Dear Michael,
the main reason why the PARALLEL option exists in BaseX is that a single query should never block other queries that run in parallel. It’s perfectly fine to have BaseX applied in environments with hundreds of parallel requests. As Marco indicated, parallel access leads to random access patterns on disk, so the major question is how we can get your queries faster.
Feel free to tell us more about your queries or query patterns; we might be able to give you some clues how they can be rewritten to benefit from the database statistics and index structures.
Best regards, Christian
On Mon, Apr 8, 2019 at 4:05 PM Michael Perkonigg michael.perkonigg@humanomed.co.at wrote:
Hallo,
ich versuche gerade, BaseX hier für eine zentrale XML-DB zu evaluieren.
Die DB ist read-only. Wir haben also keinerlei Updates.
Wir haben verschiedene XQuery-Queries(?), die abgesetzt werden, dabei ist aufgefallen, dass wenn ich mehrere Queries parallel starte die Antwortzeiten unverhätnismässig steigen.
Einzeln:
Query1: 500ms
Query2: 1200ms
Parallel brauchen beide zusammen dann zwischen 3 und 5 Sekunden.
Erstaunlicherweise sind die Antwortzeiten mit der Option PARALLEL=1 am geringsten, d.h. bei der Defaulteinstellung PARALLEL=8 (und auch schon bei PARALLEL=2) steigen die Antwortzeiten.
Ich frage mich nun, ob BaseX als Datenbank für eine verteilte Applikation mit zentraler DB überhaupt geeignet ist und ob ich vielleicht mit irgendwelchen Optionen BaseX für meine Zwecke optimieren kann.
Ganz theoretisch könnte die DB ja mit hundert parallelen Anfragen belastet werden.
-- mit freundlichen Grüßen