ECOwiki編集・相談スレッド - 1388806946

1：名無しさん：2014/01/04(土) 12:42:26 ID:6HK1tTSc0: 旧、新wikiについての情報をやりとりするスレです。

旧wiki：ttp://ec.gamedb.info/wiki/
暫定新wiki：ttp://emil.wiki.fc2.com/

旧wikiの前からの管理人失踪、突然のページ削除
これからの編集・方針について情報交換していきましょう。
321：Jasmin：2015/09/03(木) 22:15:37 ID:qtigWOJ20: 分割推奨ラインですが、あれはgamedb-wikiの時のものなので、
ECO-Wiki (acronia) では多少超えても大丈夫だと思います。

もちろん巨大ページ・画像は好ましくありませんが、
Wiki側と言うよりは閲覧者側の利便（重さや使い勝手）を考慮して判断してもらえればと思います。

参考に、ECO-Wiki (acronia) での状況は以下のようになります。

【各リソースが逼迫した場合に起こる問題と現状】
◯Wiki全体の転送量
→アクセス制限（503エラーなど）
[現状] 転送量上限の目安40GB/日に対して、2GB/日程度で問題なし

◯Wiki全体のアクセス数
→アクセス制限（503エラーなど）
[現状] 3月ごろに制限が発生。制限目安は不明なものの、最近は問題は起こっていない。

◯編集時・ページ生成時のピークメモリ使用量
→該当wikiページの編集・表示が出来ない
[現状] 制限128MBに対して現状は最大30～40MB程度なので問題なし。

◯編集時・ページ生成時のCPU使用量
→アクセス制限（503エラーなど）
[現状] 制限目安は不明なものの、特に問題は起こっていない。

【管理者側で実施している対策】
◯Wiki全体の転送量
→gzip圧縮転送
→ブラウザキャッシュの活用

◯Wiki全体のアクセス数
→画像の遅延ロード・画像同時DL数制限
→ブラウザキャッシュの活用

◯編集時・ページ生成時のピークメモリ使用量
→（特になし）

◯ページ生成時のCPU使用量
→bodycacheパッチの適用

【編集者側で可能と思われる対策】
◯Wiki全体の転送量
→Wikiページ記述量削減（gzip圧縮しているので影響小）
→画像数、画像ファイルサイズ削減

◯Wiki全体のアクセス数
→画像数削減（特に一度に表示される画像数）

◯編集時・ページ生成時のピークメモリ使用量
→Wikiページ記述量削減（ページ分割など）
→includeで分割ページ読み込み

◯編集時・ページ生成時のCPU使用量
→Wikiページ記述量削減（ページ分割など）

【備考】
・転送量は余裕があるので、閲覧者から見たページの重さなどを考慮してください。
・HTMLはgzip圧縮転送されるので、多少大きくてもページ表示速度への影響は少ないと思います。
・includeでの分割はピークメモリ使用量削減効果がありますが、現状問題にはなっていないので、無理して使う必要はありません。
322：319：2015/09/03(木) 23:25:10 ID:TWrVlILE0: ありがとうございます。現在の分割提起は取り下げます。
ページサイズのみを根拠にしていて(利便性等ではない)、これは大きな問題になっていないとのことですので。
通常　　463KB 68+31体メモリ8.4MB
アルマ 331KB　　　46体メモリ9.6MB
分割後 328KB 24+22体メモリ3.7MB　←1期2期を独立させてincludeしたテストページ
ttp://eco.acronia.net/wiki/?SandBox/table5

「総アルマ化」がいつまで続くか不明ですが、分割が必要になっても通常を参考に構成すれば良いので直ちに分割可能だと思います。
323：287：2015/09/03(木) 23:56:37 ID:TWrVlILE0: ちなみにスキル全載せ版>318はメモリ11.4MB、ページ生成時間は50倍みたいです。
もし全載せした場合、重いという意見が多ければ直ちに分割includeしようと思います。
324：Jasmin：2015/09/04(金) 01:11:57 ID:qtigWOJ20: ページ生成時間とメモリ使用量は、
「State: generated.」と「State: cached.」でかなり差があるので気をつけてください。

「State: generated」→編集直後の初回ページ生成で、生成時間大、メモリ使用量大。
「State: cached.」→2回目以降の閲覧でキャッシュ利用のため、生成時間小、メモリ使用量小。
「State: skippedやsuspended.」→キャッシュが使えない特殊ページやプレビュー。負荷はgeneratedと同様。

分割includeが効くのは「State: generated」の方ですが、
大半の閲覧は「State: cached.」で捌かれるので
閲覧に関してはパフォーマンス上の問題は起こりにくくなっています。

また、memory_limitの設定も128Mと大きいので、
ページの肥大化で編集不可能になる心配もほとんど無いと思います。
（gamedb-wikiは、たぶんmemory_limitがだいぶ小さかったのだと思います。）

#contentsが使えないデメリットもありますし、分割includeはやらなくて済むならその方が良いかと思います。
325：Jasmin：2015/09/04(金) 01:28:33 ID:qtigWOJ20: なお、「Wiki全体のアクセス数」の観点からは、
（includeで結合せずに）独立したページに分けた方が良いです。

例えば、今のアルマページの構成だと「第3期アルマ」の情報を見に来た人も
ページを開いたときに上の方にある「第1期アルマ」の画像を読み込むことになり
その分アクセス数が増えてしまうからです。

閲覧者からすると画像を余計に読み込むことにもなるので
結構長くなってきたアルマページは分割を真剣に考えて良いかもしれませんね。