cURL関数の説明をちょっと読んだら面白そうだったので、クローラーの取得部分を並列化してみました。
これで、単線だったローカル線がいきなり、複々線化してさらに高架も建設したような感じに成長。
気になる取得数は3000スレ/hourをもうすぐ超えるのではないかというほど。
同時処理数をあんまり多くするとセッションがドンドン食われるので、
その辺りは負荷と兼ね合うようHTTPの標準的な数値に調整。
これでクローラーのメジャーバージョンはv6になった。
# Blu-ray マイスター検定クイズでも95%を超えたので、
# マイスター認定証が貰えるらしい。 現在109人中 16位だそうで。
Windowsでは、Shift_JISによく似たCP932(MS932)という文字コードが用いられているわけですが、
CP932には存在している文字、記号がShift_JISには存在しない場合「?」に置き換えられて入力されます。
実は、過去ログ検索を作っているときに最初Shift_JISでテーブルを作っていたのですが、
これの影響で文字化けが起きていることが後で解りました。
CP932の文字をMySQLのテーブルに挿入する方法の一つに
テーブルの照会順序をutf8_unicode_ciに変えることがあり、
CP932に存在して、Shift_JISには存在しない文字、記号が扱えるようになります。
つまり、文字が存在しないならば、文字が存在する文字コードを使えば良いと言うことです。
すべてShift_JISのテーブルに以下のようなSQL文を実行すると盛大に文字化けしてしまうわけですが、
INSERT INTO `hogehoge` VALUES(“1″, “Right Triangle”, “⊿”);
CP932を扱う列をUTF8にして、以下のように書き直すことで文字化けを防ぐことが出来ます。
INSERT INTO `hogehoge` VALUES(“1″, “Right Triangle”, CONVERT(_cp932 “⊿” USING utf8));
まぁ、最初からUTF8にすれば良いってだけの話です。
最近、Googleを支える技術 とか、プラネットグーグルなんて本を読んでいるのですが、
スケールが大きすぎてどうも自分の所では規模も、技術も足りず、生かせそうに無い気がします。
さて、 XREA から色々な機能を自宅サーバーに移植したクローラーですが、
どうやら、順調に動いているようです。
あまたがボーっとしているときにはあまり重要なところをいじらない方が良いのだけれど、
ちょっと気になったことがあったので、クロールの調整をしてみました。
それと、以前からXREAでは使用していたディレクトリ名→サーバー名の解決をする関数を
自宅サーバー向けに書き直して、クローラーに組み込んでみました。
これで、いつサーバーが変わっても設定ファイルを書き直さなくて良いわけです。
変更前は1日に収集しているスレッド数が約8000スレッドほどだったのですが、
明日は一体どれくらいに増えるのか? 楽しみです。
昨日は、MySQLに貯まった重複データの掃除と、
自宅サーバーの調整を色々とやってみた。
重複データの削除は5分ぐらいで終わって、32件を削除した。
自宅サーバーの調整は、まず lighttpd の導入から始めて、
FastCGIのインストールと実際に使えるまでの設定。
これが結構すんなり入ってしまったので、過程をWikiにメモした。
後は、毎日行っているシステムのフルバックアップをより低負荷で行うために
新しい rsync のソースをダウンロードしてインストールした。
wget http://www.samba.org/ftp/rsync/rsync-3.0.4.tar.gz
tar zxvf rsync-3.0.4.tar.gz
cd rsync-3.0.4
./configure –prefix=/home/hoge
make
make install
これが速くて、17分で完了。
グラフで見る限りいつも40分ぐらい掛かってるみたいだし、随分と速くなった。
readc.cgiは描画関係はだいたい終わった。
コード自体はみやすくなったものの、最短時間は現行より速くない気がする。
ただ、平均時間は明らかに速くなっていて、殆ど0.3秒以内に処理が終わる。
今のコードの行数は840行。
どうにかして高速化出来ないかなぁ?
readc.cgi書き直しをチャッチャカ継続中。
コードの見直しで、今まで0.5秒掛かっていた処理が0.15秒になった。
といっても、MySQLやSQLiteとの連携を始めたら遅くなるのは目に見えているので、
この辺りはとりあえずファイルに出力して、定期でバッチ処理した方がよさそう。
正規表現はある時ばっさり削ったのであんまり使ってないし、
それほど高速化も見込めないけど、コードが見やすくなるのは気持ちが良い。
後は、生死判断を快適に行えるようにしないと。
ID抽出や、レストラッキング(ある書き込みについたレスを一気に抽出する機能)はかなり高速化できて、
謎の技術を使って1.6秒が0.16秒にすることが出来た。
あとWinbinderについて、ちょっと面白いことがわかった。
あんまり解説している日本語のサイトがないので、来年ぐらいまでに簡単に何か書くかも。
今日書いたコードは600行ぐらい。
処理部分で言うと、引数を判断して書き込みの描画を行う部分
(l50とか、100-とか、-200とか、100-200とか)
readc.cgiのクリーンアップを2時間ぐらいやっていたんだけど、コードが複雑すぎてすごい時間掛かりそう。
その場その場で1年以上継ぎ接ぎをしてきたからなんだけど、1から作るのもすごい大変。
特にファイル関連が複雑で、スレッドの生死判断、板名の抽出、スレッドの取得など
この辺りでコード全体の半分ぐらいを占めている。
一回、紙に書いて整理してから書かないと、また複雑になるだけだから
時間をかけてクリーンアップというか、1から作り直しなのでリメイクしていこうと思う。
ブレーカーが落ちてサーバーが止まってしまったので
fsckをかけてファイルシステムに不整合がないかチェックした。
開発中のクローラーの名前は「かざぐるま」に決定。
丸一日起動しっぱなしにしていたら、11,000スレも収集してた。
機能は前回からちょっとパワーアップして、更新の有無をチェックを付けた。
以下は、To Do
- (済) ファイルの格納先を設定ファイルで任意のフォルダ階層に出来るようにする。
- メモリ使用量の改善(現状ピークで8MB切る程度、アイドル時は1MBを切る)
さて、後は何を付けようかな?
一昨日書いたToDoはこんな感じだったんだけど、概ね消化することができた。
- 巡回スレッド数の設定 → 実装完了
- 取得する最低レス数の設定 → 設定部分は終了あとは実装だけ
- 定期実行 → 実装完了
作業を進めるに当たって、一つ問題があって、DOSプロンプトを消すことが出来ない状態。
つまり、ふたばブラウザの双助だったり、ニコニコ動画のローカルプロクシNicoCacheみたいな状況。
どうにかこれを打開できないか考えてみたのだけれど、WinBinderを使うとGUIウィンドウがハングするし
タスクトレイに入れられるらしいPHP-GTK2は、PHP5で動かない。
PHP CompilerというPHP5に対応したコンパイラも有るんだけれど、これはPHP-GTKのエラーが出て動かない。
うーん、どうしたものか。
ユーザー側でタスクトレイに入れるソフトを使うという手も有るけど…。
もうちょっと情報を集めてみよう。