「Research Artisan Lite」というソフトウェアにハマっています。
私は以前から3年周期くらいでコードを読むほど熱中するソフトがあるのですが、
nicoCache以来の久しぶりに面白いソフトを見つけた感じです。
(ちなみにその前にハマったソフトはAsteriskでした)
で、このソフト(以下、アルチンと記載)。最大の特徴がユーザーの導線を完全に追えるんですね。
アナリティクスなど他の解析ソフトでは、統計的な解析を行うのに対して、
アルチンではユーザー個人の導線を追えます。
不動産屋のように100人に1人くらいが売買を行うような
特別なユーザーの操作を追いたい時にはアナリティクスでは不十分なわけです。
全体的な機能としてはコンバージョン設定できない、動的フィルタがかけられない、
カスタムレポートがかけないなどアナリティクスには全然及ばないので
アルチンのみを使用するのではなく、他の解析ツールと一書に使うと良いと思います。
また、機能以外の部分の不満では
どうもDB負荷を少なくしフロントの台数を多くして解析するような設計方針なのか
フロントの負荷が高くDBの負荷が異常に低いというバランスの悪い設計に見えます。
何となくですが色々な人の些末な要望を聞いているうちに、
より多くの人が使えなくなってしまったのではないか?というような印象をコードを読んでいて
思ってしまいました。
若干ではありますがコードを見ながら高速化出来る箇所を書いてみます。
高速化1:like 検索の削除
ResearchController.php:1160行目
このメソッドはフィルタ設定で記載したIPまたはリモートホストを
除外する設定なのですが、通常はIPのみで記載できるはずです。
また、Like検索をおこなっておりますが、
フィルタ設定に正確に記載すればLike検索は不要です。
修正前
private function _checkfilter($filters, $conditions) {
if (is_array($filters)) {
foreach ($filters as $filter) {
if (trim($filter) <> '') {
$conditions[0] .= ' AND (';
$conditions[0] .= ' remote_host NOT LIKE ?';
array_push($conditions, '%' . $filter . '%');
$conditions[0] .= ' AND';
$conditions[0] .= ' remote_addr NOT LIKE ?';
array_push($conditions, '%' . $filter . '%');
$conditions[0] .= ' )';
}
}
}
return $conditions;
}
修正後
private function _checkfilter($filters, $conditions) {
if (is_array($filters)) {
foreach ($filters as $filter) {
if (trim($filter) <> '') {
$conditions[0] .= ' AND (';
$conditions[0] .= ' remote_addr != ?';
array_push($conditions, $filter);
$conditions[0] .= ' )';
}
}
}
return $conditions;
}
高速化2:titleテーブルへの保存処理の削除
静的ページだったり、流入がオーガニックのみの方は削除しなくて良いと思います。
広告会社からの流入やだったり、動的ページが多いサイトの場合には、
URLのパターン分だけレコードが作成されてしまうため、このテーブルは無限に肥大化します。
動的サイトの場合にはほとんど意味のない情報になるため削除したほうが良いです。
Track.php 583行目
if ($trackInfo['url'] != $trackInfo['title'] && trim($trackInfo['title']) != '') {
$title = new Title();
$title->setIgnore(true);
$title->setValue('url', $trackInfo['url']);
$title->setValue('title', $trackInfo['title']);
$title->setValue('logtype', $trackInfo['logtype']);
$title->save();
}
高速化3:(計画中)DBに若干の負荷をかける作りへ変えたほうがいいと思われる
プログラムの中で最も低速な箇所がLog.php:66行目のfindSummaryである。
ここでは何とra_log_YYYYMMテーブルのデータを全件、全カラム読み出している。
普通に考えればインデックス張ってGroup by して集計して取ったほうが
phpで集計するよりも断然早いのだが・・・意図しているところは何だろうか。
予想だが、アクセス数が秒間1000を超えるようなサイトで使用されて
集計中にログの取りこぼしでも発生したのかな?
MyISAMだしログの件数によってはReadロックが大変なことになりそう。
InnoDBにして集計を試してみようかと思案中。
ただ、メタプログラムの箇所なので影響範囲がかなり広くなるので
改造するのは結構大変かもしれないと思った。
高速化は次回へと続く・・・