Performance experiences on using Pro Cloud Server

[Sjaak62]

Can anyone please share experiences with the Sparx Pro Cloud Server in combination with SQL Server? Currently we are using a PostgreSQL database in AWS as a repository with about 6 concurrent users. We currently experience a bad performance on this and want to assess whether another setup (Sparx Pro Cloud Server in combination with SQL Server) will help us out. We want to use Sparx EA client together with the Sparx Pro Cloud Server, we don't have the intent now to use the Web interface.
What other setups of Sparx are proven to have a good performance for 5-10 concurrent users on one repository?

[skiwi]

Works perfectly fine for us. We have always maintained out model in SQL server.

[Sunshine]

Remember the network plays a part in performance too. Used SQL server in many organizations and it usually performs well. Occasionally had performance issues with network.

[BobM]

Performance is great here
What version of procloud and client are you using (there have been some performance updates)

[Geert Bellekens]

The single key bottleneck for EA performance is the bandwidth/speed of the network connection between the EA client and the database.

The EA client is very chatty, and will execute hundreds of tiny queries per second to get it's information.

PCS somewhat mitigates the issue (presumably by grouping queries or something), but the best way to good good performance is to place the EA client as close to the database as you can.

I have a lot of clients who have installed the EA client on a server, and use something like Citrix or Remote Desktop (AVD, WVD, or whatever Microsoft calls it today) to stream the GUI to the users machine.
So now the EA client lives in the same datacenter as the database, with an optimal connection.

You can add PCS in the mix in this scenario, but you don't have to. (less moving parts => less worries)

Geert

[wivel]

I have had issues with PCS, mainly timeouts when trying to export the model to one of the available XML file formats. Issues that I didn't have when using a database connection on the same repository as the PCS one. Even when timeout was set to max.

 So, as Geert said, the less moving parts the better, and if you do not have a need for WebEA or integrations to other tools, there is no need for PCS.

Henrik

[Geert Bellekens]

I have had issues with PCS, mainly timeouts when trying to export the model to one of the available XML file formats. Issues that I didn't have when using a database connection on the same repository as the PCS one. Even when timeout was set to max.

 So, as Geert said, the less moving parts the better, and if you do not have a need for WebEA or integrations to other tools, there is no need for PCS.

Henrik

Even when you have PCS for WebEA, you can still connect directly to the dabase with the clients.

Geert

[BobM]

Even when you have PCS for WebEA, you can still connect directly to the dabase with the clients.
Geert

We do that in case of emergencies (for us PCS works great, and we do use WebEA)
The reason why we prefer the PCS connection is that it's simply shutting down a service when our DBA has to do maintenance on the database, when on direct connections they all need to be terminated individually.