QA Analytics is programmed to run well on common rental servers, however, you should consider well if you are using a CDN or installing on your company’s own server or a host server with a special configuration. The QA Analytics involves Ajax communication with the WordPress server to record data in real time. You should be aware of the specifications and, in some cases, you may need to change your server settings or refrain from using the plugin unfortunately.
Due to the convenience of real-time Ajax communication, special attention should be paid to the following points.
- PHP and WordPress versions
- PHP settings
- File creation
- PHP memory and database capacity relative to the number of accesses to your site
- CPU
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 Analytics performs the aggregate processing 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 visits, 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 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 an ordinal server. If ajax errors occur on the client side, it is safe to specify a post_max_size of 10MB or more.
– ‘memory_limit’ of 512MB or more is recommended.
QA Analytics has a large amount of data processing depending on the number of visits to your site. Memory size is also important to run at high speed, and we recommend a memory_limit of 512MB or more, especially for a site has many visitors. 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.
PHP memory-related errors looks like following. The size depends on the host server.
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in ・・・ on line 1078
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” and “{PLUGIN_DIR}/qahm-ajax.php”
QA Heatmap Analytics uses the standard WordPress ajax communication to store the data. Therefore, ‘admin-ajax.php’ and ‘qahm-ajax.php’ which is generally under “wp-content/plugins/qa-heatmap-analytics/” needs to be running correctly. You don’t need to worry about the standard Ajax communication of WordPress in general host 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.’
By default, ‘direct’ method is selected. Some might set other permissions, however, of these four, QA Analytics only supports “direct” method and “ftpext” method which writes via ftp. 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’ method 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 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 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 Analytics, when collecting event data on all pages, 100,000 PV will increase the data by about 100MB.
データの保存（場所と期間）についてはマニュアルをご覧頂ければと思いますが、DB容量は1GB以上を推奨しています。（DBとして保存できる容量の制限をかけている場合の注意事項です。起動するメモリサイズのことではありません。メモリサイズは任意ですが、MySQLのkey_buffer_sizeはメモリ全体の25%程度が一般的だと思います。）
CPU
QA 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.