Severe performance issues with v14.1 - any ideas?

[Paolo F Cantoni]

Paolo,

I think Eve is referring to stereotype inheritance

If you define a relationship on the parent (abstract?) stereotype then you don't have to repeat that for each of the child stereotypes

e.g. To explain it using UML terms. If you define the relation "datatype" between Property and Datatype, then you don't have to define it again between Property and Simpletype and Property and Enumeration.

Without knowing your metamodel, we can't really say if there is an opportunity to generalize some of the relations between concrete stereotypes and replace them by relations between their abstract generalizations.

Geert

Thanks Geert,

Does that mean I have an inheritance relationship (Generalization) between (for example) Technology Node and System where System inherits from Technology Node (In ArchiMate terms)?

Paolo

[Glassboy]

Does that mean I have an inheritance relationship (Generalization) between (for example) Technology Node and System where System inherits from Technology Node (In ArchiMate terms)?

Do you mean System Software or have you further extended Node to System?

[Eve]

As Geert said, inheritance.

With 31000 links there has to be at least some opportunity. At a minimum, consider using an abstract stereotype as the source and target of each of your connectors. Then add a generalization from each valid concrete stereotype. Anything over 2 possible stereotypes at each end or 3 at one end you can introduce an abstract class and reduce the number of model constructs vs the simple approach.

If you look in the ArchiMate3 technology file. Yes, ArchiMate_SystemSoftware extends Node, which extends Internal Active Structure, which extends Active Structure, which extends Structure, which extends StrategyAndCore and Element, which extends Concept. It picks up different stereotyped relationships from each of those abstract classes. We introduced StrategyAndCore (because it made things easier) and an Node (so that ArchiMate_SystemSoftware didn't inherit the extension.)

[Sunshine]

...
The large scale diagrams are a mandate from management. 
...

Thats your problem there, listening to management who know nothing about modelling.

[Paolo F Cantoni]

...
The large scale diagrams are a mandate from management. 
...

That's your problem there, listening to management who know nothing about modelling.

Golden rule applies...

But in any event, "landscape" style diagrams will inevitably lead to diagrams with a large number of objects  (especially in an environment such as ours - where systems proliferate like weeds) and we have more business activities than normal in a standard organisation.

However, we've tracked down some of the performance issues to problems with Zooming - which we'll report when we've got a better handle on it.  We've suggested changes in process for some of our users.

So as I initially said, apart from the zooming issues, the problem may not directly be V14.1 itself.

Paolo

[Paolo F Cantoni]

As Geert said, inheritance.

With 31000 links there has to be at least some opportunity. At a minimum, consider using an abstract stereotype as the source and target of each of your connectors. Then add a generalization from each valid concrete stereotype. Anything over 2 possible stereotypes at each end or 3 at one end you can introduce an abstract class and reduce the number of model constructs vs the simple approach.

If you look in the ArchiMate3 technology file. Yes, ArchiMate_SystemSoftware extends Node, which extends Internal Active Structure, which extends Active Structure, which extends Structure, which extends StrategyAndCore and Element, which extends Concept. It picks up different stereotyped relationships from each of those abstract classes. We introduced StrategyAndCore (because it made things easier) and an Node (so that ArchiMate_SystemSoftware didn't inherit the extension.)

Thanks, Eve,

I get the concept; and now I've seen a worked example, it all makes sense.  Also, it's much closer to what I'm after (in terms of metamodelling our technology).

Since our hand-crafted MDG didn't use the generalizes attribute, I'll have to go through our file and create these linkages in our model. But the outcome will be worth it.

I take it the QuickLinker will generate the links for the specific metatypes "on the fly" as required.  Consequently, ALL the required abstract metatypes for a given technology must be in the resulting MDG file.  Since we're learning this and our intern is of a "tender age", when things don't work as expected, we need to know where to look.

Paolo

[Eve]

Yes, they are generated on the fly. The abstract stereotypes need to appear in the technology.

[BruceTOGAF2]

Yes, we are also experiencing poor performance on earlier versions and on Sparx EA V14 since we moved from a LAN architecture to a WAN architecture. Due to the move, we implemented Sparx Cloud Service which required upgrading to Sparx EA V14.  Sparx Cloud Service has improved things but still the performance is nowhere near as good as it was in a LAN architecture. Zooming on large diagrams (hundreds of diagram objects) is very noticeable. Our Sparx Repositories are Oracle. Instances per object type (in addition to the list below we have about 10,000 instances of other various object types)
Object type   Instances
Activity   26490
Class   19080
Requirement   13306
Component   9584
Package   6964
Event   6151
Decision   5341
Note   4784
Boundary   4545
Text   3811
ActivityPartition   3399
UseCase   3366
Artifact   2076

[Geert Bellekens]

You seem to be collecting all the performance killers here:

- WAN (network bandwith/latency -> with or without Cloud Server)
- Oracle
- Diagrams with lots of objects.

Recommendations:

- Use a terminal solution such as MS RDS (Remote Desktop) or Citrix instead of connections over WAN
- Use SQL Server or MySQL instead of Oracle
- Keep your diagrams sane (rule of thumb, you have to be able to print each diagram on a A4 while everything is still readable)

Geert

[qwerty]

- Keep your diagrams sane (rule of thumb, you have to be able to print each diagram on a A4 while everything is still readable)

Except for a few (!) wallpapers built preferably from existing small A4 (or Letter for the US guys) diagrams.

q.

[jalbers]

I run JScripts on large SVN version controlled models that identify which packages need to be checked out to make a set of changes, then do another pass to check out those packages using the Package VersionControlCheckout() API.

With 14.1 (and maybe earlier, not sure) the time to run these scripts is untenable.  For a simple pass checking out, say, 100 small packages, it can take one to three minutes per package to checkout.  Task Manager reports that the EA process is Not Responding for most of that time.  The time that svn.exe runs per package is less than a second.

I also notice that as the script runs, the display resolution switches between normal high-res and something low-res like 1024x768.   The Not Responding periods correspond to the display in low-res mode.

I usually run model work via an RDP remote session.   I tried instead running directly on the target system, logging in on the main console.

The hang times go down to 10 seconds or less and the overall time to run large scripts becomes tolerable.

Does anyone understand why the graphics resolution toggles as control switches from EA to SScripter.exe, why this blocks EA, and how to resolve the problem?  Is there something magic like a Registry setting that would resolve?

I often need to work on large EA models remotely, and the slowdown is a problem.

Regards,