QA Heatmap Analyticsは一般的なレンタルサーバーでうまく稼働するように設計されていますが、自社サーバーや特殊な設定が行われているレンタルサーバーに設置する場合は、QA Heatmap Analyticsの仕様をよく把握し、場合によっては設定を変更する必要があります。
特に「PHPとWordPressのバージョン」と「PHPの設定」と「ファイル作成」と「DBの容量」に関して注意が必要です。
PHPとWordPressのバージョン
サーバーのPHPのバージョンが5.6以上。WordPressのバージョンが4.5以上をサポートしています。また推奨のサーバースペックとしてメモリは4GB以上搭載し、ハードディスクはSSDであることが望ましいです。
PHPの設定
max_exection_timeは240秒（4分）以上を推奨
QA Heatmap Analyticsは、バックグラウンドでサーバーに負荷をかけないように細切れで集計処理を行います。この集計処理は通常2分以内に終わるように設計していますが、やはりページ数が多かったりアクセス数が多い場合には、時間がかかり、最大10分間かかることを想定しています。
mixhostなどのレンタルサーバーはphp.iniで設定されているmax_exection_timeの初期値が30秒と短い場合があり、その場合は集計処理が完了しない可能性があり、不具合が発生する可能性があります。
max_exection_timeは240秒以上に設定頂くと安心です。
post_max_sizeは10MB以上が推奨
QA Heatmap Analyticsはajaxで表示データのやり取りを行います。基本的にダウンロード方向で容量が発生するので、post_max_sizeは各レンタルサーバーの標準値で稼働するはずですが、クライアント側でajaxエラーが発生する場合、post_max_sizeは10MB以上を指定頂くと安心です。
ファイル作成
QA Heatmap Analyticsはなるべく負荷を低くするように下記のように設計されています。
- リアルタイムのデータ保存はファイルシステムで行う
- DBへの集計処理は負荷の低い時間帯（夜間など）にcron（wp-cron）で行う
データファイルはajaxを用いて3秒程度の非同期通信でwp-content/の直下のqa-heatmap-analytics-dataにセキュリティに配慮した形で保存されます。従って、wp-content以下にウェブサーバーから書き込める必要があります。
admin-ajax.phpの許可
QA Heatmap AnalyticsではWordPressの標準ajax通信を使ってデータを保存します。従って、admin-ajax.phpが正しく稼働する必要があります。一般的なレンタルサーバーではWordPressの標準のAjax通信は気にしなくても行えますが、もし特殊な設定でAjax通信を止めている場合は、通信可能な状態にして頂く必要があります。通信について詳しくはこちらをご覧ください。
サポートされるFS_METHODについて
WordPressには、FS_METHODと呼ばれるWordPressによるファイル書込をサポートする権限が4種類あります。FS_METHODはwp-config.phpにて定義できます。
このうちQA Heatmap Analyticsでサポートされるのは、直接書込を行うdirectおよびftp経由で書込を行うftpextのみです。標準ではdirectが選択されています。その他のssh2とftpsocketsについてはサポートされません。下記はftpextを定義した例です。詳しくはこちらをご覧ください。
define( 'FS_METHOD', 'ftpext' );
define( 'FTP_USER', 'username' );
define( 'FTP_PASS', 'password' );
define( 'FTP_HOST', 'localhost' );
define( 'FTP_SSL', false );なおftpextについては、ftp経由になるため、どうしてもdirectに比べてパフォーマンスの劣化が見られます。安定稼働のためには、なるべくウェブサーバーからdirectで直接書込が行えるようにすることをおすすめします。
メモリとSwapについて
一般的なレンタルサーバーにおいては、ウェブサーバーから起動されるphp-fpmプロセスの数は静的（static）で制限がかかっています。CPUのコア数以上に稼働させることはできないからです。
しかし、まれに同時接続数によって動的（dynamic）にプロセスが起動する設定のサーバーがあります。たとえばkusanagiなどのWordPressのインストールパッケージにおいては、設定がdynamicになっていることがあります。
その場合、同時接続数が増えると、メモリの消費量が増え、Swapが発生することがあります。
SwapはIOWaitを発生させますので、ファイル書込を行うQA Heatmap Analyticsにとっては大変よくない状況となり、IO Waitが頻発してサーバーに多大な負荷をかけてしまいます。
メモリSwapはQA Heatmap Analyticsに関わらずユーザーに待ち時間を与えるので避けるべきであり、たとえばphp-fpmの同時起動数はメモリおよびCPUが潤沢でない限り、静的にした方が一般的にも安全で意味のある設定になります。
【参考サイト】
DBの容量
QA Heatmap Analyticsにおいて、全ページのヒートマップデータを取得した場合、10万PVで約100MBのデータが増えます。
詳しい仕様やデータ保存期間の設定方法はこちらをご覧頂ければと思いますが、DB容量は1GB以上を推奨しています。（DBとして保存できる容量の制限をかけている場合の注意事項です。起動するメモリサイズのことではありません。メモリサイズは任意ですが、MySQLのkey_buffer_sizeはメモリ全体の25%程度が一般的だと思います。）