This article covers both physical and virtual machines. The three variables we will make recommendations about are memory, processors and hard drive space.

A common question that people new to iRise ask is "What should the size of my Definition Center be if I have X number of Authors and Y number of Reviewers?"
 
 The problem with the question is that the items are not directly correlated. The most important factors in determining the performance of a Definition Center are the number and complexity of the projects that will need to be accessed concurrently from the Definition Center. 100 Authors accessing a few medium sized projects will have a smaller impact on the Definition Center than will 20 Authors accessing 20 different large projects. Based on our experience with many customers over the years, we have come up with some ballpark estimates for server sizes based upon the number of Authors.
 
 These are not hard and fast numbers and you could find that your particular organization’s usage patterns do not fit the assumptions that lead to these numbers. Fortunately, changing the memory, disk size and processor capacity of servers in these days of virtual machines is easy. Use the numbers below as a starting point and assess the server performance periodically to see if performance matches predicted usage.

iRise projects are stored in linked xml files in the data directory and are loaded into memory when used either via the Studio client or when viewing the simulation in a browser. Multiple users share the same in memory representation of the project on a Definition Center when they access it concurrently. Also, the entire project is loaded into memory when needed, so large projects impact memory more than small projects do. Also, memory management techniques remove projects from memory when space is needed and they are not in active use. From the perspective of memory, the key metric is the number and complexity of projects needed in memory at any one given point in time. The iRise application tries to have commonly accessed projects in memory to improve performance, so the overall memory consumption of the application can look much larger than is actually being used. This article explains how to amend Definition Center memory.

To see how much memory the application is using at any one point in time, bring up Task Manager and switch to the Processes tab. Locate the tomcat7.exe process and look at the ‘Memory – Private Set’ column. You can add the additional columns to Task Manager for ‘Memory – Working Set’ , ‘Memory – Peak Working Set’, ‘Memory – Working Set Delta’. These will give you a snapshot of what memory the application is using at that point in time.

To see over time how the application is using memory and to see how frequently garbage collection is occurring you can examine the GC.log file (located on a default install in the x:\iRise\DefCenter\Tomcat\logs folder). The log file itself is pretty obtuse and difficult to understand, but freely available tools like GC Viewer will let you graphically view the contents of the log file. Also contact iRise Customer Support and we can help you view your log files and analyze memory usage.

An additional concern to keep in mind when using a virtual machine (either VMWare or Hyper-V) is that high memory Java applications are very sensitive to changes in memory. VMWare recommends reserving memory for a virtual machine matching the amount of memory the server believes it has (if you have told the OS it has 8GB, reserve 8GB for that instance). In Hyper-V you can do something similar by dedicating static memory to a given instance that matches the amount the instance believes itself to have. We highly recommend setting up virtual machines with either memory reservations or static memory to prevent any memory management related delays when using the application. See our article Best Practices for running Definition Center on a Virtual Machine for further details.

iRise projects are not stored in a traditional database. Project data is represented using a proprietary in-memory object data store that gets persisted to linked xml files. In addition to a binaries folder containing images and other static assests, two components of a project are persisted; a smaller working state of the project and a backup version, that if unmodified, contains all history for that project. Over time, a continuously modified project will end up with a very large backup or history file and may require pruning.
 
 It is a good idea to create a windows monitoring task to monitor the size of disk space available on the drive used for data storage and provide alerts when capacity reaches a certain size. The size of these backup files does not affect performance of the project, but if the data directory size gets too large other things can get impacted, for instance, nightly and weekly backups of the data directory can start to take a long time. Also backing up server data before upgrading can take a lot longer if the data directory is large. Contact iRise Customer Support for assistance pruning your data directory.

The iRise application makes use of multi-threading and benefits from multiple processors. If available it is a good idea to increase the number and speed of processors available on a given machine. After memory, this is the next most important factor in determining overall Definition Center performance.
 
 Here is a link to the installation guides for the different versions of iRise. Use these to find the minimum system requirements for a particular version.

Definition Center Operations Guide
Configuring Definition Center Memory