関連キーワードをなんとかしようスレ
■ このスレッドは過去ログ倉庫に格納されています
read.cgiの片隅に表示されている関連キーワードを きちんとメンテナンスしてみようなスレッド。
お、スレ来ましたか。 先日管理人からお誘いがきたです。 もう一人、超強力な人(仮名)が呼ばれている様子。 >>1 スレ立て乙です. で,core 吐くのは何とかなったっぽいですが,Solaris の port_associate() / port_get() 前提に作ったのを FreeBSD の kevent() に対応させた(つもりの)部分の動きが相変わらず怪しいと......<crawld で,truss を使えるように(/proc をマウント?)してもらえると,デバッグがしやすいかなぁ,と...... Mozilla/5.0 (X11; U; SunOS i86pc; ja; rv:1.9a1) Gecko/20061128 Minefield/3.0a1 >>5 超強力な人だ。 これまでの経緯や進捗などについては、 帰宅後にでもここにぼちぼちと。 で、/proc を mount する作業についても、 帰宅後に進めるです。 ■ これまでのまとめ 2006年の4月頃、read.cgi の出力の上のほうに「関連キーワード」を 表示する機能を、管理人がつけました。 http://qb5.2ch.net/operate/kako/1145/11456/1145615267.html の 490- プログラムは管理人が作成したプロトタイプ版でした。 まずプロトタイプ版で動かし将来よくしていこう、という目論見だったようです。 http://qb5.2ch.net/operate/kako/1145/11456/1145615267.html の 496 現在でもこの機能は、一部サーバで動いています。 * 全サーバでの動作はさせていません(負荷問題) * 負荷軽減のため21時から2時まではリクエストの処理をしていません(同上) また、事情により最近立ったスレッドではこの機能は動いていないそうです(by 管理人) * キーワード【準備中】 になっているもの このような状況の中、管理人からSunOSさんと私に、 「これ、やってみませんかー」というオファーが来ました。 そして、相談の結果、オファーを受けてみることとしました。 ■ これまでにすすめたこと ・先日管理人・SunOSさん・私の3人でオフラインで会い、現在の状況の確認をしました。 (管理人が手ずからペンとスケッチブックを持ってきて、絵を描いて説明しました) ・このためのサーバを2台準備し、私がインフラ部分の基本環境を作りました。 p2.2ch.io と c2.2ch.io になります。 ・管理人が今日、このスレを立てました。 そんなわけで例によって、表でわいわいやっていくことになりました。 ・現在 SunOS さんが中身の開発をすすめているところです。 というわけでどんな構想で作っておられるか等については、 ぼちぼちとここでやっていくのがいいのかなと思います。 例によって今後進めていく作業者間の作業連絡等も、 表ででやれるところについては(パスワードとかセキュリティ関係じゃないものとか)、 ここでやっていけるといいのかなと。 こんなところで。 >>12 はい。 組むのはあまり戦力にならないので、 例によってインフラ整備系とかネットワーク系でがんがってみようかと。 SunOS さんからの依頼により、 [cp]2.2ch.io の libcurl を 7.16.0 に更新しました。 >>9-11 ,15 乙です. >>12-13 よろしくです. 構想については管理人さんから大枠が示されていまして シード: 取得する Web ページの URL を保持し,それをクローラに渡す ↓ クローラ: 渡された URL のコンテンツを取得する ↓ パーサ: コンテンツから特徴的なキーワードを抽出する ↓ インデクサ: URL とキーワードの対応テーブルを DB として保持する フロントエンドからは,まずそのスレに対応するキーワードデータがすでに DB に存在するか調べ, あればそのキーワードを使用し,なければシードに URL を渡して上記の処理を行う,と. で,/proc をマウントしてもらったおかげで truss が使えるようになり, かなりデバッグがやりやすくなりました.で,crawld(=クローラ)もだいぶ安定してきたかな. usage: crawld [-fh] [-b host] [-d datadir] [-i interval] [-o unixfile] [-p port] [-s statfile] [-u useragent] -b host: bind UDP socket to this host [0.0.0.0] -d datadir: directory for fetched files [/var/crawld] -f: run in foreground -h: this help -i interval: interval(sec) for a same host [3] -o unixfile: output filenames to this unix domain socket [none] -p port: bind UDP socket to this port [9606] -s statfile: dump statistics to statfile on SIGUSR1 [/dev/null] -u useragent: set User-Agent request header [none] シードからは,crawld が待ち受けしてる UDP ポートに URL を投げ入れると, そのページのコンテンツを取得しデータディレクトリ配下に格納します. crawl.pl という Perl スクリプトを使えば,コマンドラインから URL を渡せます. usage: crawl.pl URL [URL ...] or crawl.pl <file_of_URLs -o オプションを使うと,取得したコンテンツが格納されているファイル名を Unix ドメインソケット経由でパーサに渡すことができます. -i オプションのインターバルは同一ホストに対するもので,別ホストに対してはインターバル指定にかかわらず即時取得します. 2ch 限定で使う分には,とりあえずインターバルを 0 にしてもいいかもですが. 並列度は,URL をどんどん放り込めば,理論上は1プロセスあたりの fd 数の限界に達するまで増えて逝きます. ただし,同一ホストに対するリクエストは Keep-Alive を有効利用できるように直列化されます. んで,crawld の次はパーサになるわけですが......キーワードの妥当性チェックのために Google に問い合わせてヒット数で判断するということが言われてるのですが, 外部のサービスに依存する形になるのはちと危うさがあるかな,という懸念が個人的には...... クローリングしたデータから自前で単語のヒット数のようなデータを蓄積するとか, 自前で完結できる形でできないかなぁ,とも...... 自前で完結するとなると全体のデータの中の単語量を調べるってので、 なんとかなるかもかも。 でも、ある程度大きな規模のデータがないと 結果に偏りが出ると思います。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる