アーカイブ: July 2006

restructuring akahuku plus #2

IE 版 について。

赤福プラスというツールがあって、任意のサイトを見たとき、任意のスクリプトを実行するというブラウザのギミックの上に成り立っている。Opera ではユーザー javascript という機能があるのでそれを利用する。

IE にはそういう機能はないので Proxomitron を併用する。Proxomitron で、虹裏の html に赤福プラスを読み込む script タグを埋め込む。また、送信フォームの固定は IE の DOCTYPE スイッチが Standards Mode じゃないと働かないので、そのための DOCTYPE 宣言も埋め込む。

Proxomitron 以外にも IE に擬似的にユーザー javascript 機能をもたらすソフトはあるんだけど、素の IE でしか機能しないとか、この DOCTYPE 宣言の埋め込み、あるいは document.compatMode の上書きというのはそもそも javascript ではできない(と思う)とかなので結局 Proxomitron 以外選択の余地がない。

でも、Proxomitron 自体が残念ながら開発が止まっているソフトだし、少なくともふたば上でだけでも、任意のスクリプトを Proxomitron なしに動かすことはできないのかしら……と思うわけよ!

restructuring akahuku plus

赤福プラスというツールがあるのだけど。

建て増し続けでソースが読みにくい上に中で何をしているのか本格的に忘れたので、少し書き直してみることにした。

monaca

というわけで、できた:
http://akahuku.dw.land.to/q/futaba.htm

軽いものなのか、そうではないのかをテストしたいのだけど、この dw.land.to サーバが、たくさんの人に共有されるものなので、そもそもあまり軽くないかも、とか。

最初 futabaplus.php というファイル名にしていたけど、ふたば外の人間が作ったものが futaba* を名乗るのはおこがましい気がしたので、別に何の脈絡も何もないけど monaca.php にした(んが、通常ページのトップは futaba.htm のままだったりする)。

A Daydream #6

#5 の続き。

そんなこんなをやってるうちに、(例によって)プロバイダ代を支払い忘れてネットが止まって 1 週間。こんなふうになりました:

  • MySQL をバックエンドに持つふたば系の画像掲示板
  • ログをテーブルとテキストファイルの両方に持つ
  • テキストファイルのログへは、POST されたレスの追記のみ行う(ので、軽い、はず)
  • futaba.htm、1.htm ~ の更新はできるだけサボる(ので、軽い、はず)
  • カタログは html として吐き出し、更新はできるだけサボる(ので、軽い、はず)
  • 赤福プラス相当のスクリプトを標準で提供し、相応の機能追加と新着レスのみの取得が可能(なので、軽い、はず)
  • 赤福プラス相当のスクリプトを標準で提供し、レスの POST と POST 時点での新着レスの取得を 1 リクエストで行う(ので、軽い、はず)


逆にボトルネックになるかも? という点は
  • 連貼りチェックを確実に行うため、POST 処理を同時には 1 つずつしか行わない
  • レス送信モードが php ファイルの呼び出し(ただし、DB との接続やらログの再構成は一切行わず、単にその時点でのテキストログを吐き出すだけ)
  • 赤福プラス相当のスクリプトからの新着レスの取得は、php ファイルの呼び出し


ということで本当に軽くなっているのか、そろそろ適当なサーバに置いて試してみたいところ。

A Daydream #5

#4 の続き。

POST時の怠惰な更新
POSTで書き直す対象となる html は、

  1. レス送信モード
  2. 通常モード
  3. カタログモード

の 3 つとなります。

このうち 1 は、必ず POST ごとに書き直さなければいけません(実際は、独立させたレス部分のファイルへの追記のみ)。ただし、レス部分以外にも部分的にスレッドの状態によりリアルタイムで変化する個所があるので、多少の仕掛けはほどこすことになります(後述)。

2 はいわゆる futaba.htm、1.htm ~のやつで、これを POST ごとに書き直すのはけっこうなコストとなる。ということで適当にサボることを考えます。というか、虹裏ではすでにそういう処理が入っている、っぽい(レスしたときに「更新延期」と出ていれば、たぶん通常モードの書き直しはその POST 送信の時点では行われない)。

この更新延期という処理が具体的に何をしているのか? というのはよくわからなくて、通常モードの html を書き直す間隔として、たとえばファイルの最終更新時間からの経過秒数で判断するとか、あるいは決まったレス数ごとに行うとかをしているのだと思います。とまあ、虹裏での処理はわからないけど、とにかく、適当な間隔を空ければよいということです。

3 は、虹裏ではカタログは futaba.php?mode=cat という形で呼び出していて、つまりおそらくリクエストのたびに php が走って、DB を見に行って、html の中身を組み立てて……ということをやっている。これは明らかに高いコストなのであって、実際負荷のためにカタログモードをはずされた鯖もある。なので、カタログも html ファイルを書き出すようにして、通常モードの html を書き出すタイミングで一緒に作るようにすればよさそうです。

レス送信モードの構成
さてレス送信モードは、内部的な出力の単位で分けると

  • ヘッダ(これはつまり、html レベルでの head 要素までの部分)
  • 送信フォーム
  • スレの本文
  • レス群
  • 削除フォーム
  • フッタ

となる。このうち POST によって変化するのは(レスの削除を考えなければ)レス群への追記だけなので、内部的にもそういうつくりにしましょうよということなのですが、他にも一部、POST によって内容が変化しうる要素があって、

  • 送信フォーム:見ている人数が変化する
  • スレの本文:消える時刻、消滅警告の有無が変化する

現状の虹裏ではレス送信モードは基本的には静的な html ファイルであって、これらの情報の更新は POST されたタイミングで行われるのだけど、いま作ろうとしている掲示板では常に更新されるもの・されないものを分けて、レス送信モードはそれらを組み立てて返すことになるので、つまりレス送信モードは php スクリプトを呼び出し(xxx.php\?res=\d+ の形式になる)、リクエストごとに動的に生成する必要がある。

これによってパフォーマンスがどれくらい変化するのかはなんともいえないけど、せめてリクエストごとに DB を見に行ったりするような処理は避けたいところ。ということで、見ている人数を表すテキスト、スレの本文もテキストファイルに追い出し、本当に必要なタイミングで書き直せばよさそうです。

見ている人数は、モードに関わりなく板全体を通しての情報なので、futaba.htm の書き直しにあわせて更新すればよさそう。スレの本文は POST 処理内で(必要なら更新に適当な間隔を置きつつ)更新。

ということで、とりあえずスレを立てて通常モードを更新するところまで書いた。

A Daydream #4

A Daydream #1(futaba.php の流れを汲んだ上で、より軽い画像掲示板を作るにはどうすればよいかを考えてみる)の続き。

現状の futaba.php+MySQL のボトルネックが、レスの POST ごとに res/\d+\.html を1から書き直してるところにあるんじゃねえの!? と予想した上で、html ファイルのレス部分を独立させて POST 時はその独立させたテキストログにただ追記するようにしたらどうか、ということです。

DBとの兼ね合い
スレッドのレスをすべてテキストログに置くとなると、そもそも MySQL 使う意味は? となりえるが、以下の理由で不可欠:
  • 0~ページを再構成するために、スレッドの更新時間の逆順でソートした結果を得る必要がある
  • スレッドの寿命まわりを計算するために、最新のレス、最古のレス、最新のレスより n 行までの範囲からはみ出すレス群を得る必要がある
  • コメントの二重投稿、短い時間内の連続投稿を防ぐため、ログの全行から特定のコメントや投稿時刻を高速に抽出する必要がある
  • POST時の一連の処理をアトミックに行うために、トランザクションが必要である(後述)

な感じで、ぜんぶいかにも DB だなぁ~な処理です。

そういうわけで1つのレスを構成する要素(日時とか、ホストとか、コメントとかいろいろ)を DB 上のログとテキストログの両方に追記していく。無駄といえば無駄だけど、テキストログはクライアントが直接読むのを許可することを考えると、内部的な情報すべてひっくるめて持つ DB 上のログ、画面に現れる情報のみのテキストログと分けるのはまあまあ自然な成り行きだと思います。

ただ、そうするとおのおのの POST がオーバーラップしたとき、DB のログへの追記、テキストログへの追記が狂って順番を保証できない可能性がある(現状でも、レス番号と投稿時刻がクロスしたりする、あれ)。それはまずいので、POST 処理全体をトランザクションの中に置く必要があるわけです。あと、POST 処理がシーケンシャルになることで、連貼りのチェックなんかも正しく動き始める気がしないでもない。

レス送信モードの構造
レス送信モードのうちレス部分が独立することで、サーバ側でヘッダ・レス部分・フッタを構築して返す必要が出てくる。ということで、
  1. レス送信モードは xxx.php\?res=\d+ の形式に先祖がえり
  2. mod_rewrite が使えるなら、xxx.php\?res=\d+ な実体に res/\d+\.html のふりをさせる
  3. mod_layout が使えるなら、res/\d+\.html をテキストログそのものとし、別に用意したヘッダ・フッタを自動挿入してもらう

なんかのいずれかを選択することになるでしょう。3 が一番軽くなるかな? あんまり apache に依存するわけにもいかないなら別に 1、あるいは 1+2 でもいい。クライアント側で javascript が有効ならテキストログを直接読むので(後述)レス送信モードが単なる html ファイルか、php スクリプトかどうかはあまりパフォーマンスには影響しない(と思う)のでこれは単に好みで。

テキストログの差分読み込みとレスの削除
テキストログはクライアントに公開して、いわゆる赤福プラスの「続きを読む+読み込みを最小にする」をさせることが可能です。というか軽さを実現するために赤福プラス的な javascript は標準装備することになるのだけど。

このとき、レスが削除されたらどうするか。レスを削除されたらさすがにテキストログを1から書き直すことになるのだけど、そうすると差分読みするときのインデックスがずれてしまうわけね。これはテキストログの書き直しではなくて、該当レス部分を空白で(元のレスが占めていたバイト数分)上書き、なんかで逃げればいいかも。ログを見たら削除されたレスがあるようだなぁ~というのはバレちゃうけど。


ということでなんか書いてみます。これでレスの POST ごとに res/\d+\.html を1から書き直してるのが全然ボトルネックじゃなかったら目も当てられません!!

Sea Horse #2

と思ったけど、スクリプトが起動するタイミングがβ版と同じだったのでまだ保留。

プラグインの SDK 公開してください・・・。
Download Opera, the fastest and most secure browser
December 2010
S M T W T F S
November 2010January 2011
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31