| [CDO] reading/writting throughput performances [message #619062] |
Thu, 29 May 2008 10:22 |
 Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
I've been messing around CDO lately and I hacked a few ugly unit-tests
measuring read/write throughput when I use CDO (RC2).
I'm using an embeded-derby database, two different metamodels (complex one -
250 EClassifiers/300 features and a simple one - 1 Classifier/3 Features)
The test is a "quick and dirty" one so please do not take these figures too
seriously, I would just like to have your input about the "order of
magnitude" I should expect or settings affecting seriously these
performances. I tried both JVM and TCP acceptor but the performances are
quite similar though JVM is a bit faster.
* First case : building a small model (10000 elements) with the simple MM,
only adding instances in an empty database :
commiting change on every add I get a 2 objects per second rate.
commiting changes every 10 adds - I get a 30 objects per second rate.
browsing the just commited elements opening a new transaction and getting a
new Resource instance, I get around 30 000 objets/sec rate just iterating
thanks to Resource.getAllContents().
* Second case : I built a big model in the database using the complex
metamodel. It contains 700 000 elements. The creation went pretty nicely (I
did not measured it exactly as it was launched during a night, but it seems
I got around 100 objects/sec rate in writting as I was writting every 700
objects.
Once the model is built the derby database is 222 MB (which - I heard - is
not so big for derby).
Retrieving the distant resource and calling eAllContents() on it, I get a 50
Objects/sec rate at best, which mean my eAllContents() call would take 4
hours !
This is probably linked to the way the mapping to db is done, here's the
config I used (came from CDO-server example if I recall correctly).
<repository name="repo1">
<property name="overrideUUID"
value="1ff5d226-b1f0-40fb-aba2-0c31b38c764f"/>
<property name="supportingAudits" value="true"/>
<property name="verifyingRevisions" value="false"/>
<property name="currentLRUCapacity" value="10000"/>
<property name="revisedLRUCapacity" value="100"/>
<store type="db">
<!-- type: horizontal | vertical | <any user-contributed type> -->
<mappingStrategy type="horizontal">
<!-- ONE_TABLE_PER_REFERENCE | ONE_TABLE_PER_CLASS |
ONE_TABLE_PER_PACKAGE | ONE_TABLE_PER_REPOSITORY | LIKE_ATTRIBUTES -->
<property name="toManyReferences" value="ONE_TABLE_PER_REFERENCE"/>
<!-- LIKE_ATTRIBUTES | LIKE_TO_MANY_REFERENCES -->
<property name="toOneReferences" value="LIKE_ATTRIBUTES"/>
<!-- MODEL | STRATEGY -->
<property name="mappingPrecedence" value="MODEL"/>
</mappingStrategy>
<dbAdapter name="derby-embedded"/>
<dataSource class="org.apache.derby.jdbc.EmbeddedDataSource"
databaseName="/tmp/cdodb1"
createDatabase="create"/>
</store>
</repository>
What do you think about that ? What throughput do you think I should
expect ? What are the main reasons fur such figures ?
I can provide you the "stupid" test case and even profile the code more
closely if you want.
Cédric
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
Powered by
FUDForum. Page generated in 0.01756 seconds
] 
Search
Help
Register
Login
Home
