Common topology performance notes

Each of the topologies discussed in this guide includes an Engineering Station node. It is assumed for this example that the Galaxy Repository also be located on this node.

However, the Galaxy Repository is not required to be running once the objects have been deployed. For example, the portable GR or the typical engineering station that needs to be re-imaged multiple times, making its availability intermittent. SQL Server can be shut down in these scenarios with minimal impact to the running system.

Installing the GR on a dedicated node has the following benefits:

• It separates the engineering station(s) from the running system.

• It prevents bulk operations (for example, a Galaxy load, mass import, change propagation, etc.) performed on the Galaxy Repository from impacting the running system. If the Galaxy Repository were running on a node where an AppEngine hosting other objects is also running, and a bulk operation was performed, they would compete for CPU resources. The competition could potentially result in scan over-runs or missed scans on the AppEngine. Separating these components prevents unnecessary disruptions in the running application.