A Serena Software White Paper
Serena Dimensions CM
Scaling for the Enterprise
Manager Scalability Lab
Principal Product Architect
Serena Dimensions 10 is the industry’s leading end to end, process-centric Application Lifecycle Management
solution for distributed development. It integrates application development across global sites, stakeholders and
platforms, and automates development steps based on consistent processes to streamline delivery of the
applications that drive the business. Dimensions 10 is comprised of a suite of components that can be deployed
separately or in a single integrated fashion.
Dimensions CM is at the core of Dimensions 10, the industry’s leading software change and configuration
management solution. Dimensions CM seamlessly orchestrates application change and configuration across
platforms, locations, and teams. Dimensions CM delivers:
End-to-end traceability, from the inception of a project or issue through delivery of the functionality
Streamlined regulatory compliance though development lifecycle process definition and enforcement
Enhanced team productivity with an infrastructure that supports collaboration between co-located or
geographically distributed stakeholders
Visibility and control over project status, progress, and prioritization
This document describes the high-level architecture of Dimensions CM highlighting the major components of the
system and how to deploy them in an enterprise environment to ensure your Dimensions solution scales and
The following diagram gives a general overview of the tiers in the Dimensions CM architecture and which
components reside in each tier and how they connect:
As you can see Dimensions CM has an n-tier cross-platform architecture consisting of the following layers:
Business logic tier
The components in each of these tiers can be installed all on a single system or onto separate physical
machines. Because the components can be scaled horizontally (spread across a number of machines) to
expand capacity, Dimensions CM can grow to meet the needs of your enterprise.
The presentation tier consists of the clients that end-users will make use of to access the functionality of
Dimensions CM. There are a number of different clients to allow support for different platforms and access
Below is a detailed diagram of this tier.
The Desktop Client provides a rich Windows user interface built using the Microsoft Foundation Class
(MFC) library and other native Windows user interface technologies. This is a fully-featured client
providing access to all the end-user functionality of Dimensions CM. This client uses TCP/IP to
communicate over the network to the business logic tier.
The Project Merge Tool and Synchronize Wizard are also Windows Desktop Clients built using similar
Command Line (CLI)
The Command Line Interface (dmcli) is a small native component that can run on Unix and Windows
platforms and allows power users access to a flexible command line for the full Dimensions CM
functionality. This client also uses TCP/IP to communicate to the business logic tier.
Eclipse IDE Integration
Dimensions CM has a rich Eclipse plug-in that integrates the request and version management
functionality of Dimensions directly into the developers Eclipse workspace environment. This client
has been developed as an Eclipse Plug-in (see http://www.eclipse.org/articles/Article-Plug-in-
architecture/plugin_architecture.html for details). The plug-in uses TCP/IP to communicate to the
business logic tier.
Microsoft Visual Studio Integration
Similar to the Eclipse plug-in the Dimensions CM Visual Studio Integration allows access to request
and version management functionality from within the IDE. There are two pieces to this integration,
the version control aspects of the integration are implemented using a Microsoft Source Code
Control Interface (SCC) plug-in while the request management features are provided by a
separately installed plugin implemented using the Visual Studio Integration Program (VSIP) SDK. This
integration communicates to the business logic tier of Dimensions CM using TCP/IP.
The Administration Console provides a web-based front-end for performing tool administration and
configuration activities. See below for more detail on implementation technologies.
The Web Client provides a web-based interface to the end-user features of Dimensions CM. Both
this client and the Administration Console use the standard HTTP (or HTTPS) protocol to
communicate to a Web Application Container (aka servlet container) in the business logic tier. The
use of browser-based HTTP communication enables deployment of these clients across a wide
variety of platforms and network topologies.
Some use of a signed applet is made on the client side to present UI elements and interact with the
file system. Also optionally the user can choose to download some native code that allows file
In addition to those mentioned above there are many other clients for Dimensions CM including
integrations with other IDEs and 3 party products, the Dimensions z/OS clients. All of these clients
either use HTTP/HTTPS or use TCP/IP to communicate with the business logic tier in a similar way to
the clients listed above.
BUSINESS LOGIC TIER
Components within the business logic tier are server components responsible for carrying out Dimensions
operations on behalf of the clients (e.g. authenticating users, checking privileges/authorization, enforcing
process rules, maintaining metadata about products, projects, baselines, requests, and items under control).
These server components are supported on a wide variety of platforms including Windows, Linux and a
number of Unix platforms. See our web site or the Readme file for a list of the latest supported platforms.
Below is a detailed diagram of this tier.
Dimensions CM Server
The Dimensions CM Server component is where the main business logic of Dimensions is
performed. This component is implemented using a proprietary C/C++ application management
framework that provides high scalability and performance and has been proven in many enterprise
environments over the years.
There is a “listener” component (dmlsnr.exe) that simply monitors the health of the Dimensions
server and re-starts the server processes in the event of a failure giving the system maximum
The “listener” starts a “pool manager” process (dmpool.exe) whose main job is to manage a pool of
“application servers”. When a user is actively using a Dimensions CM client they are allocated a
process from the pool, when they become idle the process returns for the pool to become available
for other users. The initial, minimum and maximum size of the pool can be configured as can the
period of time that a client must be inactive for their application server to return to the pool. This
pooling architecture allows high scalability as many users can be connected to Dimensions but only
the active ones are taking up precious system resources.
The “application server” process (dmappsrv.exe) is where the main business logic for Dimensions is
performed; these processes connect to the database to perform metadata queries/updates and
communicate with the client. It is these processes that are “pooled”. When a user wants to
retrieve file content for an item revision it is also the job of the “application server” to communicate
via TCP/IP to the file/storage tier to retrieve the content from the file system.
On Unix platforms the “pool manager” process must be run as the privileged user account “root” so
that it can authenticate users credentials (access passwords and shadow password files) and run
processes as the client user (to access the file system on behalf of that user). For similar reasons on
Windows platforms the “pool manager” must be run as the Windows System account or an account
with similar access rights.
Web Application Container
The Web Application Container is a J2EE servlet container (such as Apache Tomcat); this component
deals with requests from the Administration Console, Web Client and Web Services clients.
Server Pages) technologies and their implementation follows a model 2 MVC (Model-View -
Controller) pattern to separate presentation, logic and content.
Most of the product’s business logic is implemented by the Dimensions CM Server; the servlet code
does not itself access the database directly, it communicates over TCP/IP to the Dimensions CM
Server to perform operations, query data, store/retrieve file content etc.
When the product is installed it is deployed and configured to run under Apache Tomcat but it can
also run under other supported Web Application Containers (see product release notes for details)
and the roles of the web server and servlet container can be separated, e.g. Microsoft IIS (Internet
Information Services) could be used as the web server and Tomcat for the servlet container. By
default the web applications are hosted by Tomcat on TCP/IP port number 8080 but again this is
Serena License Manager
The license manager is basically an extension of the Macrovision FlexLM licensing product; it
supports both concurrent and named user licensing models. In addition to the license server Serena
also provides a Java Swing based GUI to perform license administration activities.
When a connection is made from a client to the Dimensions CM Server the “pool manager” process
calls the license manager to obtain a license for the client. When the user exists his client or a
session timeout (configurable in length) occurs the license is returned. Communication between
the license manager and Dimensions server is via TCP/IP using Macrovisions own APIs and
Dimensions is a highly configurable tool with a rich set of relationships and properties of the assets being
managed, so to enable high performance and scalability Dimensions CM uses relational database technology
to store and query this metadata.
Below is a diagram of this tier.
As you can see, to support enterprises that have already made an investment in database technology
Dimensions supports multiple industry leading databases. For a list of the latest supported databases, check
our web site or the Readme file for the version you are evaluating. Depending on your choice of database the
Dimensions Application Server will use different network protocols and APIs to access the database. For
Oracle Dimensions uses the Oracle Call Interface API (OCI), for DB2 the DB2 CLI (Call Level Interface) is used
and for SQL Server Dimensions will use Open Database Connectivity (ODBC) APIs.
A single Dimensions server can connect to multiple database instances, within an instance there can be a
number of Dimensions CM base databases (for example perhaps one base database is used for your
production work and another one for testing), each of these has their own schema and there is also a single
common schema (referred to as PCMS_SYS) that stores some common metadata.
Tools are provided to carry out routine database maintenance and monitoring and documentation is provided
covering backup and recovery of the database.
In addition to managing the metadata about assets under control Dimensions CM also needs to securely
manage the content of the assets themselves (versions of your source code, documents etc). These file
storage/retrieval tasks are carried our by this tier in the architecture.
Below is a detailed diagram of this tier.
The only component in this tier is the Dimensions CM Agent, this is a group of components that interact with
the file system either to store/retrieve content in the item library (repository of versioned assets) or manage
content in a remote area (deployment area, work area).
The agent is similar in its architecture to the Dimensions CM Server in that there is a “listener” process which
ensures the server is healthy, a “pool manager” process to authenticate the user and allocate “library server”
processes. The “library server” process is the one that actually accesses the file system and communicates
back to the Dimensions CM Server or client via TCP/IP.
There are three primary uses for Dimensions Agent technology:
1. To host a Dimensions Item Library
When assets are checked-into Dimensions their content needs to be stored in a secure location (called
an Item Library). The machine hosting the item library must have a Dimensions CM server or agent
installed on it to interact with the file system to store the assets. Different item types can be placed in
different item library locations; these might be separate directories on disk but on the same machine or
you could even have separate physical machines hosting item libraries for different item types.
By default when an item library is accessed the “library server” process runs as SYSTEM on Windows and
root on Unix but this is configurable.
There are three options for storing the content of the files in the item library:
Content can be stored in flat files e.g. one file on disk for every revision of an item held in
Dimensions CM. This type of item library is referred to as a “normal” item library.
Content can be stored using delta storage where you get one file on disk per item and that one
file contains all revisions of the item (with only the differences between each revision being
stored). If disk space is a limiting factor for your Dimensions configuration then the use of deltas
would be helpful but otherwise we would recommend using flat files for storage (as described
Content can be stored in a compressed form. The content is stored in flat files e.g. one file on
disk for every revision of an item held in Dimensions CM but each of these files is compressed.
This type of item library is referred to as a “normal compressed” item library. Obviously if
compression is used there is some CPU overhead in uncompressing the data each time it is
2. To host a remote work/deployment area
For example a Dimensions user might be running Desktop Client on Windows but he actually does
mainframe software development so wants his assets checked-out and back-in to partitioned datasets
(PDS) on the mainframe MVS file system (rather than his local hard disk). In this situation the customer
would need a Dimensions CM Agent installed on the mainframe to interact with the mainframe system.
When a remote work area is accessed the “pool manager” on the CM agent node attempts to login using
the credentials you used to login to the Dimensions Server. If this fails it will prompt the end-user for
credentials to access that work area. Once a user has entered their credentials for a particular area they
are not prompted again unless they logout of their client or their session expires.
When a deployment area is accessed if the Dimensions CM administrator chose to store credentials for
that area then those credentials are used but if they were not stored then the user is prompted (just like
for work areas above).
3. To host an item library cache
To enhance performance across slow networks (for example across a high latency Wide Area Network)
Dimensions provides a unique caching feature (called an item library cache) that stores asset content at a
location nearer the user who needs that content. So instead of going over the WAN to obtain the
content it can instead be obtained directly from a cache on the same LAN as the user.
For example consider the scenario where a company has a data center somewhere in North America but
has some outsourced development occurring in India. The developers in India are using Dimensions CM
clients to connect over a high bandwidth high latency wide area network to the Dimensions CM server in
the data center. Without an item library cache when a client in India retrieves the content of a project
the file content will be sent over the low-speed WAN, despite Dimensions network optimizations such as
compression and only sending files that have changed if the project contains some large files or a very
high number of files then the fetch of the files will be slowed down by the network speed.
But imagine the developers in India install a Dimensions CM Agent on a host on the LAN in India and
configure an item library cache on that machine as shown in the diagram below:
Overnight they can schedule a job to populate the cache (download all their important/frequently
accessed project content). In the morning when developers start work if they have setup Dimensions to
make use of their locale cache then when they get project content it will not come over the WAN but
instead come from the local item library cache which is on their LAN so will be faster than obtaining the
content from the server.
When the developers in India create new file versions those must be transferred over the WAN to the
main item library (in North America). When those new versions are fetched to India the cache is also
updated so future fetches are optimized, in this way the cache grows as development is performed.
If any developers in North America access file content they would not have chosen the India library cache
so content would come directly across their LAN from the main Dimensions CM Agent hosting the item
Utilities are provided to purge or completely clean the item library cache to optimize the usage of disk
space on the cache machine.
The Dimensions CM Agent is used to manage the storage for an item library cache. When an item
library cache is defined in the Dimensions CM Administration console credentials are associated with
that cache area so when the “pool manager” needs to start a “library server” to access a cache area it
runs using those credentials.
Dimensions CM has broad platform support allowing the use of Windows, Linux, many flavors of Unix and
z/OS for the IBM Mainframe. See the Dimensions CM Readme document for further details on supported
APPLICATION PROGRAMMING INTERFACES (APIS)
Dimensions CM offers a number of publicly available supported APIs (Application Programming Interfaces)
allowing customers to create their own applications that make use of Dimensions functionality or to extend
the functionality of Dimensions CM.
A set of documented C functions and structures are provided along with examples and makefiles to
allow users to write C/C++ applications that can query Dimensions CM metadata and perform
Dimensions CM operations. This API is a cross-platform (supported on Windows, Linux and many
flavors of Unix) client API and uses TCP/IP to communicate to the Dimensions CM Server.
The Java API (referred to as dmclient) is a fully featured object-orientated API for accessing
Dimensions CM functionality. It comes with complete JavaDoc documentation, examples and is
documented in the Developer’s Reference guide. This API is cross-platform and uses TCP/IP to
communicate to the Dimensions CM Server.
A set of SOAP Web Services are provided with Dimensions CM to perform common Request
management operations. The Document Literal Wrapped style of WSDL declaration is used and the
WSDL is WS-I Basic 1.0 compliant.
In the diagram below a web service client is using some kind of SOAP Client API to send the SOAP
request over HTTP to the Web Application Container. This could be any SOAP 1.1 compliant client.
In the business logic tier the Dimensions Web Servcies are implemented using Apache AXIS so the
AXIS servlet receives the request and calls into the Dimensions CM web services code. The web
services call the Dimensions CM server using TCP/IP in the same way as the other Dimensions CM
In addition to using programmatic interfaces to access Dimensions CM metadata you can also use
standard SQL to access the database via a set of read-only published views. This allows customers
to write their own reports using Dimensions metadata or to perform complex queries perhaps as
part of an API program.
In the description of the tiers and components above it was noted that most of the components communicate
using TCP/IP, the messages sent over these connections are RPC (Remote Procedure Call) style messages, the
caller requests a particular function and sends a number of input parameters, then the other end responds
with some output parameters. We call this SDP (the Standard Dimensions Protocol).
The Dimensions CM Server and Agent components listen on TCP/IP port number 671 by default but this is
configurable. The TCP/IP connection is initiated from the client to the server so if you are configuring a
firewall on your network you will have to allow incoming connections on that port to the Dimensions server
and if needed also from the server to your Dimensions CM Agents.
When an RPC request or response is large it is automatically compressed by Dimensions to provide efficient
low-bandwidth delivery of data. When transferring files the file content is automatically compressed, and the
level of compression can be configured from the Administration Console. When transferring many files (for
example downloading the contents of a project) Dimensions CM will read the file content from the
file/storage tier into an in-memory buffer (configurable in size) in the server compressing the data as it goes
and then it delivers the compressed data buffer to the client. Also note that files are only transferred if they
have not changed since the client last obtained that file, this optimization along with the compression ensures
Dimensions CM performs exceptionally, even when over a slow Wide Area Network.
When communicating between tiers (across the network) Dimensions employs various strong encryption
technologies to ensure sensitive data is transmitted securely.
SSDP is the Secure Standard Dimensions Protocol and is identical to that described in the (Network
Protocols section above) but all data sent over the wire is SSL encrypted. If your Dimensions network
traffic travels over a public network link we would strongly recommend you configure Dimensions to
Encryption is provided using TLS version 3.1 using the following cipher suite:
The encryption is performed using the OpenSSL API (http://www.openssl.org). Diffie-Hellman key
agreement using ephemeral keying (key exchange via a temporary key) is employed to encrypt the
traffic using a customer provided certificate, we recommend a 1024 bit key but this is configurable by
your Dimensions Administrator.
Encryption of passwords
During authentication the client needs to send the password of the user to the Dimensions CM
server, even when you are not using SSDP or other encryption the password will still be encrypted.
The sensitive data is encrypted using a 64bit key based on the current system time and a hard-coded
1024bit seed generated by a PRNG (PseudoRandom Number Generator). This protects your
sensitive data from being easily discovered using a network packet sniffer, if further security is
needed we recommend enabling the SSDP protocol to SSL encrypt all traffic.
The Web Client and Administration console can be used over the industry standard HTTPS protocol
to encrypt all communication between the browser and the Web Application Container using
When using LDAP to authenticate user credentials Dimensions CM can support both LDAPS (LDAP
over a SSL tunnel) and LDAP with StartTLS extensions. Both of these security mechanisms encrypt
the LDAP communication using strong SSL/TLS encryption. Not all LDAP servers support both secure
protocols so choose the relevant one for your particular server.
Encryption of stored passwords
Passwords for a few key Dimensions user accounts must be stored on the Dimensions CM Server on
the file system (in a file located in dfs/registry.dat under your Dimensions CM Server installation root
folder). To ensure these are secure on Unix they are owned and only readable by root on Windows
you can secure these files after installation of Dimensions CM. In addition to file permissions this
information is also protected by encryption technology. The user names and passwords stored in this
file are encrypted using a 64 bit Blowfish (symmetric block cipher) encryption algorithm.
A utility called dmpasswd is provided to administer the accounts stored in this file.
The three accounts that are stored in this way are:
1. Dimensions Pool Manager:
The “application server” (dmappsrv.exe) processes running on the Dimensions Server are by default
all owned by a single user account (referred to as the pool manager). The “pool manager” needs to
know the password for this user to start these “application server” processes.
2. Database Schema:
Each Dimensions base database is itself a database schema, the schema username and password
need to be stored to allow Dimensions to connect to the schema.
3. LDAP bind user:
If you have configured Dimensions CM to use LDAP and are using a specific user account for
performing searches on the LDAP directory then their DN and password must be stored in this file.
Also if the Dimensions administrator has entered user credentials for a deployment area in the
Administration Console these will be stored using the same 64 bit Blowfish encryption scheme in the
database. These are stored in the administrative schema (PCMS_SYS).
When a user invokes a Dimensions CM client they must login before using the tool, a user name and password
must be provided. The Dimensions CM Server needs to validate the user name and password are correct and
it can be configured to do this using a number of different authentication systems.
Native OS Authentication
This is the default configuration for authentication and uses the servers native operating system
authentication mechanisms to validate the users credentials.
On Unix we use the POSIX standard getpwnam, getspnam and crypt functions to encrypt the
password provided by the client and compare it to the value stored in the systems password file. If
the values match then the user is successfully authenticated.
On Windows platforms we first query user account information using the NetGetUserInfo function
provided by the Microsoft Platform SDK. Which domain controller we query that information from
depends on how the system has been configured.
If a domain name was specified as part of the user name (e.g. mydomain\myuser) we query the
domain controller for that domain and call NetGetUserInfo against that domain controller.
If the Dimensions CM Server is configured to authenticate against a given domain name (using the
DM_LOGON_DOMAIN parameter) then we lookup the domain controller for that specific domain and
call NetGetUserInfo against that domain controller.
Finally if no domain was specified in the user name and no domain name has been configured we
query the primary domain controller for the Dimensions CM Server.
Having obtained account information we verify if the user’s password has expired and if necessary
allow them to change it. Once that is complete we call the Microsoft Win32 API function LogonUser
passing it the default logon provider and a logon type of LOGON32_LOGON_NETWORK.
If LogonUser succeeds then the user’s credentials have been validated successfully and they can
access Dimensions CM.
On a Dimensions z/OS agent machine the POSIX getpwnam and crypt functions are used just like on
Unix. These system calls will then authenticate users against your chosen security system (RACF,
Also note that on Unix you can run the command line client on the Dimensions CM Server (on the same
physical machine) and it will not enforce the entry of a user/password pair, it can use the credentials of the
already logged in user.
The Dimensions CM Server can be configured to authenticate users using a LDAP (Lightweight Directory
Access Protocol) server. Some examples of LDAP servers are Microsoft Active Directory Server, the Java
Directory Server from Sun Microsystems and the OpenLDAP directory server. Enterprise customers often use
these directory servers to centralize their user account information.
Dimensions uses the OpenLDAP API to communicate between the “pool manager” and the LDAP server. As
mentioned in the Security section above the Dimensions CM server can be configured to use
secure/encrypted versions of the LDAP protocol.
To authenticate using LDAP Dimensions CM needs to identify the DN (Distinguished Name) for the user and
“bind” to the LDAP directory server using that name and the provided password. LDAP is a highly
configurable directory server so Dimensions CM provides three ways of identifying the DN of user:
1. Search for a matching DN
This is probably the most common way of authenticating using LDAP, with this setup the Dimensions CM
Server searches the LDAP directory for a DN that has a particular attribute value then binds using that DN.
You need to configure a “bind user” which is the DN of a user who has authority to search the directory and
register their password using the dmpasswd utility. Dimensions CM will then “bind” initially as that user,
perform a search (from a given point in the LDAP directory tree) to find a DN where a specific attribute has
the value set to the name of the user logging into Dimensions and if a match is found Dimensions will “bind”
using that DN. If binding is successful then the user is authenticated successfully and can access Dimensions
2. Search anonymously for a matching DN
If you do not configure a bind user but you do configure Dimensions CM to perform an LDAP search then the
search will be performed anonymously. It will function as described above (searching for a matching DN and
then binding to it) but you will need to have anonymous searches enabled on your LDAP server.
3. Construct a specific DN
The final LDAP authentication option allows you to configure Dimensions CM to construct a specific DN
instead of searching to find one. You need to configure the “base” of the DN and an attribute to use as the
RDN (Relative Distinguished Name). Dimensions will form a DN by first specifying the RDN followed by the
user’s name, followed by the “base”. Dimensions then tries to “bind” to that DN using the password provided
when the user logged in. If binding is successful then the user is authenticated successfully and can access
On Solaris Dimensions CM also supports authentication using PAM (Pluggable Authentication Modules)
allowing many common authentication systems to be supported. The Dimensions CM PAM implementation
only support authentication modules that require user name and password only (e.g. the PAM LDAP module),
modules that require more data to authenticate the user are not supported.
When PAM authentication is configured the Dimensions “pool manager” component calls PAM APIs to
authenticate the user, passing in the user name and password when required. PAM will call whatever
authentication module has been configured for the Dimensions service (as configured in the /etc/pam.conf
file). Dimensions CM uses a PAM service name of “dimensions_cm” by default but this is configurable.
If the PAM conversation succeeds then the user is authenticated successfully and can access Dimensions CM.
Each Dimensions operation is controlled by a privilege; these privileges have a set of rules which (if met) grant
the user permission to carry out the operation. These privilege rules are very flexible allowing control over
who can do what based on the state of the object being operated upon, the groups the user is a member of,
the roles that the user holds etc.
In addition to the privilege other process rules are also evaluated to see if the operation can be performed.
For example you might have the “Relate Item to Request” privilege but you still cannot check-out files against
a change request if it is in the closed phase of its lifecycle.
Roles are an important aspect of the Dimensions CM authorization mechanism, roles can be used in
conjunction with privileges to control access to assets depending on which design part (functional area or
logical component of the system) that the asset belongs to. For example a piece of source code could be
owned by a design part called “GUI” and privileges could be configured so that only users who hold the
“developer” role on that part would be allowed to edit that code. They might hold the “developer” role on a
different part (e.g. Database) so they can edit “database” code but not GUI code. In this way you can break
you product/application up into areas and define roles/responsibilities for those areas.
See the Process Modeling User’s Guide for further details on how Dimensions privileges, users, design parts
and roles function.
There are a wide variety of configurations that are supported by Dimensions CM , especially when you factor in the
number of platforms that are supported. The next set of diagrams shows Dimensions CM deployed in a few
They show how the architecture that as been descried can be deployed onto physical systems. The components
are designed to be installed and configured easily. Once you have chosen to deploy your initial system, it is
possible to change and expand as your needs grow.
STANDALONE S ERVER
In this configuration the components from the lower three tiers of the Dimensions CM architecture (business logic,
database and storage tiers) are all hosted on a single physical server machine. This may work well if you have a
small user community or a powerful server machine.
In this configuration the database has been moved off onto a separate machine from the Dimensions CM server.
This spreads the CPU and RAM needs of the server components across the two machines allowing for better
performance and scalability.
The following configuration shows Dimensions CM usage spread across several geographically dispersed sites.
Users connect using Dimensions CM clients from India and England to a central Dimensions CM server in the
United States. In both India and England Dimensions CM Agents have been installed to act as item library caches
for those locations allowing the users to keep content they frequently access close to them.
As you have seen Serena Dimensions CM is architected to scale to a variety of Enterprise needs, but providing a
scalable environment for enterprise applications is complex. Dimensions CM is supported on a variety of platforms
and has many possible configurations. Many factors must be closely considered including network hardware and
software, WAN integration, server hardware and software, network load, server load, and more.
Prior to deploying Dimensions CM, these factors should be considered by your IT professionals and if needed with
advice from Serena Software Professional Services. Your data and usage models will need to be considered as
well when determining how to scale Dimensions CM to meet your needs. For example a heavy web user
population may need more Web Server resources where as heavy Desktop or IDE client population may require
additional CM servers.
Scaling up involves applying higher powered hardware on the Dimensions CM server. This
can involve faster CPUs, multiple CPUs, more memory, faster Network cards, or more likely,
some combination of all of these. Although the information shared in this section applies to
scaling up a system with the entire application installed on it, it is also applicable when
choosing to scale horizontally and should be considered there as well.
Depending on the operations being performed, the Dimensions CM server and the database
can be CPU intensive. When using multi-processor or hyperthreading configurations, the
server is able to use more system resources than under single processor configurations. In
memory intensive situations, the server may even consume all available memory. Having
two gigabytes of memory available per processor (virtual or physical) is a good general rule of thumb.
Choosing a 64bit platform over a 32bit platform will allow you to scale further vertically. It will be able to address
more memory and is capable of processing more per CPU cycle. Dimensions CM will take advantage of both faster
and additional processors and improve the performance.
Memory is important to scaling Dimensions CM. There are several processes that run and require memory and
making sure there is available memory when needed will allow you to scale further.
Dimensions CM Server memory
The CM Server can be scaled by adding memory. The processes of the CM server were described earlier. The
“application server” process’s (dmappsrv.exe) can be controlled in the listener.dat configuration file (see User
documentation for more details). Here you can control the number of active processes and how they startup.
One of these processes is needed by each active/concurrent connection you plan to support. Starting more
initially and leaving them running to service user connections will consume more memory, but will reduce the
amount of CPU and other processing activity involved in starting the process when they are not readily available.
For each active/concurrent user you plan to support, you can estimate using approximately 50MB for each. By
adding more memory on the CM server, you will find the ability to support additional “application server”
processes is increased and will allow your system to handle more user connections efficiently.
File Storage Server memory
The processes of the File Storage Tier were described earlier. The processes that perform the work for this layer
are “library server” process’s (dmlibsrv.exe). Generally there will be one process for each active file transfer (ie:
get, check in, check out,…). They are created for the duration of the operation and utilize approximately 20MB.
Adding additional memory to the system will allow more of these processes to run enabling additional file transfer
actives to take place.
Web Application Container memory
Our default installation installs a java based Web Application Container (Apache Tomcat). Adding more memory to
the Application server can improve your ability to scale vertically and support additional web clients. The amount
of memory that is used is controllable via configuration settings which can be located in our documentation. Since
we do also support other Web Application Containers as well, you should consult their documentation for details
on expanding memory if you are using one of those containers.
Database server memory
Making sure your database has ample memory is important for scaling your system. Simply adding more memory
may not necessarily allow the database to properly utilize it in all cases. We recommend that you consult your
database documentation for how to optimize the memory and configuration for the database you have chosen.
But as a general rule, for each additional active/concurrent process approximately 20MB is consumed. You should
consider the type of activities that your user population will be performing when sizing this area. For example if
you expect many people to be constantly running reports, you will want to make sure there is enough memory to
support those processes and the database is tuned properly to take advantage of it.
The disk subsystem in a single system configuration can also be used to get additional scalability. Generally the
faster the disks are, the faster your operations will be performed. If you have the ability to use multiple drives,
doing things such as separating the database data and the database logs on to separate physical drives (or
spindles) will allow the system to operate more efficiently. Having a separate drive for the Item Library location
will also allow the drives to function better in parallel. If possible place the operating system on a drive of its own.
The more you can reduce the contention for data access off the physical disk drive, the more scalable the
configuration will be. There are also techniques such as disk striping that can assist in increasing the throughput in
certain disk configurations.
In addition to the speed and configuration of the disk subsystem, additional performance can be gained from the
Item Library in the File Storage tier, but organizing your file types in to separate directories. When too many files
accumulate on the file system in a particular directory, it can impact the operating systems speed to serve up the
The systems’ networking is an important aspect of scaling. If the network card is saturated with network traffic in
your configuration, an additional network card can be used to help scale the application. Whether you are scaling
vertically or horizontally and are planning to support clients in a WAN environment, we suggest you consult our
“Optimizing WAN Development” guidelines document.
When it comes to achieving the highest levels of concurrency, scaling out horizontally becomes necessary. Simply
moving the components to separate machines is a great start when attempting to scale horizontally. Since the
Database and CM Server will most likely be contending for CPU, RAM and disk I/O, it is recommended that you
separate these pieces first.
When you begin to apply a horizontal scaling strategy, you will have further networking considerations. Consider
keeping the CM Server and DB Server on the same network subnet if possible. The closer in proximity the servers
the less impact you will see due to network traffic/delay.
To extend the capacity of the system you essentially have the option of doing some form of load separation and
Dynamic Load Balancing
The Web Application will be able to take advantage of a web farm that contains multiple Web Application
Containers (e.g. Tomcat) . The farm of Web Application Containers can be implemented using either hardware or
software. Hardware web farms require specialized hardware and skills to implement and tend to be more costly.
A software web farm can be implemented completely using Microsoft Windows 2003/2000 Server. The network
load balancing capabilities of Windows 2003 and Windows 2000 Server automatically distribute the load across
servers in the farm. In either type of Web Farm, the end user continues to access the system via a single URL and
is completely unaware of the Web Farm implementation.
Specifically the Web Application Container can be load balanced using usual techniques: DNS based (with the
known drawback of the DNS Caching mechanism) or Reverse Proxy based (whether using software techniques as
Squid Internet Object Cache, Netscape's or Microsoft's Proxy Server, and Sun's Netra Proxy Cache Server or using
hardware techniques as Cisco Systems' LocalDirector and Coyote Point Systems' Equalizer).
The Dimensions CM server can also be load balanced using a hardware load balancer that supports the use of
“server affinity” algorithms. A Dimensions client needs to connect to the same physical hardware for the
Dimensions Server after an "idle" time, this means that the client needs to communicate to the same IP address for
the server for the lifetime of its session.
If you wanted to expand the capacity of your CM servers to support additional IDE and Desktop clients and add
more capacity for your Browser based clients, your system deployment might look similar to this next diagram.
Dynamic load balancing
Static Load Balancing
The nice part about dynamic load balancing is that all the Web Farms are seen to the end users as a single system
even though they are made up of multiple systems. If you are not able to implement dynamic scaling, you can still
scale the deployment manually.
Each Dimensions CM Servers would be set-up and linked to the central database. Each Dimensions server will hold
part of the load of the users connecting to Dimensions. There will be no dynamic Load balancing happening and
you will have to define a set of fixed users to connect on each of the server that you will set up. You might do this
by instructing different departments of your organization to access one of the specific systems that had been
designated for them.
Depending on the bandwidth of your network and the organization of your projects it is even possible to set up the
Dimensions Server “locally” and connect to a central database located “remotely” that holds the entire
configuration Management Meta-data for your organization.
Dimensions CM performance/scalability can be most impacted by the following factors:
Server CPU speed
Serna Dimension CM Configuration
Network Configuration/Topology – Dimensions CM is distributed across the clients, Servers, and database server.
Consequently, network hardware and software configuration and capabilities have a significant impact on the
performance characteristics of Dimensions deployment. The closer in proximity on the network these pieces are
the better performance you will see. As a general rule of thumb, you should attempt to have your Servers and
Database tiers on the same network segment if possible.
Dimensions CM CPU speed – The server and database transactions can be CPU intensive. Faster CPUs translate
directly to improved server performance. Do not under invest in the quality and speed of the Server CPUs. The
more processes that are running on a single machine, the more the CPU demand will be once additional load is
Software Configuration – Dimensions CM’s configurability, while being one of the products greatest advantages,
can lead to performance issues if not implemented in accordance with best practices. Serena’s technical support
and professional services teams are well versed in these best practices and should be engaged to review
implementations and help diagnose performance issues.
Usage Model - Dimensions CM is used by each customer to solve different types of business problems. You can
imagine that there are many possible usage models and of course each one will utilize systems resources in a
unique way. Understanding the usage model for your user base will allow you to determine how to best scale the
servers to meet your companies needs.
A General Approach for considering your needs
When optimizing performance, focus first on getting servers with the fastest possible CPUs. Second, look closely at
memory utilization and insure there is enough. Then, consider multiple processor configurations. These principles
should be applied to servers when both scaling vertically and scaling horizontally. In the end, any single
Dimensions CM operation happens fastest when CPU speed, network bandwidth, and available memory are high.
Using the fastest possible CPU at the client, server, and database tiers result in the best end user experience.
The following chart illustrates scalability zones for Dimensions CM.
Dimensions CM Scalability Zones
In this chart there are four zones. Zone 1 represents low concurrency and simple configuration and usage
patterns. Zone 4 is highest end of the spectrum. It represents high concurrent user load and complex data and
This table can be used to determine appropriate server configurations based on usage patterns and expected
number of concurrent active users. The configuration recommendations are the results of analysis of data
collected as part of the rigorous Dimensions CM acceptance and certification process.
A concurrent user is defined by a user in the system who is actively performing work (e.g., two users refreshing
their workspace at the same time). More users can be logged into the system but are not considered concurrent
until they are performing some activity. With this definition you can determine your usage pattern and the
number of concurrent processes that you anticipate to consider a hardware configuration that might fit your
needs. If for example, if you want to support a population of 250 users and you believe at any one time you will
have 50 users performing moderate operations (submitting new requests, updating records, performing file
operations, etc…) then Zone 2 would be the starting point for the hardware you might consider. If you had a
1000+ user population to support, Zone 3 at 100 concurrent users might be appropriate for you.
Serena Dimensions CM has been architected, implemented and tested to meet the complexity and scalability
challenges of the enterprise. Its meta-data driven design provides extreme configurability and flexibility. Its open
architecture provides several solutions to enterprise data connectivity. And, by leveraging state-of-the-art
technology, Serena Dimensions CM provides a platform that will grow to meet the ever expanding needs of the