Re: [basex-talk] concurrent performance issues?
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 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
Re: [basex-talk] concurrent performance issues?
Hi Michael, there has been a lot of discussion related to this issue. The most significant result that has alway clearly emerged and that Christian is always evangelizing us about is that beeing DB -access strictly serial, querying in paralllel is causing only trouble unless the data is actually split onto different disks. accessing in parallel just causes the OS/HW TO jump around on the disk missing al the cache efficiency and optimization. So, unless you have hardware that really supports parallel access, just prefer sequential disk access. Hoffe dies hilft. M. On 08/04/19 16:05, Michael Perkonigg 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
[basex-talk] concurrent performance issues?
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
