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

1：wiki管理人 ◆aRmzD8Jm32：2011/07/09(土) 21:14:21: ちょっと貸してね
2：wiki管理人 ◆aRmzD8Jm32：2011/07/09(土) 21:17:55: 状況説明

1. 07/09 16:00頃にwikiがアクセス負荷のため鯖会社から一時利用停止
→「負荷軽減したら動かすよ、稼動後また負荷きたら契約解除もありえるよ」
2. 07/09 18:00頃に利用停止解除
3. 即メンテ画面に移行
4. どうやって負荷軽減しよう…

ちなみに３月頃にも負荷で一度止められてる
どちらも原因はトラフィックではなく鯖負荷
3：wiki管理人 ◆aRmzD8Jm32：2011/07/09(土) 21:20:55: 今考えてる案

まず静的HTML化して閲覧のみ復旧
その後早いうちにサーバー移転
4：名無しさん：2011/07/09(土) 21:26:18: wiki管理人が自宅鯖を作る
↓
誰からも文句言われなくなって俺たちハッピー！
5：名無しさん：2011/07/09(土) 21:36:24: >>4
割と深刻な問題だろうからそういう茶化さない方が…

とりあえず閲覧だけでも復旧出来るならその方向でお願いしたいです
自分の一存で決められる事でもないですけども
6：名無しさん：2011/07/09(土) 21:50:22: アフィとかミラーとか
7：名無しさん：2011/07/09(土) 22:01:03: ROのクエストwikiなんかはミラー化で4個ぐらいに分けてた気がする
中枢以外はリードオンリーでミラー化するのがいいと思う
トラフィックではなく鯖負荷とあるけど何か変なページあったっけ？
もしくはニコ生で最近配信多いからUUの数が増えてwiki見まくってる人が多いのかな
8：名無しさん：2011/07/09(土) 22:03:07: ミラーwikiとか一部の内容を分散するとかするのが無難な選択肢じゃね。
ミラーwiki何個かあれば負荷分散にも繋がるだろうし
9：wiki管理人 ◆aRmzD8Jm32：2011/07/09(土) 22:05:52: ミラーってバッチ処理かなんかで定期的に別鯖へコンテンツ転送するのかな？
複数サーバー用意するのが大変そうだよなー、うーん
10：名無しさん：2011/07/09(土) 22:06:05: トラフィック原因じゃないなら単純にユーザ増えてリクエストが多くなってるせいだろうから
管理人の手間が増えるけどミラーで分散が一番無難に思える
アフィは何故か拒否反応出る人いて荒れやすいから、
有料鯖に移行するならDonate受け付けた方がいいかもね
週末潰れてしまって大変だろうけど頑張ってください
11：名無しさん：2011/07/09(土) 22:08:00: アフィはほんと過剰反応するやつ湧くよなぁ。
そういうの全然無視できるっすってタイプならやっちゃっていいと思うけど
12：wiki管理人 ◆aRmzD8Jm32：2011/07/09(土) 22:08:53: 負荷の原因はpukiwikiの作りにあるみたいで
ページ内のプラグインの数だけphp呼ばれちゃうみたいなんだよね
１アクセスで複数の処理が走っちゃって負荷になるとか

Donateって寄付のこと？
善意でとはいえお金もらうのは気がひけちゃって…
アフィよりはいいのかなー
13：名無しさん：2011/07/09(土) 22:13:17: アフィなんて今時分かってるやつしか踏まないしいいんじゃないか
ってそういう問題じゃないか
14：名無しさん：2011/07/09(土) 22:16:25: とりあえず1.4.7みたいだから
「pukiwiki 負荷軽減」でぐぐると出てくる
「PukiWikiの負荷軽減・高速化 - heeha.ws::blog」
ttp://heeha.ws/cgi-bin/blog/archives/2008/07/pukiwiki.html
という所のやつを参考にしてやってみるとか？
既にいろいろ施しててこの警告が来たならミラーしかない気がする
15：名無しさん：2011/07/09(土) 22:16:26: やっぱあまり大きすぎるページがよくないんじゃ
ちょっと見づらくなるけどアイテム種類別は５つに分けるとか
16：名無しさん：2011/07/09(土) 22:18:30: donateは寄付のことだね
アフィ
メリット：管理者・利用者の内誰の懐も痛まない
デメリット：荒れやすい、広告うざい
寄付はその逆って感じかな
17：名無しさん：2011/07/09(土) 22:24:40: ttp://debian.fam.cx/experimental/index.php?namazuTamer%2FPukiWiki%2Fbodycache#q1144f48
bodycacheってプラグインどうなんかな
18：wiki管理人 ◆aRmzD8Jm32：2011/07/09(土) 22:25:38: >>14
ありがとちょっと見てみる

>>15
不便になるのは極力避けたいんだよね

とりあえずミラーは後回しにしてサーバーをいいとこに移転しようと思うけど
オススメのレンタルサーバーってある？
転送量は現状500GB/月くらい
19：wiki管理人 ◆aRmzD8Jm32：2011/07/09(土) 22:39:23: ちょいまとめ

今後の予定
1. サーバー移転＋wikiいじって負荷軽減
2. 負荷状況見てミラーサイト設置

欲しい情報
・おすすめレンタルサーバー
・pukiwikiの負荷軽減方法
・ミラーサイトの設置方法
20：名無しさん：2011/07/09(土) 22:54:57: ttp://z49.org/2010/02/16/364/
fo3、oblibion wiki管理人の人も転送量の関係で色々喋ってるから参考になるんじゃない
あとpuki wikiの転送量削減pluginを公開してるみたい
21：wiki管理人 ◆aRmzD8Jm32：2011/07/09(土) 23:02:08: おお状況が似てるから超参考になる！ありがとう！
22：名無しさん：2011/07/09(土) 23:15:30: ttp://www.coreserver.jp/
ここのCORE-Bで年間１万ちょいくらいだけどオススメ
23：wiki管理人 ◆aRmzD8Jm32：2011/07/09(土) 23:24:54: 情報どうも！
そこも見たんですが転送量制限超えちゃうんですよね
現状の転送量を考えるとCORE-Cでもそのうちオーバーしちゃいそうで
お試し期間があったので無難にさくらを申し込んでみました
24：名無しさん：2011/07/09(土) 23:49:22: ttp://www.ablenet.jp/rentalserver/hosting/petit.html
転送量無制限で年3,150円。その代わり容量は小さい。
AMAZONアフィリエイトの検索タブでも置いてサーバー代金協力お願いとか書いとけば余裕でペイできるはず。
自分は年間10,000円のプランが最安の時に使っていたけど特に問題はなかった。（転送量が落ち着いたのでその後変えたので現状はわからないけど
25：wiki管理人 ◆aRmzD8Jm32：2011/07/09(土) 23:54:13: いままでが4000円/年くらいのサーバーだったんだ
それで今回の負荷騒ぎなんでもっといいサーバーじゃないと難しいかも
ってことで>>20を参考に30000円/年のさくらサーバーにした

ファイル移行して動作確認まで済んだけど
教えてもらったいくつかの負荷軽減試してみるから公開は少し待ってね
この調子なら今夜中に復旧いけるかも
26：名無しさん：2011/07/10(日) 00:03:23: まずは一日のページビューを教えてください。
そうすれば、ページビュー＋Wikiサイトである旨をレンタルサーバ会社に伝えればある程度の負荷計算してくれるんで、それでかまわないか調べてもらうことができます。
そこで、あまりにも高額になるようであれば、レンタルサーバをあきらめ、本当に自宅鯖をする事になるかもめ？
27：wiki管理人 ◆aRmzD8Jm32：2011/07/10(日) 00:13:28: 統計でも公開してるけどwikiは70000～80000PV/日くらい
>>20のサイトの人は160000PV/日でさくらのビジネスプロでいけると判断したらしいから
１個下のビジネスならいけるだろうっていう適当な試算で決めちゃいました

ひとまずサーバーはこれでやってみるのでOKです
皆さんいろいろ情報ありがとう！

あとは>>14,17,20あたりを試してみる
>>14の静的化がうまくいったら負荷は超軽減されるはず
28：名無しさん：2011/07/10(日) 00:13:59: 自宅鯖にしても今はプロバイダ自体の上りのトラフィック制限結構きついんだよ。P2Pやらなにやらのせいで。
で、さくらサーバーって正気か…。そもそも何が問題かわかっていない？
29：wiki管理人 ◆aRmzD8Jm32：2011/07/10(日) 00:15:27: え、さくらってそんなに駄目なんすか…
30：名無しさん：2011/07/10(日) 00:18:23: レンタルサーバーにとって回線の使用が一番コストかかるわけで、大抵のとこはその辺りごまかして容量とかで宣伝するんよ。
まあ、普通のサイトだったら、倉庫利用とかじゃなければ転送量なんて問題にならないからいいんだけどね。
で、さくらサーバー調べたところ、案の定、転送量限界を明記していないところだし、またいつ止められてもおかしくない。
31：wiki管理人 ◆aRmzD8Jm32：2011/07/10(日) 00:25:10: 転送量は一応調べてあるよ！

ttp://spezum.biz/interview/sakura.html
【1日あたりの転送量制限】
・ビジネス 45GB/1日

公式の情報じゃないから保証はまったくないけれど
現状が20GB弱/日なんで目安としてみてもこれなら問題ないかなーと
32：名無しさん：2011/07/10(日) 00:27:11: 追記。
で、転送量の許容を数値で出してないところの何が問題かというと、
サーバーは個人個人で用意されるわけじゃなく、複数の人数が共同に使うのは当然だよね。
一人が多く転送量使ってて、他の人の回線を圧迫すると、
「お前のとこ回線使い過ぎだから制限するわ」と、503　Server Unavailableが頻発するようになる。
これはサーバーの値段とかじゃないよ。
自分も昔、２ｃｈ系派生のサイトをつくって転送量限界で困っていろいろ探したけど、
転送量無制限のところは事業用の巨大サーバーを除くと>>24くらいのところしかなかった。
33：名無しさん：2011/07/10(日) 00:28:36: まあさくら使うならそれでもいいか。関係ないわ。
34：名無しさん：2011/07/10(日) 00:33:35: >>27
静的化は難しいと思う
ls系が動作しないようなので、色々と上手く行かないところが出てくるはず
35：wiki管理人 ◆aRmzD8Jm32：2011/07/10(日) 00:49:49: >>33
いろいろ教えてくれてありがとう
現状のサーバーで転送量については何も言われなかったんでそんなに意識してなかったよ
>>20に転送量軽減のがあるみたいだからそれやってみてまずは様子見てみるよ

>>34
たしかに静的化うまくいかん！
時間かかりそうだから静的化はいろいろ試して後日にするかも
36：wiki管理人 ◆aRmzD8Jm32：2011/07/10(日) 01:11:58: サーバー移したらいきなりてんぽった…
大丈夫かなこれ…；；
37：名無しさん：2011/07/10(日) 01:23:15: さくらインターネットといえば社長が大の洋ゲー好きで
ダンジョンズ＆ドラゴンズオンライン
ロードオブザリングオンライン
を運営して大損害を出して社長を辞めさせられたとこですね
洋ゲーのwikiを置くにはピッタリのところじゃないでしょうか
38：wiki管理人 ◆aRmzD8Jm32：2011/07/10(日) 01:24:56: ちょっと503ひどすぎるんで他探します…
お試し期間あって良かった；；
39：名無しさん：2011/07/10(日) 01:37:40: さくらは昔は結構評判よかったけど最近は酷くなっちゃったのかな
40：wiki管理人 ◆aRmzD8Jm32：2011/07/10(日) 03:36:17: CORESERVERにしてみました！
41：wiki管理人 ◆aRmzD8Jm32：2011/07/10(日) 03:46:27: 本スレID変わってた
>>193は本人です念のため
wiki落ち着くまではここ利用させてもらいます
42：名無しさん：2011/07/10(日) 07:02:30: ロリポップにしときゃいいのに
43：wiki管理人 ◆aRmzD8Jm32：2011/07/10(日) 08:16:23: ロリポップって良いの？
なんとなくさくらと同じようなイメージだったんですが
もし今のとこだめだったら検討の対象にするかも

とはいえ今のところ順調です
ttp://loljp.net/
でそのまま新サーバーにアクセスされるように修正してみました
44：名無しさん：2011/07/10(日) 09:25:33: 開かないな。サーバー移転の設定って反映されるまで結構かかるよね。半日くらい？
45：名無しさん：2011/07/10(日) 10:31:31: 昨日の時点では飛ばされてたけど飛ばされなくなってるね
あとチャンプへのリンクが違ってトップに戻されてた
46：wiki管理人 ◆aRmzD8Jm32：2011/07/10(日) 11:29:10: 朝方にDNS書き換えて転送じゃなく直接新サーバーにアクセスするようにした
環境（プロバイダ）によっては少し繋がらなくなってるかもしれない
DNSが広まるまでには数日かかることもあるって聞いたことある

もし繋がらなかったらこっちから繋いでみてくれ
ttp://loljp.c3.coreserver.jp/wiki/
URLが異なるから>>45の言うようにチャンプ詳細へ飛ばないかもだけど
画面上部の「一覧」からなら見ることができるはず

不便かけてすまん
47：名無しさん：2011/07/10(日) 11:37:35: インターネットの仕組み上、しばらくドメインから開く開かない人が出るからその故を知らせたほうがいいかも？
サーバーURLも知らせてもいいかもね。
48：名無しさん：2011/07/10(日) 11:38:06: と、書いたら貼られていた
49：名無しさん：2011/07/10(日) 15:14:27: さくらでいきなり503出たってのがちょっと気になる
動作の分析してみたいんだけど
現状のファイル一式見せてもらうのって可能？
50：名無しさん：2011/07/10(日) 15:27:41: すげー今更な話だけど
mediawikiとかなら初めから静的なhtml吐いてくれるんだよな
pukiwikiって機能的にも動作的にもかなり微妙だと思うんだけど
どうしてこんな流行ってんだろ
51： ◆aRmzD8Jm32：2011/07/10(日) 15:39:23: 携帯から

>>49
可能です。むしろ見てもらってダメなとこ指摘してほしいです。
とはいえ全部あげるのもあれなんで必要なとこを指定してもらえれば。
lib, plugin, その他設定ファイルとかかな？
ただ調べてるとさくらの503はよくある話みたいですね…。

>>50
いやー元々自分のメモ帳がわりつもりだったんですよ。
wiki レンタルでぐぐって適当に選んだとこがpukiwikiだっただけで。
他のwikiにしたいんですが移行の手間や影響考えると難しいんですよね。
こういうコンテンツ置きたいな、って調べるたびにpukiwiki選んだことを後悔します…。
52： ◆aRmzD8Jm32：2011/07/10(日) 15:41:53: >>47
そこまで詳しいわけじゃないんでそうやって教えていただけると安心できますありがとう！
53：49：2011/07/10(日) 16:27:43: >>51
503出るの普通なんですか、それもすごい話だ…

そうですね、Lib, Plugin, *.ini.phpあたりで大丈夫かと思います
こっちで環境再現していろいろやってみます
dkdlpl-becauseleesin@yahoo.co.jpに投げてもらって良いでしょうか
54：wiki管理人 ◆aRmzD8Jm32：2011/07/10(日) 16:54:10: >>53
送ったよろしく！
いたずらに使わないでね信じてる
出来る範囲で良いので検証に飽きたら捨てちゃってください

さくらは本当にびっくりしました
>>30さんは正しかった
すぐに判明して良かったっちゃ良かったですが
55：wiki管理人 ◆aRmzD8Jm32：2011/07/11(月) 00:37:32: 負荷軽減のためキャッシュを強くした
更新した内容が反映されないときはCtrl+F5を押してみて
使いづらいようなら少し弱くする
56：名無しさん：2011/07/11(月) 00:50:01: おれの学生時代は完全にはなまるのかけうどんジャンキーと呼んで差し支えない生活でしたが
最近やっとてんぷらを一緒に買えるようになりました
あんだけ食ったのに未だに見ると入ってしまうのはなんか中毒性のある成分とかが入ってるに違いないです
気を付けてください
57：名無しさん：2011/07/11(月) 03:04:46: ttp://pukiwiki.sourceforge.jp/dev/?BugTrack%2F763#v626a5a4
ttp://pukiwiki.sourceforge.jp/?%E8%B3%AA%E5%95%8F%E7%AE%B14%2F516

レンタルサーバーだと実践できないのもあるけどここ辺りも読んどけば後々参考になるんじゃないかな？
58：wiki ◆aRmzD8Jm32：2011/07/11(月) 08:58:26: おー、ありがとうございます！参考にします！

後者を見てふと思ったんだけど携帯で見てる人っているんかな？
ということでアクセス統計を見てみました

1.　Internet Explorer　173,077　34.76%　
2.　Firefox　165,011　33.14%　
3.　Chrome　112,974　22.69%　
4.　Opera　19,566　3.93%　
5.　Safari　10,070　2.02%　
6.　Lunascape　9,080　1.82%　
7.　Android Browser　6,514　1.31%　
8.　Mozilla Compatible Agent　506　0.10%　
9.　Opera Mini　421　0.08%　
10.　Playstation 3　243　0.05%　

Androidが1%超とそこそこいるんですねー
iPhoneはSafariと混ざっちゃうのかな？

ってPS3…だと…
59：名無しさん：2011/07/11(月) 09:04:21: 僕のPSPがアップを始めたようです
60：名無しさん：2011/07/11(月) 09:17:34: それでも私はドリキャスでネットサーフィン続けるよ
61：wiki ◆aRmzD8Jm32：2011/07/11(月) 15:22:30: 試しにアフィ置いてみた
なんでアフィってこうイライラするんだろうな
最下部の消したほうがいいかな？
62：53：2011/07/11(月) 19:22:43: チャンプ一覧の一部とアカリページをローカルに再現して動き見てみたけど
文字列の置換処理に恐ろしく時間掛かってるね
これは確かにキャッシュ方面から攻めるのが正しそう

PHP本体に手を出せるならXCacheとかの導入が手っ取り早いかもしれない
こっちはWikiに機能入れる方向で考えて見ますわ
63：wiki管理人 ◆aRmzD8Jm32：2011/07/11(月) 21:23:52: おおー！わざわざ見てくれてありがとう！
PHP自体はいじれないんでXCacheとやらは対応できなそうです

明日になれば負荷やトラフィックの統計が出るはずですので
それを見て今後の対応を考えていこうと思います
感触から今の状況なら耐えれそうかなーと予想してます
（今後さらにアクセス増えたらわからないですが）
64：wiki管理人 ◆aRmzD8Jm32：2011/07/11(月) 21:34:38: アフィは今のところ邪魔という声はみないけれど
今の感じなら許容範囲って認識でいいのだろうか
ここの消せ！とかこっち置いたほうがいいよとかあれば
アドバイスいただけるととても助かります

ちなみに今Google Adsense?だかってのを使っています
他の種類のを追加するという予定は（訳がわからなくなりそうなので）ありません
65：wiki管理人 ◆aRmzD8Jm32：2011/07/12(火) 09:12:53: 落ち着いてきたのでひとまず移行完了とした
あとは状況みてちょこちょこ調整していきます
66：名無しさん：2011/07/12(火) 12:50:25: アフィ邪魔っつーかAddBlockいれてると見えないんで
どーせならamazonのほうがいいです
67：wiki管理人 ◆aRmzD8Jm32：2011/07/12(火) 14:53:30: 他にも何人かからamazon置けと言われたのでメニューのをamazonに変えてみました
このサーチのやつよく見るけどまったくもって使ったことないという

そろそろサーバーの負荷統計が出てくるのでそちらの対応を始めます
今のところ余裕があったのでキャッシュを少し弱めてみました
p_commentやinclude箇所の反映がされやすくなってるはずです
68：wiki管理人 ◆aRmzD8Jm32：2011/08/03(水) 00:22:36: 503について

・契約内容
> 転送量目安(月)　※1750GB
> ※1・・・規定転送量以上の場合で、かつ、サーバー全体で負荷がかかっている場合は単位時間あたりの量を調整させていただくことがあります。規定転送量までは無制限で、それ以上はベストエフォートとなります。

・wiki転送量
8/2 4360.97864 M バイト
8/1 4614.37 M バイト
7/31 4643.99738 M バイト

こんな感じなんでwikiのトラフィック負荷はほとんどない
にも関わらず503出まくりのこの状況なんで
共用回線使用している別のサーバーが負荷かけてるんじゃないかと推測

上記内容を7/29に問合せをしたけど返事無し
それ以降一日に2回はサーバー会社に問合せしてるんだがやっぱり返事無し
さっき詐欺じゃねえのかくらいの問合せをしてみたが効果あるかどうか
10月分まで契約しちゃってるんで極力今のところでどうにかしたいんだが
今の状態がまだ続くようじゃ意味ないんでまた移転せざるを得ないかも

移転先でまたこんなんなっちゃ意味ないんで
ある程度のサーバー負荷と上記の転送量の２～３倍は
耐えれるレンタルサーバーを誰か知ってたら教えて下さい
費用は5000円/月程度ならアフィのおかげでぎりぎりなんとかなりそうです

あと今使ってるCORE SERVERについて情報あったら教えていただけると助かる
wikiのサーバーはここ「www.c3.coreserver.jp」
移転すぐはそこそこ落ち着いてたのにがっかりだよもー…
69：wiki管理人 ◆aRmzD8Jm32：2011/08/03(水) 00:24:22: 一部見にくかったので訂正

契約内容
> 転送量目安(月)※　750GB
> ※1・・・規定転送量以上の場合で、かつ、サーバー全体で負荷がかかっている場合は単位時間あたりの量を調整させていただくことがあります。規定転送量までは無制限で、それ以上はベストエフォートとなります。

※１とくっついて1750GBになってた:p
70：名無しさん：2011/08/03(水) 00:29:56: 最近繋がりが悪いよね、色々大変かもしれないが頑張ってくれ
71：wiki管理人 ◆aRmzD8Jm32：2011/08/03(水) 20:53:30: 強く言ったおかげか今日の午前中にやっと回答がきました

サポートじゃわかんないから担当部門にふる
14日経過後も続くようならまた問合せしてね
それまではこれ以上催促しないでね

とのこと
ようやく対応を始めたようなのでしばらく様子見になります
今日も503は確認したけれど頻度は少し減ったかも？
私も常に監視してるわけじゃないのでひどいときあったら報告いただけると助かります
72：名無しさん：2011/08/09(火) 23:10:34: メンテ中だからかもしれないけどまだやっぱり頻繁にテンポりますね･･･
73：名無しさん：2011/08/10(水) 21:57:26: >>71
管理人さん
具体的に実装した対策(plugin)とかは列挙していただけませんか？
74：wiki管理人 ◆aRmzD8Jm32：2011/08/10(水) 23:40:46: 負荷対策でしたら
・webcacheってプラグイン
・アイコン画像を別サーバーに置いた
この2点が大きな対応です

503の対策はサーバー会社が行っているため不明です
75：名無しさん：2011/08/16(火) 18:21:11: 毎週火曜にテンポりや504が多い気がします
今まさに酷いですね
76：wiki管理人 ◆aRmzD8Jm32：2011/08/18(木) 01:44:32: 2週間たったけど相変わらずの状況なんで
"契約解除して返金求めるぞコノヤロウ"
とサポートを突っついてみました

長い間不便かけてて申し訳ない
向こうの返答によってはまた移転することになるかも
いいレンタルサーバーあったら教えてください
77：wiki管理人 ◆aRmzD8Jm32：2011/08/18(木) 01:50:03: ちなみに１週間くらい前にサポートから
"お前のとこのwikiがアクセス過多のせいだから"
って返事がきてた

サーバーの負荷率は毎日「0p」　※1000p以上で高負荷らしい
転送量は毎日「5GB前後」　※契約内容は750GB/月まで制限無し

負荷かかってるように見えないぞどういうことだ
と即レスしたんだけど返事は無し

評判でサポートが悪いとはあったけどここまでとは思わなかった
78：名無しさん：2011/08/20(土) 21:52:57: wikiの編集者同士の相談ってここでしてもいいでしょうか?
トップのコメントが雑談可を明記したのはとても良いことだと思うのですが
かわりに編集用のコメントがwikiの掲示板なので503連発で凄い使いにくいです･･･
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群が似たような事で
苦労しノウハウを蓄積しているので参考にしても良いかと思いますよ。
81：wiki管理人 ◆aRmzD8Jm32：2011/08/22(月) 16:04:38: >>78
使いづらくてごめん
掲示板がアレなら編集者用のコメント欄作りますか？

ここは勝手に使わせてもらってる身なんで「いいよ！」とも言えないけど
今のところ怒られてないんでここでもいいよ

>>79-80
わー、わざわざ来ていただいて助言までありがとうございます！
Web_cacheを導入させていただき大変助かってます
負荷は測ってないので詳細はわかりませんが表示がだいぶ早くなりました
# よって負荷も減っているはずです

Convert_Cacheというのはまだ導入していません
>>77にも少し書いたのですが現在問題が出ている503の直接の原因がわからず
CPU負荷が問題なのか転送量が問題なのかはたまた別の問題なのか
何が原因かわからないため手の打ちようがないというのが現状です
ただそのConvert_Cacheというのはお聞きする限り効果大のようですし
手当たり次第に対策をするしかない状況ですので少し調べて導入を検討してみます

編集用と閲覧用にミラーを用意するのは効果絶大だと理解しているんですが
・複数台のサーバー管理が大変
・転送手段が難しい（自宅PC経由は電気代かかって奥さんに怒られるのがネックｗ）
・更新の際に編集用に飛ばす対応
・閲覧用からコメントを反映する対応
と色々解決しなきゃいけない問題が多く使い勝手も少し落ちるのであまりやりたくないなと

ひとまずそのConvert_Cacheを導入して様子を見てみようかと思います
もし何かありましたらblogにコメントさせていただくかもです
色々ありがとうございました :)
82：wiki管理人 ◆aRmzD8Jm32：2011/08/22(月) 16:23:05: ＜＜現状報告＞＞

現サーバーのCORESERVERで解決の目処がたたないので
移転を考えて比較サイト上位のレンタルサーバーに問合せしてみた

1. WADAX
アクセス多すぎて共用サーバーじゃ無理
専用サーバー(19800円/月)ならいけなくもないよ

2. ABLENET
アクセス多すぎて共用サーバーじゃ無理
VPS(980円～/月)か上位プラン(14800円/月)ならいけるかも
※VPSは導入や管理に手間がかかる

3. Xbit
アクセス多すぎて無理
※1万PV/日が目安らしい(wikiは8～10万PV/日)

4. Speever
弊社と提携してる某社よりご連絡いたしますので御社のご担当者様のご連絡先を～
→個人なんですけお…
※プラン確認したが法人向けで20000円～/月とか

5. sixcore
S1プラン(1890円/月)で転送量はOKだけどサーバー負荷が厳しい
上位プランでもサーバー負荷の制限はほぼ一緒
負荷軽減すりゃいけんじゃねーの？うちんとこにしろよ

とのこと
2. ABLENET：VPS(980円/月)
5. sixcore：S1プラン(1890円/月)
のどちらかなーと
VPSは導入がめんどくさいのでやりたくないけど
sixcoreは制限かかると503出るらしく改善とならない可能性あり

↑で教えていただいたConvert_CacheでCPU負荷が改善されるらしいので
それいれてsixcoreにしようかなーと検討中

ただCORESERVERに3ヶ月分(10月半ばまで)お金払っちゃってるのと
最近あまり時間がなく移転作業が難しいのがネック
83：79：2011/08/22(月) 23:17:50: 出先なので携帯にて。
鯖側の規制には他に同時リクエスト数や同時実行プロセス数などあり得ます。後者はcpu負荷対策
で対応可能ですが前者はサーバを変えるしかミラー作戦しかないです。
で、月500gbはぶっちゃけ洒落になら無い規模です。個人的には解決策探求に闘志が燃えてきますけど。

ミラーは発想を変えれば簡単です。編集鯖で定期的にログdirをgzip、ミラー側は定期的にwgetな
りで取得、解凍して上書き。coreのcronは不安だけどこの程度ならいける筈。
自分ならミラー案ですね。core-Aで月100gb捌いてた経験上。面倒かもしれませんが、｢お金は大
事だよー｣です。ミラー案は金銭的問題を一番楽に解決します。システムが安定すれば手が掛から
なくなるしアクセス減ればミラーを適宜解約で財布にもグー。

pukiwikiは欠点もありますがそれを使いこなせないレベルや知識なら何使っても同じです。
鯖も然り。ダメなサービスと評価するのはやることやってからでも遅くないかと思います。コアや
桜だってわきまえて使えば良いサーバですよ。使いこなさないでダメと言うのは賢いとは言えない
と思います。

ともあれ、同じ管理人として応援しています。
……すっごく自分で挑戦したくてｳｽﾞｳｽﾞしたますがっ。
84：wiki管理人 ◆aRmzD8Jm32：2011/08/23(火) 00:12:20: >>83
うーん、そうなると状況から同時リクエスト数の可能性が高そうです
どこまでアテになるかわからないですがpukiwikiの&online;での表示が大体100前後です
管理画面からサーバープロセス確認しても同時に5～10は常にあるので
過負荷時に20も同時にきたら制限かかりそうですね

となるとやはり解決策は
・1リクエストの処理時間を短くする
・ミラーで負荷分散
・いいサーバーにする
ってとこでしょうか

勧められるがままに
1. Convert_Cache導入
2. ミラー設置
と試してみます

ただ一つ疑問が
編集用、閲覧用と設置した場合、ミラーの閲覧用に集中して
結局ミラーサイトが過負荷で503とかでちゃうんじゃないかなと
閲覧用は更新ないのでHTML化とか出来ればいいんですが
以前HTML化しようとしてやり方わからずに挫折したんですよねｗ

うまく対応すれば今のサーバーでもいけそうなのでちょっと頑張ってみることにします

ちなみに今は頻繁に使用されている画像を別サーバーに置いたので転送量は150GB/月程度です
以前使っていたのはドメインキングというサーバーなのですが
ここはキャンペーンで100円/年で借りたのに500GB/月でも問題なく稼働しており何気にいいサーバーでした
今ここを画像用として使用しており転送量減らすのに大いに役立ってたりします
85：wiki管理人 ◆aRmzD8Jm32：2011/08/23(火) 16:24:19: Convert_Cache導入してみました！だいぶ速い！
が、相変わらず503が頻発しちゃいます…

PROCESS CPU(%) MEM(MB) STATUS IP/HOST REQUEST
12780 7.9 14m W A GET /wiki/index.php?plugin=ref&page=images&src=item_frozenmalle
12797 4 14m W B GET /wiki/index.php?plugin=ref&page=images&src=item_malady.gif
12800 11.9 16m _ A GET /wiki/index.php?plugin=ref&page=images&src=item_madredsbloo
12804 7.9 15m W C GET /wiki/index.php?plugin=ref&page=images&src=Champion_AttackD
12818 4 16m W A GET /wiki/index.php?plugin=ref&page=images&src=item_sunfirecape
13503 4 15m _ A GET /wiki/index.php?plugin=ref&page=images&src=item_spiritvisag
12822 11.9 15m _ A GET /wiki/index.php?plugin=ref&page=images&src=item_mercurystre
12824 4 16m _ A GET /wiki/index.php?plugin=ref&page=images&src=item_bansheesvei
25712 7.9 11m D D GET /wiki/index.php?%A5%C7%A1%BC%A5%BF%A5%D9%A1%BC%A5%B9%2F%A5%

プロセスを確認すると上記のような感じになってまして
画像表示のためのrefプラグインが負荷になっていそうです
これをphp経由でなく表示できれば改善されそうな気もするんですよねえ…

またキャッシュ導入の弊害として#includeで読み込んでいるページの更新がうまくいかないみたいです

・パーツページ（子）
ttp://loljp.net/wiki/index.php?%A5%C7%A1%BC%A5%BF%A5%D9%A1%BC%A5%B9%2F%A5%C1%A5%E3%A5%F3%A5%D4%A5%AA%A5%F3%2F%A5%D1%A1%BC%A5%C4%2FAnnie

・メインページ（親）
ttp://loljp.net/wiki/index.php?%A5%C7%A1%BC%A5%BF%A5%D9%A1%BC%A5%B9%2F%A5%C1%A5%E3%A5%F3%A5%D4%A5%AA%A5%F3

※パーツページを更新してもメインページのキャッシュが更新されず古い情報を表示してしまう

ttp://loljp.net/wiki/index.php?:config/Convert_Cache
この辺をうまく設定すれば直りそうなので少し模索してみます
それまではパーツページ更新後にメインページを空更新で対応してみてください
86：wiki管理人 ◆aRmzD8Jm32：2011/08/23(火) 17:09:29: 少しプロセスを監視していたところ
503発生時にrefプラグインが大量に呼ばれてるっぽいです
refを多く使用しているページが呼ばれると
同時リクエスト数が増え制限かかって503が発生しちゃってるのかも

参考
87：wiki管理人 ◆aRmzD8Jm32：2011/08/23(火) 17:10:17: 途中送信しちゃった

参考
ttp://z49.org/2010/08/10/460/

まさにこれかも…
88：wiki管理人 ◆aRmzD8Jm32：2011/08/23(火) 17:12:45: どっかで見たサイトだと思ったら>>79氏のサイトでしたｗ
ちょっと真似してみます
89：wiki管理人 ◆aRmzD8Jm32：2011/08/23(火) 17:40:20: もうtwitterでやれって感じになってますが対応履歴ということで許してください

・添付ファイルには HTTP Last-modified ヘッダをつけるべき
ttp://pukiwiki.sourceforge.jp/dev/?BugTrack2%2F249

ここを真似っ子してrefとattachににLast-modifiedを付けてみました
日毎のユニークホスト数が7000前後と結構多いので
ブラウザキャッシュがどこまで効果あるのかわかりませんが
ユーザーのリピート間隔が同日82%とのことですので
１～２日後には効果が出てくる（かもしれません）

refプラグインを介さずに画像を貼り付けられるとベストなのですが
いまのところやり方がわからないためその対応は後回しです
90：79：2011/08/23(火) 22:46:36: 今日も未だ出先なので携帯です。
1つで足りないなら一杯準備すれば良いじゃない(ﾐﾗｰ
煩雑にはなりますが全体的経費は鯖1台より遥かに安く上がります。
編集鯖ですら安鯖で済みますから。月150gbならそんなに要らんでしょうし。

ドメインキングは二年目以降が高かった記憶が。ご注意を。

refの件はかなり重要です、良くお気づきでしたね。改良プラグイン採用もありですが
抜本的改善を図るなら、運用でなんとかなります。すなわち、添付ファイル用サーバを借り、あぷろだを置きます。
で、wikiにファイルを張る時はあぷろだから張るようにすれば良いのです。
これも転送量的負荷分散になりますよね。この場合ミラー作成時に楽になるというおまけも。

完全html化は地味に面倒です。特に日本語ページがあると。fallout3の時やりましたが完全自作専用
スクリプトを書いて処理しました。可能ならやるべきですが、あんまお勧めしません。

include系が時々うまくないのは当方は割りきってます。そういうぺーじに｢反映しない時は空更新よろ｣と。
それで十分かと。

アクセスログを見てそれぞれの対策後に503発生率がどう変動したか調べておくとよいでしょう。
効果の程を確認する為に。

このようなノウハウ記事、暇ができたら書いてみるかなあ。

という訳で健闘をお祈りします。
91：wiki管理人 ◆aRmzD8Jm32：2011/08/24(水) 10:59:13: こまめにお返事どうもです

その後状況を確認してますとやはりRefプラグインがほぼほぼの原因っぽいです
これさえなんとかなれば今の問題の9割は改善されそうな気がします
# 503発生時にプロセスを確認すると必ずRefが大量に呼ばれている
# 通常時はRefが呼ばれているプロセスはあまりない

うｐろだを置いて代用は確実に改善されることが予想されますが
・現行からの置換えがかなりの手間
・うｐろだの管理が増える
・画像貼り付けを許可しなければいけない（貼付け元をろだに限定すればおｋかも？）
・attachと違いバックアップが取れない（バックアップ付きのろだを選定すれば解決）
・画像の更新時が難しい（アップファイルをURL変えることなく更新できるろだを選定すれば解決）
パッと思い付くだけでぽろぽろと問題が出てきちゃいます

特に問題なのが管理かなーと考えてまして
やってることはwikiへの添付と大差ないのですが
ろだは使用を慣れている方が多いため別の用途等に使われかねないのが怖いです

また対策のすべてに絡む話なんですが
利用者の手間が増えるなどサービスレベルが落ちるのは極力避けたいんですよね
503が頻発する現状よりマシなのはわかってるんですが高望みしすぎなんでしょうか
92：名無しさん：2011/08/24(水) 16:02:17: ref(&ref(images/ico_Annie.png,Annie);等)を使った場合とアイコン化された物(&c_annie;等)の場合負荷は変わるのでしょうか？
変わるなら各チャンピオンページの顔やスキルアイコンも変えてしまった方がいいと思いますが
93：wiki ◆SZQ5pun5Hk：2011/08/24(水) 17:54:38: 変わります！
むしろそのためにアイコン化をしていたりします。

ただアイコン化が手作業のため手間が結構かかるんですよね。
ネーミングルールを決めれば手作業もいらなくなりそうですので、
ちょっとその方向でも考えてみます。
94：wiki ◆aRmzD8Jm32：2011/08/24(水) 17:55:49: >>93は携帯からのためトリップ間違えました :p
95：79：2011/08/24(水) 23:05:48: 今日も携帯にて。
関わったからにはある程度の解決は見たいので。

その辺の懸念は判ります。じゃ編集者に負担が行かない様にと考えると、
管理者が添付画像をちまちま画像鯖に起き直してソース書き換えしかなくなります。
面倒ですよね。実は禁じ手がひとつ有りまして、refプラグイン設定の
最後のをtrueにする方法です。これはなぜ禁じ手か理解出来、
対策を講じられる人しか選んではなりません。

利便性を損なわず画像直接呼び出しを実現したい場合はrefプラグインの
改造で出来そうです。即ち、｢通常はそのままだが管理人等が確認し
安全と分かった画像は直接呼び出しに変更する｣査読？形式にしてしまうものです。
管理人の手間は増えますが信頼できる人に手伝って貰っても良いでしょうから
大変でもないかと。
問題は現物が無い事です。私は暫くは無理なんでやるとしても出来上がりは
先になりそうです。
原理や仕組み的には極めて単純なのでそちらのwikiの利用者からphp書ける人を
募ってお願いしてはいかがでしょうか。
96：名無しさん：2011/08/25(木) 02:14:23: >>93
やっぱり変わりますよね
とりあえず全チャンプの個別ページで顔のアイコンをrefからアイコン化した物に変更しておきました
小ネタ等を残しつつ現テンプレに沿って旧verのアイテムビルド等を一掃
97：名無しさん：2011/08/25(木) 02:53:12: あと各ビルドページで人によってはrefを使っている量がかなり多いのもあった
ルーン・マスタリーのアイコンはないので仕方ないけど
アイテムやサモナースペルも全部refで引っ張ってきてるのまである
DPS kennenみたいなrefばっかりのページで全く更新されないビルドページは
編集者には悪いけど削除するか一般の目には届かないよう過去分として隔離してもいいのでは
もしくは無断で修正するか
98：名無しさん：2011/08/25(木) 07:02:12: >>96
自分で勝手に作った「現テンプレ」に沿って作業するんじゃねーよ
そんなものの話は見たことも聞いたこともない
全体の改修はちゃんと話し合ってからやれ、他人の書いたものを消したり書き換えたりする時は特にだ

チャンピオン詳細からビルドやらアイテムやらを整理したい時はビルドのとこに新しいページ作って
そっちに移行する形で作業されてる形跡があるだろ？
なんでも消せばいいってもんじゃない、ちゃんと元に戻しとけよ
99：wiki ◆aRmzD8Jm32：2011/08/25(木) 07:54:43: ちょっとまだwikiを確認できてないのですが
チャンピオン詳細からビルド系の記述を消したってことですよね
でしたらチャンピオン詳細のテンプレに添っているため問題ないです

ただテンプレに合わない書き方をしていたとはいえ
せっかくどなたかが書いてくれた内容ですので
>>98氏の言うようにビルドページに移してあげるのがベストではあります

今回の精査は数も多いため
ひとまず消して復活要望があれば移すでも良いかもですね

その他のレスや詳細についてはwikiを確認してからまたレスします
100：wiki管理人 ◆aRmzD8Jm32：2011/08/25(木) 11:10:16: >>79
Refにこんなオプションがあったなんて…

懸念点というのは後ろの文から察するに
悪い画像をアップして踏み台にされちゃうかも、っていうことですよね

通常のRefプラグインの呼び出し方でも
<img src="ttp://loljp.net/wiki/index.php?plugin=ref&page=Champion%2FAkali&src=AkaliCrescentSlash.png">
などとimgタグに入れちゃえば呼び出せちゃいますし
直接アクセスを許可した場合のリスクはさほど変わらないんじゃないでしょうか

そもそもRefさえなんとかなれば直るのか、といった検証も兼ねて
ひとまずRefの直接アクセスオプションをTRUEにして試してみます
これがうまくいけばアイコン化もいらないかもですね