EDB Performance

[Richard Mordinyi]

Hi,

we are using the latest OESB version and it seems to me that the EDB has
real performance issues. I dont know about previous version, because we
havent tested the edb there extensively.
The scenario consists of two different tool domains whereas changes on
the one domain X need to be propagated to the other, Y - it seems that
loss of performance occurs whenever data is updated and/or deleted in
the edb.

We believe the reason for this is that for every data of TD X that is
updated, an edb-query has to be performed to find the corresponding data
in other domains. this is needed for model X -> model Y transformation.

Using about 330data records
Commit 1: 36 sec (inserts into TD X)
X->Y transformation: 117 sec (due to above mentioned edb queries)
Commit 2: 113 sec (inserts TD Y)

unfortunately each edb query is slow (~ 400ms), so the total time is
nrOfUpdatedOrDeletedData*330 + (some other stuff that takes some time
but we didn't benchmark yet).

WDYT?
we would like to write some itests to demonstrate the problem, but it
does not seem to work => [1]

thx+br
Richard

[1] https://groups.google.com/d/msg/openengsb-user/dap0CxN5EyQ/ljqw9OLzMrYJ

[Felix Mayerhuber]

Hi,

if I understood you correctly the insertion of 330 models took 36
seconds? Thats very strange right away. In my performance benchmarks for
the bachelor thesis the insertion of 1000 models took less than 2
seconds. But this measurements where done before the engineering object
enhancer was added. The engineering object enhancer needs to perform a
query to ensure that there is no update to other models needed. But a
query from the EDB should also take about 0,01 seconds according to my
measurements.

Additionally I can not explain the 117 seconds the transformations last.
On my benchmarks (done one week ago) the transformation of 1000 models
took the framework about 5 seconds maximum.

And why the second commit takes that much time is also very mysterious.
I think I will need to have a look at your test setup on Wednesday.

Are you using the model update propagation through the engineering
objects? I could implement a way to deactivate this feature so that we
can test if this is really the cause for the troubles.

Kind regards,
Felix

[Michael Petritsch]

Hi,

see inline response.

On Tue, Feb 26, 2013 at 1:33 AM, Felix Mayerhuber <felix.ma...@gmail.com> wrote:

Hi,

if I understood you correctly the insertion of 330 models took 36 seconds? Thats very strange right away. In my performance benchmarks for the bachelor thesis the insertion of 1000 models took less than 2 seconds. But this measurements where done before the engineering object enhancer was added. The engineering object enhancer needs to perform a query to ensure that there is no update to other models needed. But a query from the EDB should also take about 0,01 seconds according to my measurements.

It's the updates and deletes that cause a noticeable performance hit. So in this case 330 models were updated in the EDB. 'inserts' is taken out of context and actually means 'inserts of updated models' since that's what we are doing from our point of view.

Additionally I can not explain the 117 seconds the transformations last. On my benchmarks (done one week ago) the transformation of 1000 models took the framework about 5 seconds maximum.

It's not just simple transformations with the TransformationEngine from Domain x to y. The TransformationEngine transformation is fast yes, however we also have to track duplicated/multiplied models and therefore we have to perform an additional edb-query for each transformed model (to retrieve all duplicates/copies). And the performance of the edb-queries are the problem here (~ 400 ms for each query).
 

And why the second commit takes that much time is also very mysterious. I think I will need to have a look at your test setup on Wednesday.
 

Are you using the model update propagation through the engineering objects? I could implement a way to deactivate this feature so that we can test if this is really the cause for the troubles.

I don't know what you mean with this feature or when you've implemented it. Couldn't find anything about that in the gitlog. We're just inserting EKBCommits (that contain Lists for inserted, updated and deleted models) into the org.openengsb.core.ekb.api.PersistInterface's commit method.

And for the queries we are using the org.openengsb.core.ekb.api.QueryInterface.

Yes, would be great if you have a look at the setup on Wednesday.

thanks and br
 

Kind regards,
Felix

Am 2013-02-25 22:04, schrieb Richard Mordinyi:

Hi,

we are using the latest OESB version and it seems to me that the EDB has real performance issues. I dont know about previous version, because we havent tested the edb there extensively.
The scenario consists of two different tool domains whereas changes on the one domain X need to be propagated to the other, Y - it seems that loss  of performance occurs whenever data is updated and/or deleted in the edb.

We believe the reason for this is that for every data of TD X that is updated, an edb-query has to be performed to find the corresponding data in other domains.  this is needed for model X -> model Y transformation.

Using about 330data records
Commit 1: 36 sec (inserts into TD X)
X->Y transformation: 117 sec (due to above mentioned edb queries)
Commit 2: 113 sec (inserts TD Y)

unfortunately each edb query is slow (~ 400ms), so the total time is nrOfUpdatedOrDeletedData*330 + (some other stuff that takes some time but we didn't benchmark yet).

WDYT?
we would like to write some itests to demonstrate the problem, but it does not seem to work => [1]

thx+br
Richard

[1] https://groups.google.com/d/msg/openengsb-user/dap0CxN5EyQ/ljqw9OLzMrYJ

--
You received this message because you are subscribed to the Google Groups "OpenEngSB user group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openengsb-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Andreas Pieber]

which fields are queried? Don't forget that we don't index anything except the ID; do we need to? Couldn't we optimize the queries getting all entries at once?

Kind regards,

Andreas

On Tue, Feb 26, 2013 at 1:33 AM, Felix Mayerhuber <felix.ma...@gmail.com> wrote:

[Michael Petritsch]

Hi,

yes, we are querying more than the ID. We have to add a second ID to link duplicated models together. e.g. A model in domain X can have 3 representations in domain Y and to link these rep. together we have this 2nd ID. We could maybe get rid of the 2nd ID by appending some extra info to the normal ID, however we would need some way to query for parts of the ID then and this is currently not possible.

Also optimizing the queries isn't possible using the QueryInterface, since it currently supports only queries of the type 'key1:"value1" and key2:"value2" ...'

and not something like 'key1:"value1" or key1:"value2" ...' or maybe 'key1 in <List of values>'.

br

To unsubscribe from this group and stop receiving emails from it, send an email to openengsb-use...@googlegroups.com.

[Andreas Pieber]

Thanks for your response Michael, but this was rather directed directly @Felix (sorry if I wasn't clear about this). I think we could drastically optimize the queries if we a) allow "multiselects" and b) index all fields in the edb which could be part of the query. WDYT?

Kind regards,

Andreas

[Felix Mayerhuber]

Hi,

indexing will not really be possible, since the normal fields are not
part of the model itself but are model entries and all model entries are
saved as key/value/type triples in an own table. I am quite sure that
the allowing of "or" in the queries would do the trick. Have to
investigate that.

However, I can't imagine that this is really so slow. This is against
all of my measurements, so I hope that I find something tomorrow that
could be responsible for this delay. Like in the performance of the
updates and the deletes, there must be some reason why the performance
drops so dramatically, especially because I never encountered this
problem. Like I said, I will have a look at it tomorrow.

Kind regards,
Felix

>>>>> [1] https://groups.google.com/d/**msg/openengsb-user/**
>>>>> dap0CxN5EyQ/ljqw9OLzMrYJ<https://groups.google.com/d/msg/openengsb-user/dap0CxN5EyQ/ljqw9OLzMrYJ>

>>>>>
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "OpenEngSB user group" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send

>>>> an email to openengsb-user+unsubscribe@**googlegroups.com<openengsb-user%2Bunsu...@googlegroups.com>
>>>> .
>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .

[Christoph Gritschenberger]

Wasn't that the point of the idea of an "index-db":
A database that is a cached copy of the real edb, but:

* Models are represented as tables (to allow indexing)
* Only the latest version is available

I think the idea has been around for a while, but no resources to
implement it.

kind regards,
christoph

[Andreas Pieber]

I think there is already a prototype around for this. It just never had been proposed to us. Let's see if it will bubble up now :-)

But independently, I second Felix. There need to be some other problems, since those values are far too slow for what we've measured...

Kind regards,

Andreas

openengsb-user+unsubscribe@**googlegroups.com<openengsb-user%2Bunsubscribe@googlegroups.com>

.
For more options, visit
https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>

.

  --
You received this message because you are subscribed to the Google
Groups
"OpenEngSB user group" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to openengsb-user+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

  --
You received this message because you are subscribed to the Google
Groups
"OpenEngSB user group" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to openengsb-user+unsubscribe@googlegroups.com.