ER/Studio Enterprise Repository Database Sizing Guide

By: Gregory Keller

Abstract: Brief paper providing guidance on planning for the growth of Repo's database

This document is intended to serve as a hardware sizing guide for the ER/Studio. It covers the ER/Studio Repository application, the ER/Studio Repository database, the ER/Studio client, and the License Server. This information here supplements that in the ER/Studio Installation Guide and the ER/Studio help. The objective of this document is twofold: first, to provide a top-down sizing approach that is reliable and easy to follow; and second, to provide a conceptual basis for sizing ER/Studio and its associated software components.

ER/Studio Repository Hardware Configuration

Application Sizing:

  • CPU – the ER/Studio Repository is a single-threaded Windows application that does not benefit from having multiple CPU’s. For all but the smallest of implementations, it is recommended that a full CPU be dedicated to the Repository application. Having a dedicated machine (or partition) is not necessary, but is helpful, in the sense that it helps ensure that a full CPU worth of processing is available at all times. CPU speed has a significant bearing on Repository performance, hence a high-end CPU is recommended where possible.
    Recommendation: One (1) fast (2 GHz or higher) CPU
  • Memory – for small implementations, 512 MB of RAM may be sufficient, however this is typically not recommended. For medium-to-large implementations, 1 – 2 GB is best. The Repository application does benefit from added RAM, particularly for large installations.
    General Recommendation: 1 – 2 GB RAM (very large installations may benefit from even more)
  • Disk – 50 MB is generally sufficient for the application executables and logs. 100 MB is a more conservative (safer) estimate. This file system is not heavily used by the Repository application, hence it can (and typically does) reside on the local disk subsystem, versus an external array, though the latter works just as well.
    General Recommendation: 100 MB.

Database Sizing:

  • CPU – Due to the single-threaded nature of the Repository application, there is generally no benefit to allocating more than 1 CPU of processing power to the Repository database. The only exception would be the case where there is extensive direct access to the repository database for reporting. As with the application server, it is the availability of processing that is important. A dedicated server is not… though it is useful to note that there can be a measurable performance advantage to collocating the ER/Studio Repository application with its corresponding Repository database.
    General Recommendation: ½ to 1 CPU. (2-4 CPU’s in the rare cases where the customer engages in extensive reporting against the repository database)
  • Memory – The ER/Studio Repository is a transactional application that relies primarily on indexed access. Typically 512 MB – 1 GB of RAM is sufficient. One way to look at the memory sizing question is through an example: for a repository that takes 1 GB in index and data space, and where half the diagrams and dictionaries are accessed in one day, 512 MB will essentially allow a full day’s work to be kept in cache… which is rather generous.
    General Recommendation: 512 MB – 1 GB. (Or more for large installations that conduct extensive reporting)
  • Disk – 1 GB is a good starting point for a medium-sized ER/Studio installation. Large implementations—i.e. ones with many models, and extensive use of branching and named releases– may require several GB, though typically not more than 5 GB. The data files should be placed on a disk array (RAID 0+1, 5, etc.) to avoid IO bottlenecks, as well as for redundancy.
    General Recommendation: 512 MB small; 1 GB medium; 3 GB large, for data and index space.

Virtualization

Embarcadero does not explicitly support virtual implementations, however we have a number of successful examples inside and outside of Embarcadero, of ER/Studio repositories (and license servers) running within a VMWare environment. It is a fact of life that virtual configurations will carry both a CPU and a memory overhead. Embarcadero does not currently have any benchmarks available to quantify the virtualization overhead for ER/Studio on different virtualization platforms. Vendors generally have their own guidelines, and customers who make extensive use of virtualization will have probably made their own measurements.

Application, Database, and Desktop Location

Collocating the ER/Studio Repository application and the ER/Studio Repository database does enhance overall repository performance. In installations with stringent performance requirements, these components should be not merely in the same physical location (i.e. data center), but if possible on the same server.

Desktop performance is similarly dependent upon the latency and bandwidth of the network between the ER/Studio desktop and the ER/Studio Repository server.

Client Configuration

It is recommended that regular users of ER/Studio have at least 1 GB of RAM on their client machines. While 512 MB is enough to effectively navigate a typical diagram, users commonly like to have multiple models open at once (to say nothing of multiple applications!) Additionally, certain operations, such as Compare & Merge, can consume quite a lot of desktop memory, particularly when large models are being compared. Many repository activities require an implicit compare between the version of the model stored in the repository, and that which is on the desktop.

General Recommendation: 1 GB RAM

License Server

Floating-license implementations of ER/Studio use an additional software component called the Embarcadero License Server. This lightweight software package provides centralized management of shared ER/Studio licenses, as well as some reporting capabilities around license usage. The License Server can be installed on a separate server from the ER/Studio Repository. Commonly it is installed on the same server as the Repository. Overhead is not significant, except during very small windows where reports are being generated.

Additional References

The ER/Studio Install Guide provides further detail on sizing and configuration, including tables with bottom-up estimation guidelines, and matrices of supported platforms and minimum requirements for those platforms. Beyond what is noted therein, it is useful to know that branches take up approximately the same amount of space in the repository as the parent diagram, whereas named releases take up approximately 20 – 30% as much space as that of the diagram.

For implementations having more than 50 diagrams, it may be useful to supplement the top-down approach presented here with a more detailed bottom-up sizing, to arrive at a more accurate estimate for Repository database disk utilization. That said, it may be cheaper to simply allocate a few extra GB of disk than to conduct an extremely detailed analysis!



Server Response from: ETNASC01