Points to note when installing (especially on exclusive servers such as AWS)

QA Heatmap Analytics is designed to work well on standard rental servers, but if you want to install it on your own server or on a rental server with a special configuration, you need to understand the specifications of QA Heatmap Analytics and possibly change the configuration.

Particular attention should be paid to “versions of PHP and WordPress”, “PHP settings”, “file creation”, and “database capacity”.

Versions of PHP and WordPress

The server must support PHP version 5.6 or higher, and WordPress version 4.5 or higher. The recommended server specs are 4GB or more memory and SSD hard disk.

PHP Settings

– ‘max_exection_time’ should be at least 240 seconds (4 minutes).

QA Heatmap Analytics performs the aggregation process in small pieces so as not to overload the server in the background. This aggregation process is usually designed to be completed within 2 minutes, but if there are a large number of pages or accesses, it will take longer and we expect it to take up to 10 minutes.

The initial value of ‘max_exection_time’ set in php.ini may be as short as 30 seconds for some rental servers such as “mixhost”, in which case the aggregation process may not be completed and a problem may occur.

It is safe to set max_exection_time to 240 seconds or more.

– Recommended post_max_size is 10MB or more.

QA Heatmap Analytics uses ajax to exchange display data. Basically, since the capacity is generated in the download direction, post_max_size should work with the standard value of each rental server. If ajax errors occur on the client side, it is safe to specify a post_max_size of 10MB or more.

QA Heatmap Analytics has a large amount of data processing depending on the number of accesses. Memory size is also important to run at high speed, and we recommend a memory_limit of 256MB or more, especially for sites with more than 100,000 PV per month. Also, if memory errors occur, the system may not run properly, so please pay attention to see if there are any php memory related errors, and if so, set a larger size.

File creation

QA Heatmap Analytics is designed to be as low-impact as possible, as shown below.

  • Real-time data storage is done in the file system.
  • Aggregate processing to the DB is done by cron (wp-cron) during low-load times (e.g., nighttime).

The data files are stored in a secure manner in ‘qa-heatmap-analytics-data’ directly under ‘wp-content/’ using asynchronous communication in about 3 seconds using ajax. Therefore, it needs to be able to be written from the web server under ‘wp-content’.

– Permissions for admin-ajax.php

QA Heatmap Analytics uses the standard WordPress ajax communication to store the data. Therefore, ‘admin-ajax.php’ needs to be running correctly. You don’t need to worry about the standard Ajax communication of WordPress in general rental servers, however, if you have a special setting that stops Ajax communication, you will need to enable it. For more information , please see ‘About the communication done by QA Heatmap Analytics‘.

– About supported FS_METHOD

WordPress has four types of permissions that support file writing by WordPress, called “FS_METHOD”. FS_METHOD can be defined in ‘wp-config.php.’

Of these, only direct writing and ftpext writing via ftp are supported by QA Heatmap Analytics. By default, direct is selected. Other ssh2 and ftpsockets are not supported. The following is an example of defining ftpext. For more information, please read WordPress documentation.

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_USER', 'username' );
define( 'FTP_PASS', 'password' );
define( 'FTP_HOST', 'localhost' );
define( 'FTP_SSL', false );

The performance of ftpext is degraded compared to direct because it is done via ftp. For stable operation, it is recommended to enable direct writing from the web server as much as possible.

– About Memory and Swap

In a typical rental server, the number of php-fpm processes launched by the web server is static and limited. This is because the system cannot run more than the number of CPU cores.

In some rare cases, however, there are servers that are configured to launch processes dynamically depending on the number of concurrent connections. For example, in some WordPress installation packages such as kusanagi, the setting may be set to dynamic.

In this case, as the number of concurrent connections increases, the memory consumption increases and Swap may occur.

Swap causes IOWait, which is a very bad situation for QA Heatmap Analytics to do file writes, causing frequent IOWait and putting a lot of load on the server.

Memory Swap should be avoided as it causes user latency regardless of QA Heatmap Analytics. It is generally safer and more meaningful to set the number of concurrent php-fpm launches to static unless you have plenty of memory and CPU.

[Reference site]

Database Capacity

In QA Heatmap Analytics, if you get heatmap data for all pages, 100,000 PV will increase the data by about 100MB.

Please refer to the link for detailed specifications and how to set the data storage period. We recommend a database capacity of 1GB or more. (This is a precaution when you limit the amount of space that can be saved as a database. It does not refer to the memory size to boot. The memory size is arbitrary, but for MySQL, key_buffer_size is generally about 25% of the total memory.)


QA Heatmap Analytics records data with Ajax communication almost every 3 seconds per session. Since QA is an official WordPress plugin, it uses the standard WordPress Ajax communication, but this Ajax communication is generally CPU-intensive because it runs checks throughout WordPress every time.

In the case of a typical rental server, the problem will not occur because a CPU with a large number of cores is assigned.

However, if you have your own dedicated server such as AWS, in some cases, even if there are a large number of simultaneous accesses (about 50 per second), the cache is used usually to handle them, and the CPU and other devices are left at low specifications.

In this case, the CPU load that was originally required will be applied, which may result in CPU power shortage or higher CPU operating hours, and thus possibly higher AWS and other fees.

To avoid this problem, QA provides various support menus. If you have any concerns, please contact us and use our services.

Was this article helpful?

Related Articles