EA performance concerns - with WAN users

[Dave_Bullet]

Hi there,

I work in a geographically dispersed team (Aus / NZ).  We want to use one central SQL server repository to avoid the hassle of synchronising multiple repositories.

I have a diagram with about 118 elements on it and it takes only 2.5 seconds to load since I am LAN attached to the SQL Server.

I did a SQL profiler trace to see what EA was sending the SQL server to load the diagram.  It sent about 118 of the following SQL statements:

select * from t_taggedvalue where BaseClass in ('application')

(where 'application' happens to be a stereotype on many of the elements in the diagram).

The above statement returns nothing.  I'm guessing it is calling this unnecessarily once for each of the same stereotyped item - rather than just once for the diagram.

I am concerned my WAN attached users will have a huge performance hit since this "chatty" traffic will take a long time with link latency - making the product unusable with a single repository.

Any suggestions?  Preferably - can Sparx please performance tune the use of SQL on the product?

Thanks,
David.

[«Midnight»]

Hi Dave,

There's been some talk about EA traffic with SQL Server recently. This sparks (no pun intended) a memory of a similar symptom some time ago, which was also mentioned in posts here. I don't remember the details, but it seemed that EA was performing some queries - which I think might have brought back result sets rather than single records, but I'm not sure after this time - for each element or feature or something. End result could be many (very many) queries issued to grab the data for a single model.

Shortly after I saw this, the release notes for a new build mentioned something about a tweak to the SQL Server retrieval engine, and I did not notice anything about the problem afterwards.

If it were just a tweak, perhaps the root case remained and has resurfaced. Definitely worth issuing a bug report, in the hopes that, if Sparx has not addressed this, a quick tweak at the very least can be done immediately. It seems that new releases are currently on a monthly schedule, and you probably don't want to wait until August.

David

[Dave_Bullet]

Thanks David,

Appreciate that.  I hope its a setting I can change, but I will raise a formal bug report.  I'm getting my Aussie colleague to open the same model and connect to show it is the above SQL that is excacerbating load times.

For me - this is a #1 showstopper to us using a single repository across our company.  One of the key reasons we chose EA so we didn't have to worry about model synchronisation and could maximise model re-use.

I will generate a SQL server trace today (comparing local and remote performance for the same operations) and send to Sparx as a bug report.

I'm really hoping they can fix it in the next month's build..... as I have no workarounds.

Cheers,
David.

[Eve]

Hello David(s),

We do reguarly work on optimising the SQL performance of the various functions of EA.  This issue should be fixed in our next release.

If you still want to generate a SQL server trace then go ahead.  We might be able to find some other potential improvements from that.

[Dave_Bullet]

Thanks Simon,

Great news!

I'll email the trace I have to Sparx support.  The trace was done from my workstation to the local (high speed connection to the SQL server "server") database - hence the diagram open only takes 2.5 seconds on the trace.  I am trying to get my Aus colleague to test the same model open against the same SQL server which should confirm my suspicions.  Even though the SQL query returns an empty result set - it is the repeated calling of the same SQL for each element of the same stereotype in the diagram that will excacerbate latency.

Thanks,
David.

[GMuys]

I'm really hoping they can fix it in the next month's build..... as I have no workarounds.

Cheers,
David.

Dave,

A workaround could be to use EA via Terminal Services. That's what I do all the time because indeed, connecting via the Internet, even with high speed broadband, is not manageable for large models. With a model with 1200 elements (still growing), it opens immediately via TS, while it takes a couple minutes over the WAN.

When you consider the day to day work, it's even worse in terms of lost productivity, because opening a diagram and most importantly, updating it, takes way too long over the WAN.

Hope this helps.

Gilles

[Dave_Bullet]

Thanks for that.  Yep - I've thought about using TS or Citrix to deploy over (ie. we use Visio on Citrix without issues) so EA should be fine.

Good news is Sparx has logged a bug and said it will be fixed in the next release (presuming this is the one after 6.5).

I hope it is something Sparx tunes across the board with the product since it would really open up the market to large multi-nationals (= lots more license $ for them!)

Cheers,
David.

[Dave_Bullet]

My hat's off to Sparx!

I've just tried build 792 and that erroneous SQL has gone.

Well done chaps - and thanks for fixing so quickly.  I'm really impressed!

I'll get my Aussie colleagues to try and see what improvements they notice.

Thanks once again,
David.