wiki相談所 - 1310213661 - したらば掲示板

1：wiki管理人 ◆aRmzD8Jm32：2011/07/09(土) 21:14:21: ちょっと貸してね
79：名無しさん：2011/08/21(日) 17:31:31: とらっくばっくからきましたどこかのWeb_cacheつくってる人です。

CPU負荷対策ならConvert_Cacheが良いですよ。当方の環境では
サーバコンパネで確認していますがかなりの低減効果が有ります。

# デフォルトでONにしているが、Web_cache導入時に間違って
# 切ってしまった時に物凄くCPU負荷が上がった事を確認済
# 当方はさくらで運用しているが、コンパネでCPU負荷が分かる。
# CoreServerは以前使ってたが、PHPの負荷は表示されないので
# CPU負荷の厳密な検証は不可能に近い
# module版でなくcgi版PHPで動かせばCPU負荷も出るが、
# 後者は前者よりもCPU負荷が高いので本末転倒

Web_cacheも閲覧者のローカルキャッシュを利用するのでCPU負荷低減も
期待できますが、稀では有りますがサーバとブラウザの息が合わないと
キャッシュが効き過ぎる事があります。閲覧者の環境は多様なので
解決できない事も多いです。そこでCPU負荷はConvert_Cacheに丸投げし、
転送量問題をWeb_cacheとgzip圧縮転送で処理するという方針で当方の
管理下サイト(Oblivion, Fallout 3)は運営しています(それゆえ
Web_cacheの設定は弱めで実用上はキャッシュ効き杉って事は殆ど
発生しない筈)。サーバ側で処理すれば閲覧者側環境の影響は減らせますし。

Convert_Cache製作者サイトは消失していますが開設サイトや二次配布も
あった筈です。私は素のソースを持ってた筈なんですが、しまい込んで
どこにあるやら……。導入は初心者には面倒ですが頑張れば何とかなると
思います。入手解説ともにぐーぐる大先生に任せれば何とかなると思います。
LocalにApache導入して実験してみると良いかもしれません。面倒なら
XAMPPで一括導入とか。
ttp://ja.wikipedia.org/wiki/XAMPP

Wiki自体にキャッシュを組み込むのはConvert_Cache以外にもあった筈ですが、
それしか使ってないので他は挙げられません。申し訳ありません。。
Wikiの吐いているソースを拝見したが形跡が見られないので
Convert_Cache未導入と見ましたが、若し導入済みなら申し訳ありません。

以上、部外者ながら色々書かせていただきましたです。

追)
CoreServerは結構何でも出来ていいサーバなのですがサポートが致命的なので
かなり頑張らないといけないかもしれません。サーバ管理側でないと出来ないこと
すら出来ていませんでした。昔はまともだったのに。故に私はそこを止めたのでした。
ただ、最近GMOに買収されたので少しはましになるかもしれませんが。
何か有ったらblogのフォームからメッセージを頂けるとお返事できるかもです。
忙しいのでかなり反応鈍いですけど。
80：名無しさん：2011/08/21(日) 18:14:42: 書き漏らしたことを追加します。

CPU負荷
CPU負荷をおおよそ見積もりたいならばページの変換時間を見るのが手っ取り早いでしょう。
当方の管理下Wikiで恐縮ですが、
ttp://wiki.oblivion.z49.org/?FAQ%2FPC
の一番下の
HTML convert time: 0.005 ( 0.017 ) sec.
をご覧下さい。それぞれの数が動という細かい説明はおいておいて、ここが小さいほど
WikiソースからHTMLの変換が早い事を示します。ページが大きかったりサーバ能力が
低かったりするとここがすごい値になります。重いWikiだと10秒とかいう例を見た事有ります。

# 自分でチェックしたい場合はアホみたいにデカイ内容かつプラグイン機能使いまくりの
# ページを新規作成してみると良いかと。上のページのソースを使用すれば
# サーバ能力の違いも分かるでしょう

さて、試しに上のページを何も変更せず空更新してみるとこうなります
HTML convert time: 0.240 ( 0.253 ) sec.
10倍以上時間がかかっていますね？これはサーバ内のキャッシュがクリアされて
再生成されたからです(CoreServer時代は1秒台だった記憶があります)。時間で単純計算
するのはあまりに不正確ではありますが、Convert_CacheはCPU負荷を1/10に出来る
(かもしれない)というわけです。

このようにCPU負荷に限定するならConvert_Cacheはその殆どの問題を解決します。
苦労して導入する価値はあると思いますよ。Web_cacheなんて殆ど要らなくなる･･･筈です。

CPU負荷その2
サーバを二つ用意し、編集用Wikiと閲覧用Wikiの2本立てにする案もあります。
この場合、閲覧用はConvert_Cacheの一番設定の厳しいモードにすれば十分でしょう。
データの反映はwikiのログファイルだけを何らかの手段で定期的転送するのが良いでしょう。

# Coreはcron使えますが、色々制限も多いので管理人の自宅のPC上にwikiログをDL、
# それを閲覧サイトにUPってのが一番楽かも。多少面倒ですが自動化は可能かと。

この方法は編集用Wikiのアドレスを分かりにくくすれば簡易的なWiki spam対策にもなります。

# 悲しいことにWikiの編集者は閲覧者よりも極めて少ないのでこれで十分なspam対策になる

ただし、転送量問題が出てきた場合、閲覧用Wikiは複数必要になるかもしれません。

gzip転送
CoreServerを使っているそうなので基本的にこれはサーバ側デフォルトで行っている筈です。
なのでこれは気にする必要はないと思います。

転送量問題
Web_cacheを使っても駄目なら結構厳しいです。ミラーを(複数)建てるかローカル閲覧用の
変換済みデータを用意する方法も有ります(このデータの作成が多少めんどいのですよね、これが)。

この辺のノウハウはblogにまとめた……と思いきや各管理下Wikiに色々分散させて
書いたりしたので拾いにくいかもしれません。また、ローカル閲覧用データの作成や
ミラーの実際の具体的方法は私はどこにも書いて無いです。自分で書き捨てScript書いて
処理していたので…。その辺はお力になれなくてすみません。
このへんは(今は落ち着いていますけど)Ragnarok Online関連の職Wiki群が似たような事で
苦労しノウハウを蓄積しているので参考にしても良いかと思いますよ。