OpenClinica User Manual/Performance

The performance of OpenClinica as an application is dependent upon numerous software, load and hardware variables - those on the client's machine, in the network and on the server. This page is intended as a guide to where these issues can be explored.

The effect of CRF size

The speed of CRF pages can be affected by the number of fields in a section (also known as a tab or page). Long sections download slowly due to the fact that for each item in the active section, several pieces of javascript must be downloaded and parsed. If a CRF is split into two or more sections than this improves the loading speed of the CRF considerably.

The download speed of a large section can also be improved if a reverse proxy (see below) is used to compress the page.

The client machine

A client machine that is slow or that is running complex programs in parallel with the web browser can result in the web pages displaying slowly. The client machine's net connection may also be problematic if the machine if connected via an unstable wireless connection.

The network

The further the client machine is away from the server and the worse the network connection, the longer communication will take between the two, to transmit even small pages and simple graphics. Having the server halfway around the world from the client (e.g. a client in Australia and the server in the UK) can add 1/3rd of a second to communication time (that's 2/3rds second for a round trip).

The server

Server software

The server uses a number of pieces of software to respond to clients, which respond reasonably well in the default configuration, but can be optimised in different ways:

• OpenClinica
  • Recent versions of OpenClinica include performance optimisations, including '40% faster turn times' on an optimised system (read a related discussion)
  • OpenClinica has no configuration for performance optimisation (though there is a 'wishlist' for further improvements). If OpenClinica is running smoothly, the amount of time it spends writing data to the logs can be reduced. Warning: only do this when you experience no problems! In the datainfo.properties, under 11 - Logging configuration change the entry logLevel to logLevel = warn or for the brave among us to logLevel = error. As soon as anything unusual happens, changed it back to info.
• Tomcat - the OpenClinica documentation describes how to install Tomcat, which serves up web pages. Tomcat can be optimised:
  • See OpenClinica's optimisation instructions for Linux or for Windows
  • Compression (and SSL) can be enabled on Tomcat itself without using a reverse proxy
  • Other software can be used to augment Tomcat in at least a couple of ways:
    • Installing a reverse proxy such as Nginx (see Using Nginx as a secure reverse proxy for OpenClinica) to deal with SSL, content caching and compression.
    • Installing Tomcat/Apache's APR to speed up SSL.
• Database - for Postgresql see Optimising PostgreSQL. Alternatively, Oracle's docs have sections on optimisation

When a server is configured optimally (with sufficient memory allocated as in the references above), this thread suggests OpenClinica is primarily limited by the performance of Postgres' caching, and the speed of the processor it runs on. Further improvements might be gained by optimisations to OpenClinica itself.

Server hardware

Minimal

See the Compatibility and System Requirements section of the Download OpenClinica page in the OpenClinica documentation for basic hardware server requirements.

Working

OpenClinica have a page on Hardware & Software Stack Considerations that suggests a 'base configuration that works well' of: Quad Core Xeon Processor 2.0Ghz or better, 4 GB RAM, 4 x 73 GB HD. This is the same specification referred to in a mail in November 2011 by an OpenClinica employee on what he considered a 'a pretty nice setup to run OpenClinica on'. He highlighted the speed of the disk array as a key factor in performance.

Optimal

OpenClinica Optimized(tm) Hosting (Clinical Trials in the Cloud) is architected by Shaun Martin (see the press release), and uses Fusion-io's hybrid disk technology (see below) and multiple redundancy.

The theory

• Memory requirements: As of OpenClinica 3.1.x, Tomcat can use up to 2GB of RAM (see server software section above), a PostgreSQL database can use up to 2GB of RAM (see Optimising PostgreSQL) and Oracle's requirements vary.
• Disk space requirements: The space taken up by the application and PostgreSQL are around 1GB (Oracle's requirements will vary). Tomcat consumes about 400MB of disk space, and each Tomcat instance takes up around 100MB of space (assuming CRFs don't include uploaded file attachments). Java consumes about 250MB of space, and PostgreSQL 250MB of space. Actual data entry will increase usage, but as the data is generally text (except in the case of CRF file attachments), the space used is unlikely to be huge.
• Disk speed requirements: Faster disks, such as SSDs (solid state disks) and high speed hard disks will speed up the response times of PostgreSQL or Oracle.
  • For example, OpenClinica Optimized(tm) Hosting (Clinical Trials in the Cloud) uses Fusion-io's hybrid disk technology (SSDs in combination with regular hard disks) to improve database performance - 'data extracts run up to 10x faster'.
  • In a posting to the OpenClinica user list about testing SSDs, Michael Bluett reported that SSDs "didn't seem to give any benefit" on an optimised system, with Marco van Zwetselaar suggesting that this might be due to 'having plenty of memory (and allocating it to PostgreSQL), which would then mostly operate from its cache'.
  • In a posting to the OpenClinica user list about starting to use SSDs, Krister Kristianson reported faster performance, that 'What took up to 10 seconds now takes less than 1 second'.
  • When reporting a slow page in issuetracker, 'dannyl' reported a 2.5-3x speed increase, saying that the SSD 'has dropped response time to about 8-10s instead of 20-30s' (login required).
• Processor requirements: Faster processors with more cores will speed up the generation of pages by Tomcat, PostgreSQL and Oracle. If the server software is optimised and pages and data mostly served from cache, then a faster processor may be the best way to improve the server's contribution to the response time
• Separate web server and database server: Separating the database server (Postgresql/Oracle) from the webserver (Tomcat) may spread the load of the server if a single server is seen to be overloaded. But this separation introduces networking delays, which may outweigh the benefits if the webserver is frequently communicating with the database server. As a possible warning, a bug with version 3.1.2 (login required) describes a large number of queries to the database being made by tomcat.

Performance benchmarks

OpenClinica provide OpenClinica Performance Benchmarks(Link broken) to set your expectation of how fast an instance should respond in the real world. The article OpenClinica 3.1.3 Community Version – Performance Test on HDD vs. SSD from the OpenClinica Blog lists some performance benchmarks.

Measuring and analysing performance

Performance can be measured from the browser and remotely, highlighting the cause of any delay - is it processing on the server, or the speed of data from the server to the client?

• Browser add-ons can analyse the performance of a web site from a client's browser (as well as the performance of individual pages):

YSlow and Page Speed

• Sites such as webpagetest.org and tools.pingdom.com may be used to test the speed of your website from various points on the web.

Further reading

Web application optimization is a complex and almost open-ended topic (see [1]).