Optimizing TestRail installations
TestRail is already designed for high performance out of the box, but there are a few things you can do to optimize the performance of a TestRail installation. Some of these things are easier to implement (such as enabling HTTP compression or using a fast web browser). Other things such as using a dedicated application server or optimizing database performance is usually only needed for larger installations (100 users and more) or when you plan to make many concurrent requests.
This guide explains optimization techniques and recommends server specifications to get the best performance out of TestRail. The performance optimization tips and recommended settings are grouped into three sections below, namely hardware optimization, software settings and client machines. This guide also provides recommendations about using multiple server machines to host TestRail (for failover purposes or to increase performance).
Hardware optimization & specifications
For a standard TestRail installation, there's usually no need to use special server specifications or high-end hardware. For example, many teams install TestRail on a shared application server or in a virtual machine. But even if you don't plan to use a high-end server for TestRail, making sure that the server comes with reasonable modern hardware and with a reasonable amount of RAM is the first step for optimal performance.
However, when you plan to build a dedicated server for TestRail, and this is recommended for larger installations, there are a few things you can do to optimize performance when selecting the server components. Please note that your goal should be to optimize for all three common performance bottlenecks (CPU, RAM, I/O). It's usually a better idea to optimize all three components equally instead of concentrating on one component only. So instead of selecting the latest high-end CPUs and using less RAM, choosing a reasonable priced CPU and more RAM + a RAID card is usually a better idea for a TestRail application server.
- CPU: As TestRail can process multiple requests simultaneously and you usually host both the web server and database server on the same machine, TestRail will benefit from having multiple cores or CPUs in the server system. So using one or more modern CPUs with 4+ cores can be a good way to allow TestRail to handle many requests in parallel. If you plan to only serve a few requests at the same time (and this is usually the case for most TestRail installations that don't use the API excessively), going with less cores/CPUs and selecting faster CPUs instead is usually a better idea.
- RAM: The web server and application requires only a fair amount of RAM even for larger installations (as a general rule of thumb, 1-2GB for the system and ~100MB per simultaneous request is a good idea). The database, on the other hand, usually benefits a lot more from available RAM. Ideally the server can store the complete TestRail database in memory for fast database response times (please note that uploaded attachments, reports and screenshots are not stored in the database and can be ignored in this calculation). In our experience, having 8GB of RAM for the combined database and web server is usually a good number for larger installations. Make sure to follow the recommended database settings below to make use of the available RAM.
- I/O: TestRail is a very write-heavy application (as testers usually submit quite a few test results, add new cases, restructure test plans etc.), so the I/O (disk) performance is usually the biggest bottleneck. This is also the biggest drawback of using virtual machines to host applications, as the I/O performance suffers quite a bit under virtual machines. As a rule of thumb, using faster server disks (10K or 15K RPM drives) is a good idea. You can also test SSD drives or high-performance server flash IO cards to store the database. RAID cards and multiple disk drives can also be useful to improve the performance of the database. For best performance, using a RAID card with enabled write cache can boost the performance significantly. Important: only use such a setup together with a battery backed unit (BBU) and only use this if you have experience with such setups, as the write cache can lead to a corrupt database on power loss otherwise. It's still worth using a RAID write cache + BBU as it can boost the database performance significantly.
As TestRail is accessed over a network (either a LAN or over the Internet), having a fast connection to the TestRail server is assumed to achieve good performance.
Software settings & configurations
As TestRail is a PHP web application that stores its data in a database, you can optimize the performance on various levels and for different components such as the database, the web server or PHP. This section will explain and recommend a few settings that you can use to optimize the performance of TestRail installations.
Operating system & services
While we won't go into the detail of optimizing the operating system (you should obviously do this for any server), we can recommend an environment that we know TestRail will work well under. Please note that TestRail will work and perform well in both Linux and Windows environments, so if you prefer to use a Windows Server, this is also a very good choice.
If you don't prefer Windows over Linux and don't prefer a specific flavor of Linux, we generally recommend using Ubuntu 14.04 LTS with Apache and MySQL.
We recommend using PHP 5.5+ under both Linux and Windows as it comes with improved performance when compared to previous PHP versions.
MySQL InnoDB buffer
When you are using MySQL, it's important to change MySQL's default configuration, as the default configuration is usually optimized for databases of just a few MBs. The easiest way to optimize MySQL for larger databases that make heavy use of the InnoDB storage engines (which is the case with TestRail), is to assign a lot of memory to InnoDB's buffer pool. This way, MySQL can keep TestRail's database in memory and speed up the read queries significantly. You can configure the InnoDB buffer pool size by adding the following line to MySQL's config file (my.cnf, usually found under /etc/mysql or similar):
The above configuration line assigns 4GB of memory to the InnoDB buffer pool. In general, you should assign as much memory to the buffer pool as possible. On a dedicated TestRail machine with 8GB of memory, you can usually assign 4GB-6GB of memory to the InnoDB buffer pool.
Please note that it's not necessary to configure the buffer pool for a SQL Server database server, as SQL Server tries to allocate as much unused memory for its buffer pool as needed.
Enabling HTTP compression is an easy and effective way to improve the performance of web applications. Please read the following articles on how to enable HTTP compression for the various web servers:
PHP is an interpreted language and although it's quite fast, installing a PHP cache can be a good way to improve PHP's performance somewhat. Please note however that we've only tested TestRail with APC at this point (under Linux) and can only recommend this configuration at the moment. Installing APC can usually be done by using the distribution's package manager.
When installing and using TestRail on a Windows server, it's highly recommended to configure PHP and IIS to use FastCGI, as this provides the best performance and stability. It's also recommended to use a Non-Thread-Safe (NTS) version of PHP. When you follow the instructions in our installation guide to install PHP on Windows, you are already using the recommended setup.
Client software and settings
Even if your TestRail server is blazingly fast, using a slow web browser can slow down TestRail's user interface and load times significantly. Please see below for recommendations on how to optimize your client machines and/or web browsers for TestRail.
Web Browser Plugins
While usually not needed, TestRail can be used in a multi-server scenario. For example, you could use multiple web and database servers to balance the load between multiple machines. You could also use multiple servers to implement a failover mechanism for high-availability. We recommend that you contact us if you plan to implement such a scenario.