TestRail is 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 are 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.
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 on 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 toward 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 reasonably priced CPU and more RAM + a RAID card is usually a better idea for a TestRail application server.
The following test statuses are available by default:
- 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 fewer cores/CPUs and selecting faster CPUs instead is usually a better idea.
- RAM: The web server and application require 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 16.04 LTS with Apache and MySQL.
We recommend using PHP 7.0+ 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):
innodb_buffer_pool_size=4096MBThe 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.
HTTP compression
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:
- Windows with IIS 6 (static + dynamic/application requests)
- Windows with IIS 7 (static + dynamic/application requests)
- Apache under Ubuntu/Debian
- Apache under Red Hat/CentOS
HTTP caching
It can also be useful to enable HTTP caching for static files such as stylesheets and JavaScript files. As TestRail uses unique URLs for each TestRail version (by appending the current build version to stylesheet and JavaScript requests), web browsers should also refresh those files when you update TestRail. Please note that it’s not recommended to enable (long) caching for image files, as TestRail doesn’t append a version-specific string to those requests.
PHP caching
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
Windows Configuration
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.
Hardware optimization & specifications
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
Modern web browsers are getting faster with every release, and especially the JavaScript engines get faster as web browser vendors invent new approaches and ways to execute scripts. That’s why it’s important to use a recent version of your web browser of choice. So Internet Explorer 9 is faster than IE 8 and IE 7. The same is true for Firefox 4.0 vs Firefox 3.x. We generally recommend using Google Chrome to access and use web applications, as it’s generally the fastest web browser.
Web Browser Plugins
We noticed that web browser can slow down significantly over time when you use specific web browser plugins. For example, debugging plugins such as FireBug or plugins such as NoScript or AdBlock can slow down JavaScript heavy applications. For best performance, you could consider using a different web browser for your general web surfing than you use to access web applications (e.g. using Firefox for surfing and Google Chrome for web applications).