[CDO] Inefficient SQL generated for CDORepository inserts/removes [message #1792170] |
Thu, 12 July 2018 10:03 |
Linuxhippy Mising name Messages: 71 Registered: July 2009 |
Member |
|
|
Hi,
We are experiencing servere performance issues when inserting / removing Objects from a rather small (~1500 entries) CDORepository which is backed by an Oracle database.
It seems to keep ordering, CDO generate a huge amount of SQL statements that are executed non-batched (~3 for each CDO object contained in the Repository) - adding a single Object at the beginning of the Repository causes 4500 sql statements to be generated, multiplied with ~15ms round trip latency this results in over a minute the modification takes.
This is caused by the moveOneUp/moveOneDown methods called by AuditListTableMappingWIthRanges$ListDeltaVisitor.
This was observed when using cdo.server.db.4.4.0.v20160607-1254, but looking at the latest CDO code those methods seem to be more or less working the same way.
Is there any way to make inserts/removes to/from a CDORepository more efficient with a database store?
Thank you in advance & best regards, Clemens
[Updated on: Thu, 12 July 2018 10:05] Report message to a moderator
|
|
|
Re: [CDO] Inefficient SQL generated for CDORepository inserts/removes [message #1792253 is a reply to message #1792170] |
Fri, 13 July 2018 09:32 |
|
Linuxhippy Mising name wrote on Thu, 12 July 2018 12:03
It seems to keep ordering,
Yes, EMF's many-valued features are generally implemented with Lists, which are ordered. If you define such a feature as "Ordered=false" in the Ecore model, CDO uses a slightly optimized org.eclipse.emf.internal.cdo.CDOObjectImpl.CDOStoreUnorderedEList, see org.eclipse.emf.internal.cdo.CDOObjectImpl.createList(EStructuralFeature).
Linuxhippy Mising name wrote on Thu, 12 July 2018 12:03
CDO generate a huge amount of SQL statements that are executed non-batched (~3 for each CDO object contained in the Repository)
It's possible that there's room for optimization, but I'd need to know exactly what operations/modifications you've done.
Linuxhippy Mising name wrote on Thu, 12 July 2018 12:03
- adding a single Object at the beginning of the Repository causes 4500 sql statements to be generated, multiplied with ~15ms round trip latency this results in over a minute the modification takes.
This is caused by the moveOneUp/moveOneDown methods called by AuditListTableMappingWIthRanges$ListDeltaVisitor.
By "at the beginning of the Repository" you mean "into a new, empty repository"? Then, what are those 4500 statements? A single, new object should not cause any moveOneUp/Down() calls. Are they "CREATE TABLE" statements? How big is your meta model? What is this object? Does it have many-valued features with many elements? I need more details (ideally an executable test case to reproduce the scenario) to properly comment...
Linuxhippy Mising name wrote on Thu, 12 July 2018 12:03
This was observed when using cdo.server.db.4.4.0.v20160607-1254, but looking at the latest CDO code those methods seem to be more or less working the same way.
Is there any way to make inserts/removes to/from a CDORepository more efficient with a database store?
Indeed it seems that AuditListTableMappingWIthRanges$ListDeltaVisitor might profit from statement batching. Are you interested in contributing a respective patch? NonAuditListTableMapping$ListDeltaWriter already seems to employ batching.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04455 seconds