Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: canderson on March 05, 2008, 08:17:02 pm
-
Hi all,
Has anyone any experience of using EA over a WAN?
When I read the manual and saw you could upsize a model to a SQL server or Oracle database I thought that would provide me with the robustness I needed.
However, having tried it, the performance is pretty poor.
Typically it takes 1 minute to open the model and a further 30 seconds to open a diagram (and these aren't particularly large models or diagrams).
Are there any tips, tricks or tweaks to make my turkey fly?
Many thanks,
CA.
-
In fact I am just sitting here right at the slow end of such a (WAN) turkey and I can confirm that performance of that bird is, well, friendly spoken, suboptimal.
However I am not blaming EA for doing this- as the model evolved there has not been much of a decrease in performance nor an increase (ok, I can dream, can I ?).
In the office performance is very well so I am blaming the (encrypted tunneling) Extranet for the issue.
Oliver
-
I didn't mean to imply I was displeased with Sparx or EA - that's not the case.
I just wondered if anyone had any tips to make it run faster - or if it ran acceptably for other users. Knowing this is a common issue makes me feel a little happier, though now I need to work out a solution.
I'm going to get some of our network tech's to take a look at the VPN and try some performance tests.
I just wondered if there was anything obvious I might be doing wrong.
Thanks for your reply.
CA.
-
CA and Oliver,
Please let Sparx know ASAP. EA has always been 'chatty' with DBMS repositories. This has caused some grief when slow connections - long pipes and such - are involved.
However, from time to time tweaks in the EA feature set or DBMS interface have caused some builds to suddenly slow down to the point where it becomes obstructive. This often affects a subset of the supported DBMS engines, so it is not always picked up in testing.
Sparx has in past taken this kind of thing very seriously. But you've got to let them know before they can address the problem.
So, please make bug reports, both of you. If you are using the 7.1 beta use the bug report link on the beta download page, otherwise use the normal route. It would be a shame to have this get into the production 7.1 release.
So please do this right away. Remember that Sparx is in the Land of AUS, where they think the weekend starts on Thursday evening. [Or something like that; they're all upside down to me... :-?]
David
-
I would echo the recommendation to send us a support request. Make sure you let us know what database you're using. The results of general performance tests are useful, along with any sample data you're able to provide.
-
Our EA Deployment whitepaper was updated some time ago and now includes information on various configurations and how they perform over WAN environments. Might be worth a read:
http://www.sparxsystems.com/downloads/whitepapers/EA_Deployment.pdf
One recommendation when running over a WAN (if possible) is to try using a Terminal Service connection onto the local network. Having EA running on the network local to the server and only dealing with the UI over the WAN can drastically improve performance. This solution is mentioned in the Deployment whitepaper.
"In cases where the connection speed between sites is reasonable (20–60ms latency), but the volume of throughput data is restricted (i.e., a 64k bandwidth), then a terminal server type application can be used to emulate Enterprise Architect on remote work stations."
-
In my opinion EA needs some fundamental rearchitecting for it to scale. However it probably only needs it in 2 places to greatly improve performance.
Diagram opening:
1. A SQL request is generated for each and every element on a diagram when loading. This is really poor and should be fixed. Please sparx - replace the object based "element by element" querying when opening a diagram to a batch "read" of t_diagramlinks, t_diagramobjects and t_connector.
Initial model open:
2. Do not recersively retrieve the whole project hierarchy package by package. Instead either retrieve as required (ie. as packages are expanded) or do a bulk read as per 1 above. (t_package and t_object).
EA should take approx the same time to read from the database to open a diagram whether 10 elements or 500 elements.
I do not think it is acceptable to expect terminal services / Citrix to work around this problem. The product should perform well and scale well over WAN links if it is truly to be considered an Enterprise Architecture tool for large corporates over geographically spread regions.
David.
-
canderson,
As an immediate help - you could look at SQL based replication (ie. if using MS SQL Server). By putting the database as close as possible to EA, you'll minimise latency overhead on EA's database calls. Please note however EA is broken when it comes to diagram copy and paste as it does a "select *" and then crashes (due to the extra columns SQL Server adds to EA base tables to support replication). I don't like how SQL server does replication (trigger based and adding a GUI tracking column to EA base tables), but there is little chance of changing that.
David.
-
David, Just to put your mind at rest. EA already does use batch load queries for both model and diagram loading.
There are places where it doesn't, but I assure you. We are addressing them.
-
Wow! Quite a response! (Thanks to all who've contributed so far).
Anyway...
---
Aaron,
Thanks I'll check out the PDF. I can't quote figures off the top of my head but I'm confident our VPN is quick enough to not be the issue.
It's not like we're trying to do this over a 64k ISDN line - I've a feeling it's a 2 MB leased line. Having said that, I am concerned that traffic over that line gets prioritised so I'm looking into where in the priority list Oracle traffic sits.
I'm also sorry to say that Citrix just isn't going to happen for reasons of price, hassle and general inconvenience.
---
Dave_Bullet,
Thanks for your thorough insite into what happens when you open a model or diagram and your suggestion about SQL replication.
I was pondering a similar idea myself though we'd prefer to use Oracle - I'm sure it could be done the same - how often do you replicate your databases though?
---
Midnight,
I certainly will submit a bug report when I have more details (test results). Embarrassingly I have to admit I'm not 100% sure what version of EA the guys at the other end of the VPN are using - so maybe a simple upgrade will help speed things up.
I'm going to make sure they have the latest stable build and then run my tests. If it's still and issue I'll drop support an email.
---
Everyone else, one other work around I'm pondering is this...
We have a source control system that works well (enough) over the VPN.
So I'm thinking we could
1, Have a local EAP file and bind it to source control.
2, Distribute copies of the local EAP file to people at either end of the VPN.
The idea being the model and database are kept local to each set of users (hence EA works at normal speed) yet both models are kept in sync by virtue of the shared source control.
(That may have already been in the PDF I haven't read yet - appologies if it is).
Does anyone see any obvious issues with that idea?
Thanks again.
Chris.
-
Chris,
Source control configurations are not my strong point, so wait for others to chime in.
With the above caveat, take a moment to think through how your 'remote' users will work. If they work very independently, and 'own' a branch of the model (i.e. a package tree), then you might get better results by going the 'low-tech' route. Look up Controlled Packages in EA help.
David
-
Hi Chris,
I was pondering a similar idea myself though we'd prefer to use Oracle - I'm sure it could be done the same - how often do you replicate your databases though?
I can't comment on Orcale (never setup replication with it). For SQL Server we use merge replication. This is basically a near realtime replication option, where you have one publishing database and one or more subscribers. It isn't a master / slave thing. Changes at the subscriber will replicate up to the publisher. The reason for the publisher is that *if* there is a conflict, then the publisher will overwrite subscribers. This is unlikely and good in our scenario, otherwise you'd be left with manual merging to do (and who needs another manual maintenance task!).
Simon,
Thanks for the update. Good to hear you guys are working on it. Any idea on when you'll have it licked?
Cheers,
David.
-
One point to note with this issue; each DBMS has a different 'Load' on the network throughput. This difference can be significant when measuring the response from EA. I can only give a brief personal assessment of three of the main DBMS servers that EA supports, these are Oracle, SQL Server and MySQL.
MySQL did come out as the fastest due to a large difference in general network traffic between it and the slowest of these (not to be named).
So, if you are needing to use EA across a WAN, then do check to see that the DBMS used is lean in it's network throughput.
-
Source Control is a possibility, and it does target situations where a WAN is involved. The setup involves each user having a local copy of the model that is broken down into several granular sections.
Each of these sections are then commited to the version control repository and can be "checked out" for exclusive editing (other users may view the section, but are unable to edit them), and then checked back in to commit the changes made locally (after which another user is able to checkout the section for local editing).
Sections can be individual packages, or a hierachy of packages and communication time is reduced because the user works with a local copy of the repository (meaning ordinary use doesn't trigger calls over the WAN).
The disadvantage of course is the extra steps (and time) introduced in the workflow to checkout packages for editing and check them back in to commit the changes.
-
One more thing to consider when you do source control...
You should structure your projects so that individual users can work within a package tree. If you have a lot of horizontal package references - developers need to tweak stuff in different branches of the model - you are likely to run into locking conflicts. You will also have greater time overhead from multiple package checkouts.
-
Thanks Dermot,
However EA doesn't need to (and shouldn't) do 100 database selects for a diagram with 100 elements on it. This is what happens on MS SQL Server. I have a MySQL to try incase EA employs a DB factory and different flavours of RDBMS are handled differently.
Also note - my SQL Server test was on EA6.5 - I will profile EA7.1 to see if it still does that (but I would put money on it that it still does ;)
Cheers,
David.
-
Please let us know what you learn Dave.
This has been dogging us for a long time (as you know ever so well). I'm looking at a scenario where replication may be the only solution, but that does not make me happy.
[Perhaps we should discuss how replication works as EA and the schema have evolved, but on another channel.]
David
-
Regarding the configuration control. we work with a mesh of both DB and CC.
Our lan users us DB while our WAN users use CC. All of our packages in DB are also under CC and it works good, i thi we'll stick to it (also it allows to take work offline to our customer sites).
regarding:
Please note however EA is broken when it comes to diagram copy and paste as it does a "select *" and then crashes (due to the extra columns SQL Server adds to EA base tables to support replication).
This worries me very much, it isvery importnat that EA support replication. What does Sparx say about it?
For SQL Server we use merge replication. .
How does it work for you, did you have any special problems?
It is important inpout, thanks for sharing.
Martin
-
Hi Martin,
I remembered you asked me for a copy of the modified SQL Server base script to suit replication. I hope I sent it to you!
Our replication works ok. Key thing is to configure each SQL server where identity values are used (ie. t_object.object_id) to use non-overlapping ranges so you don't get primary key clashes on the merge (ie. users on different replicas create a new object at the same time). You configure this as part of the publication setup so that each subscriber gets issued a "chunk" of identity values. This is done on a per article (= table) basis.
I have not comprehensively tested all EA features to see what works / doesn't work on replication. ie. checking in and out of version control. I fear there will be a lot more things that dont work. To be fair to Sparx - SQL server replication isn't officially supported. I think for true global scalability - they will need to eventually in the product.
If there are any admins from some really large organisations - feel free to chime in here and tell us your deployment model and number of users.
David (Midnight) - Citrix seems to work ok - so that is another option to get your EA instance closer to your database for better performance. Other option is RDP / TSC for a small number of users.
Cheers,
DAvid.
-
Thanks, that is a good help [smiley=thumbsup.gif]
-
Both 7.0 (build 817) and 7.1 (build 827) perform a lot less queries to open a diagram than previous (ie. 6.5 and before) versions.
For example,
A diagram with 100+ elements generates 29 queries to the database to open and takes approx 8 seconds
A diagram with 3 elements generates 20 queries to the database to open and takes approx 2 seconds.
The above is to a SQL server literally in the next room (therefore low latency) - so would represent a best case scenario in our distributed user environment.
On the large diagram - EA does some processing (about 3 seconds worth) after the first 20 queries - something not done with the second diagram. Probably rendering the shapescript on the 100 elements in the diagram. I can accept that.
Opening a large model though is still painfully slow. Most of this is within EA not database queries. 93 are issued over the period of opening the model which takes a couple of minutes.
David.