Is your archive slower than you would like it to be?

Here are some tips, and general directions for tuning the dcm4chee system.

Server(s)

If you want to install everything (database and dcm4chee) on one machine, it is good to have a lot of memory and processing power to satisfy the needs of the system. Volume, types of images, number of concurrent users (DICOM, HL7, and human), and throughput requirements all play into the hardware decision. In general it is a good idea to run the database and the dcm4chee system on separate machines in a production environment. There will be network overhead between the two servers, but the benefit lies in the dedication of appropriate memory, processors, and storage to each application (dcm4chee and database).

If the need arises (because of volume increases or requirements, etc.), you could have multiple application (dcm4chee) servers, accessing a single database server. See the Clustering page for more information on multi-server environments.

Storage

It's definitely a good idea to have separate storage areas for the system (dcm4chee application), the database, and the image (and other clinical) data. This reduces disk contention, and allows you to optimize the type of storage to the usage. The database can grow big (see below), but the true storage need is for the image (and other clinical) data. A single study or series can be many megabytes in size, with total storage reaching into the Gigabyte or even Terabyte range - depending on the type of data you are storing and how long it is retained. In addition, since this data is very sensitive, a redundant or fault tolerant storage architecture is recommended. Different types of storage (single disk, RAID, SAN, NAS, DAS, tape, DVD, etc.) has different qualities (speed, throughput, quality, redundancy, accessibility, etc.), and can all be highly tuned in many different ways. Determining storage requirements, and tuning the storage architecture of a production medical imaging system is not for the faint of heart (the same could be said of the database as well), and should be done by an expert. However, there are many good books and internet resources on determining and tuning storage architectures. Feel free to add your storage experiences and recommendations related to dcm4chee.

Network

The amount of data transferred between the machine and the rest of the world can be enormous. Don't rely on the fact you have Gb ethernet in the server. The traffic might be slowed elsewhere - in some 100Mb switch forgotten somewhere on the main data transfer path.

• Test the throughput of main communication channels - from modalities to the server and from server to workstations.

Database

The database tends to grow huge, possibly even growing infinitely. dcm4chee saves information about the data it stores in the database - most of the columns being varchars. For a server with tens of thousands of studies the size of the database can easily get close to 5-10GB! Database access speed is vital for fluent server operation. In addition, since this data is very sensitive, a redundant or fault tolerant storage architecture is recommended.

• Pay close attention to DB configuration and tuning instructions provided by the vendor of your DB and configure it for optimal performance for your hardware.
• Dedicating a machine for the DB might be a good idea for larger scale systems. This offloads the database processing to a separate CPU than the dcm4chee application.
• The database connections are managed by JBoss, are usually pooled, and are part of the server transaction management. You can speed things up by configuring the datasource corresponding to your DB in JBoss. See Installation notes to find out more about this, and consult the JBoss web site for information regarding Datasource configuration.
• Place the database file(s) on a fast, high capacity media.
• Optional, and only for the truly knowledgable: Optimize the DB schema to fit your needs. Some fields are defined as varchar(255) and might not need to be. The theory says that only significant information is stored, but it's usually not true - the db will keep some space reserved for updates. Many times varchar(32) or (64) will be enough for the data you're working with. Be absolutely sure about this though before modifying the dcm4chee schema! Non-default schema modifications will not be supported by the developers or community!

JBoss

dcm4chee is a J2EE application deployed within the JBoss Application Server. This means that it relies heavily on the JBoss EJB container, datasource management, JMS, connection pooling, among other JBoss services. Configuration of the datasource was mentioned before, however there's much more that can be configured with regards to the other items.

If you want to be sure you're getting maximum performance from the application server, you might have to dig into JBoss performance tunig.. One good step however is to give the server enough memory - see the Installation notes to see how. To find out more about JBoss tuning see JBoss wiki page on the topic. JBoss tuning (like database tuning) is an endeavor unto itself, and the JBoss website, wiki, and forums are the places to go for that type of information.

dcm4chee Application

There are many things you can configure for optimal performance. Here is an list of items to think about (note that this is not an exhaustive list):

• Need to talk about compression. That is a big item in the performance discussion.
• As mentioned above, configure the app to store data on another disk, preferably a RAID field with fast access and big capacity. Put the database there as well. This is done in FileSystemMgt service configuration.
• Limit logging level to Error (see Logging Configuration to find out how).
• Optimize Forwarding and other DICOM communication:
  • Note, that DICOM is generally an inefficient protocol. It takes quite a few handshakes to send or recieve a single study..
  • Use forwarding sparingly. Every location in your forward list means an association needs to be established and data transferred for every study recieved - every forward increases the time consumption for a single recieved study exponentially.
  • Configure the Move SCU Service retry intervals.
  • Try not to forward to an SCP that is frequently down. This will result in many retries, consume a lot of time (and resources), and hinder other forwarding rules from smooth operation.
• Limit the number of events logged by the Audt Record Repository service (see the AuditLogger MBean Service for more information).