Problems with SQL Server Data Model - Query timeout expired

[BruceTOGAF2]

Following disappointing poor performance of Sparx EA with an Oracle Sparx repository, I have done a DBMS to DBMS project transfer from Oracle to SQL Server. Sparx EA with our migrated SQL Server Sparx repository (development environment) works much faster than Oracle. I was conducting performance tests of 8 users of Sparx EA with SQL Server Sparx repository, when we experienced the following error messages.
•   Microsoft OLE DB Provider for SQL Server [-2147217871] Query timeout expired
•   Microsoft OLE DB Provider for SQL Server [-2147467259] [DBNETLIB][ConnectionWrite (send0).General network error. Check your network documentation'
•   ADODB.Recordset [-2146824584] Operation is not allowed when the object is closed.

I have been advised to locate the SQL Server DB Server and the Sparx Cloud Service server in the same sub-domain on the same router/switch, because the Sparx Cloud Service server will be making 100's to 1000's of requests and any network latency will dramatically impact overall performance. This was not relevant advice because I was the only tester using Sparx Cloud Service. I am planning to conduct more tests with all 8 testers using Sparx Cloud Service to access the SQL Server Sparx repository.

In the last 2 decades it has become normal practice for large organisations to locate DB Servers in managed data centres and to use managed cloud services. Our organisation cannot dictate that the SQL Server DB Server and the Sparx Cloud Service server are located in same sub-domain on the same router/switch, because we use DB Servers in managed data centres. I fear that Sparx EA really is not suited to this modern architecture. I welcome your views.

[qwerty]

You're probably using it over a WAN. There's some optimization for WAN usage build in. You might experiment with that.

q.

[Geert Bellekens]

You're probably using it over a WAN. There's some optimization for WAN usage build in. You might experiment with that.

q.

Cloud services are the next version of the old WAN optimizer.

I have a feeling you are really seeing a network issue rather than a performance issue.

We have good experience using some kind of terminal solution such as Microsoft RDP or Citrix.
No need to setup the whole cloud server (and no license fees for the cloud server) and much better performance.
And no need for local EA installations anymore.

It does have some downsides, but in general I would recommend this setup to most organisations.

Geert

[Glassboy]

I have been advised to locate the SQL Server DB Server and the Sparx Cloud Service server in the same sub-domain on the same router/switch, because the Sparx Cloud Service server will be making 100's to 1000's of requests and any network latency will dramatically impact overall performance. This was not relevant advice because I was the only tester using Sparx Cloud Service. I am planning to conduct more tests with all 8 testers using Sparx Cloud Service to access the SQL Server Sparx repository.

The term "subdomain" used here seems to be meaningless.  The cloud service and the back end database don't need to be on the same switch (god know's why they'd be connected directly to a router), but they should both be in the same physical data centre.  Putting them in separate physical sites would make no sense, either today or in yesteryear.