Is your archive slower than you would like it to be?
Check following tips to see where the bottleneck of the system might be.
0. Server(s)
If you wan't one machine per server, you'll need a lot of memory (to satisfy the needs of db engine and jboss) and a big diskspace - tha amounts of data are big for most of medical data. One series can counsume even tens of megabytes, but even if it's not so and you're working with smaller data, you'll need a lot of space. It's definitely a good idea to have separate disc for the system and separate disc (field) for the data and the database.
1. Network
The amount of data transferred between the machine and the rest of the world is 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 main data transfer path.
- Test the throughput of main communication channels - from modalities to the server and from server to workstations.
2. Database
The database tends to grow huge. Dcm4chee stores necessary (and a littlebit more) information about data it stores in the database - most of them being varchars. For a server with tens of thousands of studies the size of the database can easily get close to 5-10GB! The database access speed is vital for fluent server operation.
- (optional): Optimize the db structure to fit your needs. Most of the fields are defined as varchar(255) and don't 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.
- Pay close attention to db configuration instructions provided by the vendor of your db and configure it for optimal performance for your hardware.
- Dedicating a special machine for the db might be a good idea for larger scale systems
- The database connections are managed by jboss and usually are pooled and 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.
- Place the database file(s) on high capacity disc/field
3. JBoss
Dcm4che is j2ee application deployed under jboss. Thet means it relies heavily on jboss ejb container, datasource access management and other jboss services. The configuration of datasource was mentioned before, however there's much more that can be configured about the ejb engine etc. If you want to be sure you're getting maximum, you might have to dig into jboss performance tunig.. One good step however is to give the server enough of memory - see Installation notes to see how.
To find out more about JBoss Tuning see JBossASTuningSlimingon JBoss wiki.
4. Application
There are many things you can configure for optimal performance. Among other things you can:
- 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 quite ineffective protocol. It takes quite a few handshakes to send or recieve a single study..
- Use forwarding sparingly. Every location in forward list means an association that needs to be estabilished and quite timeconsuming operation invocation per every study recieved - with every forward you double the time consumption for a single recieved study.
- Configure MoveSCU/SCP service (the MoveSCU/SCP MBean) retry intervals (see XMbeansto find out more).
- Never forward to location, that is often down. This will result in many retries and consume a lot of time and hinder other forwarding rules from smooth operation.
- Limit number of events logged by AudtRecord service (the AuditLogger MBean - see XMbeansto find out more)