EA "at scale"

[Paolo F Cantoni]

I wasn't sure how I should query for this so if this has already been discussed, can someone point me at the previous discussion?

Having just got a new "gig", I'm looking at creating an organisation-wide repository based on ArchiMate concepts which will handle, a number of states (e.g. Current->Future - plus at least 3 others, and each project gets its own "slice"), a number of layers from "Meaning" to "Implementation" (at varying degrees of detail).

So my question is, what kind of "scaling" can I expect?  

• What (on disk) size of repositories have people created?
• How many (simultaneous) Users?
• How many Elements?
• How many Connectors
• How many Diagrams

I'm just looking for indications that my proposed solution is viable.

TIA,
Paolo

[Geert Bellekens]

Hi Paolo,

The biggest model I worked with is about 400 MB when transferred to an .eap file.
It contains about 120.000 elements and we probably have an average of 15 simultaneous users.

We are running on an SQL Server backend and we don't have any issues with performance.

The only thing that is slow is when we open a sequence diagram message to a huge "I do everything" interface that contains a no less then 500 operations (owned or realized). That usually takes about 10 seconds, but I can hardly complain about that can I

I've heard many stories from other user that support the this. EA actually scales very well.

The only negative sound I heard was in relation to an Oracle backend. For some reason EA and Oracle don't seem to play nice.

Geert

[Eve]

I can't go into any details, but I know that there are quite a few customers out there with very large databases.

As long as you choose your back-end database reasonably (ie. Don't expect Access or firebird to scale as well as some of the others) you should be fine.

[Paolo F Cantoni]

Thanks for your input before.  I have a different, but related, question.

Version control of a repository requires export of the XMI (either transparently - via on-line VC - or explicitly - via of-line VC).

I would assume that during the export process, the exported branch is locked to prevent corruption of the export.  Can someone confirm that?

If we have a large scale repository; for the sake of discussion lets assume: >100K elements, >13000 diagrams, >2GB (if it were an .EAP file).  some branches might have upwards of 3000 elements.

It seems to me that direct VC would interfere with normal operation - assuming say 10-20 simultaneous updates.  The same would be true of off-line export, I guess.  Can someone confirm that?

I note that project transfer is a very quick process (say <30mins on a decent machine for such a size of repository) - whereas XMI export can be quite long.  So my idea was to nightly do a project transfer to another repository and perform any VC from the copy, at our leisure.

I'm of the view that version control for repositories is QUITE different from VC for source code and the only real use is to allow some tentative recovery if something goes horribly wrong.   I believe it's better to have snapshots of the entire repository (compressed) and held for some suitable period - which this solution gives us "en passant".

Thoughts appreciated, anyone?

Paolo

[Eve]

First, project transfer is a valid backup strategy. You could also use a sql dump. Certainly if all you are after is a backup, XMI is going to be the slowest approach you can use.

As for version controlling a single xmi export of that size. I would say it means you're doing something wrong.

1. Use the option in version control (or package control) to save child package stubs/not include child packages.
2. If you don't have that option because you're manually saving xmi. Define package control on the packages. That way you can break it up and still do a single batch export.
3. If the option isn't going to help because everything is inside a single flat package... Well, if you have a model that size in a single package I won't even recommend breaking it up. I would recommend giving up.

The version control option for saving to stubs is highly recommended. And given it is there, the only reason you should be exporting a package that large is if it's a flat structure that large. If you're manually exporting inste

[Paolo F Cantoni]

Thanks for that Simon,

I didn't explain myself well enough.  I normally use stubs were appropropriate during export (whether manually or automagically).  So I'm NEVER exporting a single XMI.  Indeed, the corporate repository is split into a number (<12) of root nodes of varying content and depth.

However, we have determined that in a true enterprise repository, the elements need to be separated from the viewpoints (to use ArchiMate terminology - diagrams for the rest of us).

The elements are held in branches by the element type and even though the element type is broken into alphabetised folders to reduce the size of individual folders (because of EA's behaviour when adding elements and diagrams to folders), there's still a s"shirtload" of packages to export.

I've noticed, when I've automated the snapshotting of smaller (but still large) the cycle time for each package can be quite large since EA has to aggregate the cross-package connections which in an enterprise repository can be quite numerous.

That's why I thought of exporting from a clone.

BTW: Can you confirm that during export, the packages in the branch to be exported are locked?

Paolo

[Eve]

I don't think there's a lock applied, most of the information is retrieved up-front though.

[Paolo F Cantoni]

I don't think there's a lock applied, most of the information is retrieved up-front though.

Is anything locked during the retrieval process?

I would have thought you needed to create some consistency - while you collected the information (which might take a while)...

Paolo