QAアナリティクスは一般的なレンタルサーバーでうまく稼働するように設計されていますが、CDNを使っていたり、自社サーバーや特殊な設定が行われているレンタルサーバーに設置する場合は、QAアナリティクスの仕様（WordPressサーバーとAjax通信を行い、データをリアルタイムで記録する）をよく把握し、場合によっては設定を変更したり、使用を控えて頂く必要があります。
リアルタイムAjax通信やデータ処理の都合上、特に次の点に関して注意が必要です。
- PHPとWordPressのバージョン
- PHPの設定
- ファイル作成
- アクセス数に対する「メモリ」と「DBの容量」
- CPU
PHPとWordPressのバージョン
サーバーのPHPのバージョンが5.6以上。WordPressのバージョンが5.6以降をサポートしています。また推奨のサーバースペックとしてメモリは4GB以上搭載し、ハードディスクはSSDであることが望ましいです。
PHPの設定
max_exection_timeは240秒（4分）以上を推奨
QAアナリティクスは、バックグラウンドでサーバーに負荷をかけないように細切れで集計処理を行います。この集計処理は通常2分以内に終わるように設計していますが、やはりページ数が多かったりアクセス数が多い場合には、時間がかかり、最大10分間かかることを想定しています。
mixhostなどのレンタルサーバーはphp.iniで設定されているmax_exection_timeの初期値が30秒と短い場合があり、その場合は集計処理が完了しない可能性があり、不具合が発生する可能性があります。
max_exection_timeは240秒以上に設定頂くと安心です。
post_max_sizeは10MB以上が推奨
QAアナリティクスはajaxで表示データのやり取りを行います。基本的にダウンロード方向で容量が発生するので、post_max_sizeは各レンタルサーバーの標準値で稼働するはずですが、クライアント側でajaxエラーが発生する場合、post_max_sizeは10MB以上を指定頂くと安心です。
memory_limitは 1G（1024M）以上が推奨
QAアナリティクスは、アクセス数に応じてデータ処理量が大きくなります。高速で動くためにもメモリサイズは重要で、memory_limitは 1G（1024M）以上を推奨いたします。またメモリエラーが発生すると正常に稼働しなくなることもありますので、phpのメモリ関連のエラーが出ていないかは注意してご覧頂き、場合によってはサイズをより大きく設定してください。
php.iniで設定できるmemory_limitの表記ですが、サーバーによっては「G」単位に対応していないところもあるようです。よくご確認の上、設定してください。
なおPHPのメモリ関連のエラーは、サーバーのエラーログには下記のように記録されています。
※bytesサイズはサーバーにより異なります。
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in ・・・ on line {1078}
ファイル作成
QAアナリティクスはなるべく負荷を低くするように下記のように設計されています。
- リアルタイムのデータ保存はファイルシステムで行う
- DBへの集計処理は負荷の低い時間帯（夜間など）にcron（wp-cron）で行う
データファイルはajaxを用いて3秒程度の非同期通信でwp-content/の直下のqa-heatmap-analytics-dataにセキュリティに配慮した形で保存されます。従って、wp-content以下にウェブサーバーから書き込める必要があります。
admin-ajax.phpおよびPLUGIN_DIR/qahm-ajax.phpの許可
QAアナリティクスではWordPressの標準ajax通信を使ってデータを保存します。従って、admin-ajax.phpおよびPLUGIN_DIR（通常はwp-content/plugins/qa-heatmap-analytics/）の下にあるqahm-ajax.phpが正しく稼働する必要があります。一般的なレンタルサーバーではWordPressの標準のAjax通信は気にしなくても行えますが、もし特殊な設定でAjax通信を止めている場合は、通信可能な状態にして頂く必要があります。通信について詳しくはこちらをご覧ください。
サポートされるFS_METHODについて
WordPressには、FS_METHODと呼ばれるWordPressによるファイル書込をサポートする権限が4種類あります。
初期値では「direct」が選択されています。FS_METHODはwp-config.phpにて定義できます。
このFS_METHODを定義している場合、注意が必要です。
４種類のうち、QAアナリティクスでサポートされるのは、直接書込を行う「direct」および ftp経由で書込を行う「ftpext」のみです。その他の「ssh2」と「ftpsockets」についてはサポートされません。
▼参考
WordPressサポート wp-config.php の編集
下記はFS_METHODに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アナリティクスにとっては大変よくない状況となり、IO Waitが頻発してサーバーに多大な負荷をかけてしまいます。
メモリSwapはQAアナリティクスに関わらずユーザーに待ち時間を与えるので避けるべきであり、たとえばphp-fpmの同時起動数はメモリおよびCPUが潤沢でない限り、静的にした方が一般的にも安全で意味のある設定になります。
【参考サイト】
DBの容量
QAアナリティクスにおいて、全ページのヒートマップデータを取得した場合、10万PVで約100MBのデータが増えます。
データの保存（場所と期間）についてはマニュアルをご覧頂ければと思いますが、DB容量は1GB以上を推奨しています。（DBとして保存できる容量の制限をかけている場合の注意事項です。起動するメモリサイズのことではありません。メモリサイズは任意ですが、MySQLのkey_buffer_sizeはメモリ全体の25%程度が一般的だと思います。）
CPU
QAアナリティクスは1セッションあたりほぼ3秒ごとにAjax通信を行いながらデータを記録します。QAアナリティクスはWordPress公式プラグインのため、WordPress標準のAjax通信を使っていますが、このAjax通信は毎回WordPress全体のチェックが走るため一般的にCPU負荷がかかります。（具体的にはwp-loadの一連の処理が走ります）
一般的なレンタルサーバーの場合、コア数が多いCPUが割り当てられているので問題は発生しません。
しかしAWSなど専用サーバーで独自に構築されている場合、大量（1秒間50程度）の同時アクセスがあっても普段はキャッシュを使ってさばき、CPUなどは低スペックのままにされているケースがあります。
この場合、本来必要だったCPU負荷がかかりますので、CPUのパワー不足に陥ったり、CPUの稼働時間があがるため、AWSなどの料金が高くなる可能性があります。
この問題を避けるために、QAアナリティクスではサポートメニューを用意しております。不安な方はぜひご利用ください。