Severe performance issues with v14.1 - any ideas?

[Paolo F Cantoni]

Since recently moving to v14.1 we have experienced a slowdown in performance.  At this stage, we aren't blaming v14.1, we're just trying to acquire information to help us determine where the problem is.

Due to business requirements, we've had to develop large-scale diagrams to run over the entire landscape (they weren't there last year).  Some of these are VERY large.  For example, some systems related diagrams have (currently) nearly 800 objects on them.  We anticipate that they might eventually require up to 1000 objects on them.

Is anybody using such large scale diagrams?

Other information of possible relevance:
SQL Server Repository (on VM)
Total objects in Repository: 99900 - approximately half of which are "administrative" objects.
Total object properties in Repository: 480000
Total packages in Repository: 8400
Total connectors in Repository: 136000
Total diagrams in Repository: 45500
Total diagram links in Repository: 580000
Total diagram objects in Repository: 480000

Some objects are quite "rich" (have lots of tags) - Systems, for example, have 25-30 tags each.

Does anybody have any suggestions on how we can configure wither the client or the server to improve performance?

TIA,
Paolo

[Geert Bellekens]

Paolo,

I think you'll have to rethink the huge diagrams.
I don't see a valid reason to put up to 1000 objects on a diagram.

Your repository is not exceptionally large

That being said, the general performance recommendations apply

- look at the network traffic between client and server, that is very often the bottleneck

I've seen good results with terminal server solutions such as Citrix or Remote Desktop (server and client being in the same datacenter)

Geert

[Sunshine]

I've been using V14.1 since it was released and not noticed any performance issues.
Whilst we don't have diagrams with 1000's of objects on them we do have quite a sizable model. Our model has the following stats for a comparison with yours;
Packages: 8929
Element: 61834
Diagrams: 4157
Connectors: 35679

[Eve]

Where are you experiencing performance issues? A very large diagram might cause a slow down. In the examples I've seen in the past the number of connectors is much more problematic than the number of objects.

We've also seen at least once an issue where sql server indexes have become so fragmented that it was effectively doing a full table scan all the time.

[Paolo F Cantoni]

Thanks all for your replies.

We're still investigating, but apart from some weird behaviour when zooming, not everyone is experiencing the same issues.

The large scale diagrams are a mandate from management.  At this point, we don't have much say in the matter.  However, we are investigating if, for some diagrams, the use of frames may be helpful.

We did some timing runs and for some machines, loading the 800 object diagram (on an i7 Surface Book 2 across the network to the server) took less than 20 secs - which to me is acceptable.

By sitting with the users and observing their usage, we are starting to see what they are complaining about.

We'll keep you posted.

Paolo

[Paolo F Cantoni]

Where are you experiencing performance issues? A very large diagram might cause a slowdown. In the examples I've seen in the past the number of connectors is much more problematic than the number of objects.

We've also seen at least once an issue where sql server indexes have become so fragmented that it was effectively doing a full table scan all the time.

Eve,
quick question.  To your understanding, is the problem less if connectors are suppressed (such as currently in our largest diagrams - they're basically auto-colour "landscapes" where connectors aren't visible); or is it just the number of applicable links on the diagram?

[Eve]

Try going into the diagram properties and disabling all connectors. Any difference?

[Paolo F Cantoni]

Try going into the diagram properties and disabling all connectors. Any difference?

That's what I was asking you... 

The massive diagrams have connectors disabled.  I was asking would there be an even slower performance with them enabled?

Paolo

[Eve]

I just ran a couple of tests on a diagram with 104! connectors. (That's a factorial)

There doesn't appear to be any difference between not showing any connectors and setting each connector to hidden.

In that diagram it's noticeably slower moving around the diagram or trying to select anything with even a fraction of the connectors visible.

[Paolo F Cantoni]

I just ran a couple of tests on a diagram with 104! connectors. (That's a factorial)

There doesn't appear to be any difference between not showing any connectors and setting each connector to hidden.

In that diagram it's noticeably slower moving around the diagram or trying to select anything with even a fraction of the connectors visible.

Thanks,  that's not unexpected, based on what we've seen with connectors suppressed.

Do you think that the fractional behaviour is only an expression of "If ALL connectors are not suppressed (or hidden), ALL connectors must be computed, regardless of whether they are visible or not"?

Paolo

[Eve]

Do you think that the fractional behaviour is only an expression of "If ALL connectors are not suppressed (or hidden), ALL connectors must be computed, regardless of whether they are visible or not"?

Absolutely not. It's much much worse with all connectors visible.

[Paolo F Cantoni]

Do you think that the fractional behaviour is only an expression of "If ALL connectors are not suppressed (or hidden), ALL connectors must be computed, regardless of whether they are visible or not"?

Absolutely not. It's much much worse with all connectors visible.

(my emphasis)

As we've just discovered on a separate diagram (in a separate repository).  We're trying to move our QuickLinker (CSV) to a model based specification.  Our Intern added 31,000+ stereotyped relationships to the diagram with the Vertex Stereotypes.  It's been running for an hour so far (@13% CPU utilisation ).75Gb )   

Paolo

[Eve]

Make sure you turn off connector line jumps.

Hopefully you'll be able to reduce that number substantially by moving the relationships to supertypes.

[Paolo F Cantoni]

Make sure you turn off connector line jumps.

Hopefully you'll be able to reduce that number substantially by moving the relationships to supertypes.

I think we have.
I'm not sure how long it took to load the diagram (since we left it running overnight).  However, after saving the diagram (and getting the diagramlinks created (we then hid the 31000 via query).  It seems to take about 17 mins to load.

What is this supertype of which you speak?

In the profile toolbox we have metaclass, stereotype, enumeration and profile package.

Can you provide an example?

Because the _MeaningForwards and _MeaningBackwards are, in our view incorrectly, defined as Metaclass (as opposed to Stereotype) attributes, we have to create a 1:1 Metaclass for each stereotype (as we populate ALL our QuickLinker semantics).

Obviously, we'd be keen to raise the level of definition.  As far as I'm aware, extension is not inheritance.  So how can we do it?

TIA,
Paolo

[Geert Bellekens]

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