>>658

ふ〜ん、そんなのもあるんだね。
後でゆっくり読んでみるよ。

いいたかったのとはちょっと違う。

今は「 read.cgi がリクエストが来たら、各リクエストごとに dat から HTMLを生成している。」がいまの実装であっているかい?
違っていたら、この提案は意味なし。

read.cgi がファイルにアクセスして、HTML 生成をするのはかなりの作業だと思う。それを、一回毎に HTML を生成、破棄しいないでプロセスにキャシュしておくのはどうかというのが提案。
squid などで、試しているキャシュに似ている。

Apache が read.cgi を含むプロセスと、何らかの通信をするなどして、一つのプロセスが常駐する必要がある。
一段目のキャッシュとして malloc 等で割り当てたメモリに HTML を保存する。
そこに、URL が存在したら、それをそのまま socket に流す。

一段目のキャシュに無かったら、二段目だ。
こっちもハッシュの鍵はURL。
こっちでは、HTML ではなくて、生成圧縮済の HTML へのパス。
例えば、/var/tmp/read.cgi_cache_file。
これは、一段目のキャッシュが大きくなった時にファイルに書き込む。
IO が発生するが dat を読んで、HTML を作って、圧縮するよりは、速いはず。

二段目にも無かったら、dat を読むしか無いね。
HTML を作ったら今度は送信するだけでなく、一段目のキャッシュに保存。

しばらく経つと、キャッシュも大きくなるから、何らかの優先順位を決めて、一段目のは二段目に移動。
二段目のは削除。


キャッシュにハッシュ関数を使うってだけ。P2P のとは全くの別物。

仮定としては、メモリと /var/tmp (一時保存のHD)等は余裕があって、ユーザは書き込みよりも、読者の方が多い。
アクセスの多い板はある程度限られている。