EA 7.5 Beta 1 - Performance observations

[Dave_Bullet]

I have a largish central SQL Server 2000 database we use for our corporate modeling.

I'm running EA 7.1.834 and EA7.5 Beta 1 side by side on the same client - connecting to the same server (on the same floor of our building).

Here's what I've found, opening our central database and a large / complex diagram

1. Lazy load
This feature is excellent and cuts the initial opening time from 18 seconds to about 3 - 4 seconds - well done Sparx

2. WAN Optimisation
Although I understand this solves the problem of bandwidth and not latency constrained networks - this provides no benefit as EA fundamentally needs to change to set based retrievals and not object based retrievals.
Opening a complex (100+ element) diagram takes about 21 seconds initially.  With SQL server doing some caching, this reduces to about 7 seconds when reopening the diagram

WAN optimisation actually adds a little overhead here, so we are better off not using it to improve diagram load speed.

Remember - this is local client to local server on the same switch (100Mbit/sec).  Bandwidth is no issue, and there is nothing I can do to further reduce latency.

3. Diagram rendering
Panning through the diagram using the new rendering engine is FAR SLOWER than EA 7.1.834.  I set to basic and turned off the anti-aliasing and still very slow by comparison.

So my verdict on performance is 1+ (lazy load), 1- (diagram panning speed) and 0 (diagram load no quicker).

I need to do some more investigation on why diagram load and rendering is so slow.  It could well be due to the shape script being applied to every element on this particuarly large diagram.

Cheers,
David.

[Dave_Bullet]

Some stats on the large diagram:

The particular diagram contains 146 elements and numerous connectors.  Each element is rendered by shape script
EA makes 28 select calls to the database !!!!!  these span approx 6 seconds (of an 8 second opening time)
5 of those SQLs are issued one after the other and are identical
3 "select .... from t_diagram" could be collapsed into a single call
Several calls are made to t_seclocs - can these be collapsed?

Reducing the above calls would greatly help latency, reduce database load and improve performance.

[Eve]

Well David, your observations on lazy load an WAN optimization confirm what we've seen here.  The WAN optimization isn't intended for your scenario.  It will slow things down.  But if you were working from home for some reason, it would likely help a lot then.  You still wouldn't want to do a large report or XMI export, but it makes the whole thing a lot more usable.

I don't know what would be causing your diagram rendering slowness.  Yes, the anti-aliased drawing modes are both significantly slower than the basic mode.  But the basic mode is pretty much EA drawing as it always has.  There shouldn't be any difference there.

You're getting many more database calls than is normal for loading a diagram.  The normal calls for all diagrams are very much set based that won't change regardless of the size of the diagram, although I am aware of a few special cases that can do more.

If you can, and would like to, you can send a model into Sparx Systems and I'll find someone to look at the issue.  Either way, I'd recommend a support query directly to Sparx Systems.  We don't go into detailed support issues of this nature on this forum.

[Dave_Bullet]

Hi Simon,

My apologies if I came across a little aggressive / annoyed.  I'm just a bit disappointed.  Was hoping that all my performance problems would disappear and I could convert the unfaithful in this organisation away from Visio.

I'll produce a cut down model with the large diagram in question (pulling together all the elements that make it up).  That will help me perform some troubleshooting (ie. is it an EA problem or an environmental problem).  I'll also try a local SQL Server install to eliminate any network latency issues (I've got a dual proc / dual core xeon machine so should be ok).

I'll submit a formal request to Sparx with this cutdown model if that helps...

Thanks again,
David.

[mrf]

Hi David,

It may also be worth disclosing which addins you have active in your email. They could also be contributing to redundant SQL calls that you are witnessing.

[KP]

The particular diagram contains 146 elements and numerous connectors.  Each element is rendered by shape script
EA makes 28 select calls to the database !!!!!

Can you trace any of those selects to a specific shape script command? Shape scripts shouldn't ever cause any database queries - all the data they access should be held in memory - so if it ever happens it needs fixing. In particular, have a look at any HasProperty() functions.

Of course it might just be that shape scripts are slow...

[Martin Terreni]

Ok, here are my conclutions about 7.5 performance:

1) Lazy load- grate! it reduce a model with 50 sec loading to 4 seconds (in LAN) and 15 minutes loading to 1.5 minute in WAN.
2) WAN server - from office of course no real effect. From WAN connected through VPN it reduced a model which takes abourt 15 minutes to load (if not more) to 6 minutes.On a smaller model which takes 1.5 minutes to load it loaded in 30 seconds. When combined with Lazy load from home it reduce load time to 30 seconds!

Final conclution -
1) WAN optimizer makes it faster,but is a little disapointmentI was hoping ti will do magik, but maybe it was to much to expect.
2) Lazy load is a victory!
3) still problematic to work through WAN.


PS: can it be that the WAN server is not realy a service, it needs its console to be opened?

[mrf]

Martin: Yes, at the moment the server runs as an application, not a service.

I think it's a little unfair to compare the WAN optimizer with Lazy Load based on model load times. Lazy load is an internal heuristic designed to load model contents on demand, and as such provides a very significant reduction in model load time.

The WAN optimizer on the other hand seeks to improve performance by reducing the amount of data that is transmitted over the WAN, and as a result you should notice a performance increase in all aspects of the application (eg opening diagrams, XMI exporting), not just model loading.

In my opinion, the two options are both as valuable and necessary as each other to make EA across a WAN more usable.

[Martin Terreni]

You are probably right, though WAN optimizer is unusable if it is not a service.
Imagine I have users all over the glove now (India,Europe,USA,Israel...) I have to leave my self logged in to the server so users can connect? this is not really reliable.
Are you planning the release as service with the production of 7.5?