nDiki : Referer

本サイトの Referer 統計復活

以前のサーバでは Apache で combined 形式のアクセスログをとっていて、Referer (リンク元)の統計をとっていたんだけれども、今のサーバでは Referer log が提供されていない (common 形式の提供)。

なもんで、しばらく Referer のない淋しい統計生活だったのであった。 で、今日 SSI でめでたく復活。 とりあえずちょちょっと作って実験中。 ログの出力を Apache の combined 形式と同じ形式にしたので、analog がそのまま使える(統計スクリプトの手間も省けるというもんだ)。 もっとも、combined に必要なフィールドの全ての情報が SSI では取得できない(ような)のでそこら辺は適当(適切)に埋めておいてある。

ついでに cookie による統計も実験してみようかなと思ったがサーバでは mod_usertrack が disable だった。 自前で cookie を焼くとなると、全ページを隠れCGI処理しなきゃならないので面倒だ(昔別のサーバ上でやってたけど)。 IMG でお茶を濁す方法もあるけど、なんなので cookie は見送り。

Referer チェック

AWStats だと (analog でもそうだが)各ページ毎の Referer が確認できないので、結局自前でちょちょっとスクリプトを作成。

Referer spam

うちも御多分に洩れず増えている。 リンク元表示とかやっていないのだが、AWStats をインストールした時のメモとかがあるせいなどからそれらのページにモリモリきているようだ。

さすがに気分が良くないので IP アドレスとかで弾くことにするか。 しかし deny のリストのメンテが面倒だなぁ。

[ DiKicker ] キーワードのハイライト表示

指定したキーワードに関する記事を表示する際、日記記事内のそのキーワードをハイライト表示するようにしてみた。 どのような文脈でそのキーワードが使われているか、さっと探せてすこしは便利かな?

配色によっては記事の中で目立ちすぎて読みにくくなりそうだからそこら辺は検討の余地あり。

Referer見て検索エンジンから飛んできた場合は、そのキーワードをハイライト表示するようにも以前からしたいと思っているんだけれど、こちらはまだ未実装。

[ DiKicker ] ロック獲得リトライをさらに減らす

相変わらずここ最近 www.naney.org の負荷が上がり気味。 今日は Referer spam の爆撃もきていた様子。

DiKicker の挙動やログを見ていて気がついたのだが、さばききれなくなるのはどうも記事更新チェックの時間が長いからのようだ。 排他ロック獲得ループの回数が今の設定でも長い。

どのみち負荷が高い場合は共有ロックの方が勝ち気味で、排他ロックできなくて終わることが多いはずなので、思いきってもっとリトライの回数を減らしておいた。

それとロック獲得ループの中で「結局ロックできなかった時」に余計に1回 sleep() していたのでこれを削除。

Referer spam は # がお好き?

Referer spam が相変わらずきている。 今まで個別に .htaccess で拒否している。

ところでログを見ていてしばらく前から気になっていたのだが、なぜだか知らないがうちにくる Referer spam は

 http://www.example.com/#

のような最後に # がついた(通常は送られてこない) Referer URL を送ってきている。

サヨウナラ。

 SetEnvIf Referer "http://[^/]+/#" denyreferer
 deny from env=denyreferer

サーバの負荷が高くなったら DiKicker が 503 を返して沈静化を待つようにした

www.naney.org を収容しているサーバの負荷が高い状態。

1. Referer spam 弾きを強化。
2. 1日半前ぐらいに1度リブートしたようで、Memcached が起動していなかったので起動。

という対処をしたけれどそれでもなかなか負荷が落ちつかない。

傾向としては SpeedyCGI のバックエンド側(speedy_backend)が MaxBackends まで起動して処理が追いつかないと、起動しているフロントエンド側 (speedy) がどんどん増えてしまうという状況のようだ。

DiKicker の高速化も順次着手しているのだけれど追いつきそうにもないので、loave average が高い時は頑張らずに無条件に 503 を返すように修正して対応(以前ハイパー日記システムの時にも同じことをした)。

本当は SpeedyCGI フロントエンドの数に応じて負荷の軽い処理に切り換える等工夫したいんだけれど、フロントエンドの数を取得する方法は簡単にはなさそうなんだよなあ。