XMI Import to DBMS Speed

[kjourdan]

I want to use a DBMS repository for common models that will be used by other projects.  The choice for DBMS is driven by 1) the need for co-development of the models by a globally dispersed team and 2) robustness to corruption.

I have a repository setup with a cloud connection and am importing xmi (1.1) files that were exported from a standalone model (eap file). One of the xmi files is 28 MB.  Importing this xmi file into a standalone model takes about 2 minutes; exporting takes about 30 sec. Importing the same into the DBMS repository takes about 42 minutes; exporting takes about 55 sec.

Is this long import time due to a setup issue of the repository, network issue, or is it expected?

[Geert Bellekens]

EA is very very chatty with the database. It can launch up to a few thousand little sql queries at the database.
When this database is located on the same machine (.eap file) then there's little overhead (both happen in memory), but when the database is located on another machine,  then you have a certain overhead because each query has to be packages, sent over the network to the server, received and processed.

So the trick is to make sure to have a large bandwidth available from the machine that runs EA and the database server.

Model transfer is a lot faster, but you can only use that for the first .eap file you transfer (as it overwrites the target model completely). It might make sense to first make a consolidated .eap file that contains the whole lot, and then do a model transfer, iso importing the individual xmi file to the server.

Also make sure you are not using Oracle as DBMS as this is know to be a slow performer when used with EA.

Geert

[Paolo F Cantoni]

I want to use a DBMS repository for common models that will be used by other projects.  The choice for DBMS is driven by 1) the need for co-development of the models by a globally dispersed team and 2) robustness to corruption.

I have a repository setup with a cloud connection and am importing xmi (1.1) files that were exported from a standalone model (eap file). One of the xmi files is 28 MB.  Importing this xmi file into a standalone model takes about 2 minutes; exporting takes about 30 sec. Importing the same into the DBMS repository takes about 42 minutes; exporting takes about 55 sec.

Is this long import time due to a setup issue of the repository, network issue, or is it expected?

Your ratios are to be expected...

If you have a server based DBMS, why are are you creating separate repositories?  We run a single repository enterprise wide with very few problems - with the benefit of easier rationalisation across projects.

Our repository has 70,000 items (only half of which are actually model items), 90,000 relationships (between the 35,000 model items), over 30,000 diagrams.  Our Project Transfer snapshot takes about 7 mins to export and just under 2 hours to re-import.  We have currently, approx 15 project specific model - some "quiescent"; and an enterprise wide model. We have started importing external reference models as well.

HTH,
Paolo

[kjourdan]

I am developing S/W architectures for multiple automotive products with multiple OEMs.  Multiple repositories are needed for this and our development cycle.  I will need to deliver a released S/W architecture that will be implemented and released; each S/W release must have a matching S/W architecture.  Each released S/W architecture must be reviewed (need to be able to identify changes) and will need to be placed under version management to allow visualization and restoration at a later date.

Has anyone had experience using Citrix/EA with a DBMS repository?  Would this improve the xmi import time? I am thinking the xmi files would be copied to the server and import should be much faster.

[qwerty]

Coincidentally I just had a migration from SQLite to SQL Server (in a completely different context) and found the latter a factor of 50 to be slower for each single query. So the more queries, the more it did hurt. It's likely similar with a migration from a local MS Access to SQL Server (or any other RDBMS). And as Geert already pointed out: EA is quite chatty with the DB.

q.

[Geert Bellekens]

Has anyone had experience using Citrix/EA with a DBMS repository?  Would this improve the xmi import time? I am thinking the xmi files would be copied to the server and import should be much faster.

The bottleneck is the network communication between the EA client and the database, not between the xmi file location and the EA client.
So unless you install and run EA on the same machine as the Database server that is not going to help much.

Geert

[kjourdan]

Sorry.  The xmi would be copied to the server and an instance of EA would be run on the server (remotely) to do the import.

[Paolo F Cantoni]

I am developing S/W architectures for multiple automotive products with multiple OEMs.  Multiple repositories are needed for this and our development cycle.  I will need to deliver a released S/W architecture that will be implemented and released; each S/W release must have a matching S/W architecture.  Each released S/W architecture must be reviewed (need to be able to identify changes) and will need to be placed under version management to allow visualization and restoration at a later date.

Has anyone had experience using Citrix/EA with a DBMS repository?  Would this improve the xmi import time? I am thinking the xmi files would be copied to the server and import should be much faster.

Have a look at the new cloning mechanisms in v13.  Theoretically they should be just what you need.  We've done a little testing and (once we got our heads around how it works) it seems to show a lot of promise.

Source code level version control for repositories is a chimera.  You can waste a LOT of time and resources chasing that.  If your architectures are "frozen" once released, then a snapshot of the repository will do the trick.

Paolo