負荷対策のまとめ†
- ページ: BugTrack
- 投稿者: henoheno
- 優先順位: 重要
- 状態: 着手
- カテゴリー: その他
- 投稿日: 2004-12-13 (月) 22:48:21
- バージョン:
メッセージ†
なぜだかdevサイトが急に重たくなっている様であるため、
突然ですがいくらかの負荷対策を施します。(※といっても設定の調整ですけどね)
ついでに、理由はどうでもいいから今まで散在していた
負荷対策ネタを一つに集めようという、
ひとつぶで二度おいしいBugTrackです。
- ※現在 devサイトは pukiwiki.org と同じサーバーに移動しており、負荷周りの問題は解消しています。きっかけとなった話題はsourceforge.jp 上にいたころの話です
- ※その後、別のサーバーに避難した後、再び sf.jp に戻って来ています
負荷対策とは†
- きちんと状況を把握する
- ボトルネックを無くすことで、ダメージを和らげる
- 余裕を多く取ることで、同時に取り扱える量を増やす
- きちんと情報を分けることで、不必要なアクセスを減らす
とりあえず設定を変えて様子を見る†
負荷をかけやすい機能を無効にして、状態（convert timeなど）の変化を比較する
CPUの負荷を減らす: 過度な装飾を削る†
// 編集時にkakasiやchasenを呼ばない。PageReadingを読ませない。 (pukiwiki.ini.php)
$pagereading_enable = 0;
// 一覧ページに頭文字インデックスをつけない (default.ini.php, keitai.ini.php)
$list_index = 0;
// 検索文字列を色分けする機能を無効化する (default.ini.php, keitai.ini.php)
$search_word_color = 0;
// 関連するリンクを表示しない (default.ini.php, keitai.ini.php)
$related_link = 0;
// WikiName,BracketNameに経過時間を付加しない (default.ini.php, keitai.ini.php)
$show_passage = 0
// 脚注へのアンカーに本文を埋め込まない (default.ini.php, keitai.ini.php)
define('PKWK_FOOTNOTE_TITLE_MAX', 0); // Characters
// 添付ファイルの一覧を表示しない (default.ini.php, keitai.ini.php)
$attach_link = 0;
- $attach_link = 0 の適用には注意点あり。see BugTrack2/68
- BugTrack2/264 attach プラグインの md5 計算による負荷の問題
- $attach_link = 1 の運用時や、一覧を表示する時に、「必ずMD5値の算出(※重たい処理)をしている」という問題が解消されました（パッケージ収録は、1.4.7_1 以降の予定）
ネットワークの負荷を減らす: 出力の量を抑える†
// 雛形とするページを一覧しない (default.ini.php, keitai.ini.php)
$load_template_func = 0;
// 関連するリンクを表示しない (default.ini.php, keitai.ini.php)
$related_link = 0;
フッタにあるCopyrightの表示を削る (程度はお任せ)
過度な装飾を削る事で、出力の量をほんの少しでも減らす
キャッシュを生かす†
- refを使って読み込んだ画像を明示的にキャッシュさせる →質問箱4/422
ref.inc.phpのpkwk_common_headers()内
header('Content-Disposition: inline; filename="' . $filename . '"');
header('Content-Length: ' . $size);
header('Content-Type: ' . $type);
header('Cache-control: private, max-age="720000"'); //←追加
header('Expires: ' . date('D, d M Y H:i:s', UTIME + 720000) . ' GMT'); //←追加
Cache-controlのmax-ageの値はキャッシュさせる時間（秒単位）。適宜変更してください。Expires内では、max-ageと同じ値をUTIMEに加算してください。
ただし、この修正だけだとPHPが'304 Not Modified'ステータスを返せないので、本体のデータが毎回ダウンロードされる可能性が残ります。「Last-Modified ヘッダを出力する」のBugTrack/799やBugTrack2/249を参考に、If-Modified-Sinceの判定などを追加してください。
- Apacheのモジュールmod_expiresを利用する
mod_expires
pukiwikiにて出力されるhtmlデータ以外をキャッシュさせる(css,js,画像,swfなど)
refの改修と同時に行うと、出力されるヘッダーに問題が発生する場合があります。
たとえば、ref内でCache-controlだけを指定しExpiresヘッダーを同時に指定しなかった場合などで中途半端に上書きされ、'Cache-control: private, max-age=720000, max-age=86400'のような2重定義状態になる事があります。同時に指定してもこのような状態が発生する場合は、refの改修かmod_expiresのどちらかの方法だけを適応する事。
とりあえずカットする†
MenuBar/FrontPageのデータ量を削減する†
携帯コンテンツ向けのFrontPage、MenuBarを別途作成する†
そちらには携帯コンテンツ向けに軽い内容を置く
// 携帯・PDA専用のページを初期ページとして指定する (keitai.ini.phpに追加)
$defaultpage = 'm';
携帯関係の設定などを全部スッパリ削る†
- PCから閲覧することを前提とした情報・データ(量)のPukiWiki向け
PC関係の設定などを全部スッパリ削る†
- 携帯からしか使わないPukiWiki向け
- スキンは当然keitai.skin.phpがベース。keitai.ini.phpの中身をdefault.ini.phpにコピー。
CPUとメモリとHDDの負荷を減らす: AutoLink を無効にする†
- 閲覧時や、リンクデータのキャッシュ（autolink.dat, *.rel, *.ref）を更新する時に発生する負荷を、ある程度抑えられます。
- AutoLink → BracketName に変更する手間が発生するが、動作不順に陥るよりは・・・・・といったところ → 関連: BugTrack2/81
CSS方面†
Wikiに何ページアクセスしようが、CSSには１回しかアクセスされないでしょう。(負荷はユニークユーザー数 x 1) それがページとの違いです。
プリンタ先頭のCSS をブラウザに読み込ませない (スキンの一行を削る)†
- インターネットに公開しているWikiの場合、印刷用のCSSは大部分の閲覧者には必要ではありません。負荷とのバランスを考えて選択しましょう。
CSSを静的なファイルにする (1.4.5-)†
- PukiWiki 1.4.5 からCSSがPHPスクリプトになりましたので、これを静的なファイルにすることで実行時間を削減することができるでしょう。
アクセス禁止†
- 特定ホストのアクセス禁止 (.htaccess, httpd.conf)
- 特定 User agnet のクライアントのアクセス禁止
よく調べて対策を取る†
サーバーの状況をよく調べる†
- load average、ネットワーク帯域などのグラフをチェックする
- Unix like OSの場合
- とりあえずエラーログをチェックする
- とりあえずログをチェックし、現象が恒常的なものか確認する
- uptime コマンドで load average の様子を見てから nice top
- vmstat などでメモリの状況を調べる
- OSの不要なサービスを停止する、自動起動しないように設定を変更する
ハードウェア: もう一台買う／取り替える†
- 常時CPU負荷が高いのであれば、初めからマルチ(デュアル)CPUを検討しましょう。
ハードウェア: メモリを数百MBくらい増やす (昔のマシン向け)†
- メモリの負荷が仮想メモリにまで割り込んでいるときには効果があるでしょう
- 起動時間や電気代が増したりエラー(パリティなしの場合)発生の原因になるので、1G以上はホームユーザーにはお薦めできない。
ハードウェア: 割り当てるHDD、割り当てるパーティションを最適化する†
役割ごとにHDD、ないしパーティションを切り分けることで仕事の並列度を向上。HDDを増やすと電気代と熱量も向上するぞ!
- プログラム用のパーティション
- データ用のパーティション
- ログ書き込み用のパーティション
OSのカーネルをチューンする (※しろうと には おすすめ できない もろばのつるぎ)†
入れ替えに失敗して起動しなくなってもどうにかできる人、あるいは環境(PC)がある人向け
- 無駄なモジュールを無くしてメモリの余裕を稼ぐ
- 無駄なモジュールの利用を無くして負担を減らす
- バイナリを最適化する
Webサーバー、PHPのバイナリをチューンする (※おおっと ばくだ)†
- バイナリを最適化オプションをつけて作る
- とりあえず必要なモジュールだけにする
- とりあえず静的リンクする
Webサーバー、PHPの設定を見直す†
PHPアクセラレータの導入を検討する・良く試す†
- 実験は別のサーバーで行いましょう
- トラブルがあった時にPHPアクセラレーターをoffにして様子を見たりして、障害の切り分けができる人向け。でないと周りに迷惑をかけるでしょう
ネットワークの経路・配線を見直す†
- 同じサブネットで余計な通信をしていないか (そもそもスイッチングハブを導入していないのではないか)
ファイアウォールの設定を見直す†
- そもそも余計な負荷がサーバーに届かない様にすべき。
ネットワークの負荷を減らす: CPUと引き換えに帯域を圧縮する†
通常の検索機能の代わりにNamazuを使ってもらう†
適材適所で。
Wikiの代わりに(掲示板CGI、ML、IRCサーバー・・・)を使ってもらう†
適材適所で。そのマシンで稼動させる必要がないものはそうしましょう。(Wikiも含む)
目的別にWikiを分ける・作る†
適所適材で。
ミラーサーバーを設ける†
- Read only の PukiWikiを用意し、rsyncで定期的にそちらへ送りつける
Webコンテンツの基本を思い出す†
極端に大きな画像を小さくする・色数を削減する†
- 大きすぎる画像を小さくする
- GIFで保存すべきのっぺりとした画像をJpegで保存しない。それをまたGIFに保存し直したりしない
- 色数(色深度)に制限のある形式の場合、さらに色数を削ることができるか考える
情報ごとにページを分ける†
- 情報を適度に分割する
- きちんと見出し、 #contents、 #ls2 などをわかりやすくつける
- 「必要な情報だけを必要な時にすぐに読んでもらえる様な構造にしておく」
- ユーモアを忘れない
他に利用しているサービスの負荷を減らす†
PHPアクセラレーター†
- PHPアクセラレータで一番高速なのはどれか？ - GIGAZINE
- XCacheのインストールとphp用アクセラレータ比較
コンテンツキャッシュ (改造)†
- 0hitぷき - キャッシュ実装
http://puki.0hit.net/index.php/Convert_Cache （消滅）
参考文献†
- 管理人へ連絡/13:鯖負荷対策 - 新潟中越地震 被災者救援本部@2ch
コメント†
昔、sourceforge.jp にいたころのコメント†
- これを書きながらdevサイトの設定を少々いじりましたが、ちょっと体感速度が上がったかも :) -- henoheno
- ・・・とりあえず、SFのWebサーバーとは直接関係がないけれども、SFのシェルサーバーのdmesgに気になる文字列*1が沢山続いているので、連絡だけはしておこうかな・・・ -- henoheno
- リードオンリーなミラーサイトとかドキュメントサイトを提供できますが要りますか？ -- ishii
- お申し出ありがとうございます。とりあえず少しづつ対策を取りつつ様子を見たいと思います。 -- henoheno
- CSSがPHPで一本にまとめていますが、負荷が高いところなら*.cssにバラした方が微量ながら負荷軽減になるかな？ 後は地味な対応ですが counterを使わない、AutoLinkを切る(!)、不要なユーザー定義ルールやフェイスマークを削る、とか。 上の方に挙げられている$lastmod の変更はデフォルトスキンを使っている場合はスキン内の header('Pragma: no-cache') 等で無効化される(BugTrack/413,BugTrack/486)ような気が。 -- にぶんのに
- あうっ、経過時間が出なかったので一瞬悩みました XD -- teanan
- みなさんコメントありがとうございます。上記は、とりあえず実用的な機能を失わないネタから挙げていっています。追記予定 :) どのへんで落ち着くかわからないため、devの設定等もまだ削るかもしれません。AutoLinkを含みます。 -- henoheno
- ページの下にあるアイコンのうち、上部のメニューで代替可能な物を削除したり、W3CやSFのロゴをFrontPageに移動することも(ここの)負荷対策にはなると思います。 -- Ratbeta
- 一つのWikiを複数サーバに分ける(逆WikiFarm?)のも、可能なら負荷対策として期待できると思いますが…現実的ではないですね。 -- Ratbeta
- 落ち着いてきた感もありますが、元々段階的に絞りながら様子を見るつもりでいましたので、引き続きTrackBack, Referer, AutoLinkもオフにしました。TrackbackはBugTrack/759が落ち着くまでこのままとしたいと思いますです。 -- henoheno
- If-Modified-Since に対応できれば、さほど大掛かりに改修しなくても、それなりに効果は得られるでしょうか？ -- にぶんのに
- 個人的にはこの重さには耐えられないなぁ*2…不測の事態に備えるって意味でも*3サクッとミラーしませんか？GOが出れば10分か20分位でサーバーの用意は可能なのでwebmaster<at>ishii<dot>mydns<dot>jpまで連絡下さい。 -- ishii
- あれっ？急に軽くなった…さっきまでタイムアウトしまくっていたのに。 -- ishii
- ちょっと私も辛く感じてきました。今のところorgサイトに余裕がありますので、避難するとしたらそちらにしようと思っています(まずは手元の資源をきちんと使うということで)。 -- henoheno
- 移動するついでに、文字どおり dev.pukiwiki.org にする・・とか？ (^-^ *4 -- みこ
- CSSが送られてこない事が起こり始めている現状は、なかなか危うい感じがしますね (^^; -- henoheno
pukiwiki.org と同じサーバーの時のコメント†
- ※現在 devサイトは pukiwiki.org と同じサーバーに移動しています。上の話題はsourceforge.jp 上にいたころの話題です
- 箱庭諸島２の改造版があったのを思い出して考えてみたけど、入力するものはJavaScriptで全て描画する・・・とか。たとえば、ナビゲーション、ツールバー、単語検索画面、添付画面なんかはHTMLで一緒に出力する必要はないし、うまくいけばBotも弾けるかもしれないし。問題なのは、document.getElementById('???').innerHTMLだらけになってしまう。 -- Logue
- 最近、Delegate経由*5で org や dev をアクセスすると、リロードしてもdelegateにキャッシュが残ってしまって 2005-01-04 時点の情報しか表示されないのですが・・・なにか行き過ぎた対策をしているということはありませんか？ (^^; （$lastmod あたりが不安なのですが・・・） -- みこ
- すいません、$lastmod がまだonになっていました。切りました。 -- henoheno
- 別鯖に仮移転して気がついたけど、cvs版や、特にrc_5ではだいぶ動作が軽くなってます。とりあえず、一番「重い」と感じるときは、ページの更新時だと思います。更新中にタイムアウトになってしまうのは、xreaに限った事でもないみたいですからね。 -- Logue
- 直近のCVS版の変更が、何か好影響を与えているのだと仮定した場合に思い当たるのは、現実的でない長さのGETメソッドに対して出力を打ち切る様になっている部分や、逆リンクの実装が(全文検索を回すのでなく)キャッシュを見る様になって極端に高速化している部分ですね。Webクローラーやワームに由来する負荷についてそれなりに打たれ強くなっているのではないかと思われます。編集の部分はいじっていませんから変化が無いでしょう。 -- henoheno
- もしよろしければ、またグラフを観察してみて下さい :) -- henoheno
- cpanelに表示される負荷を見る限りでは、本当にスペックをもてあましてるって感じです。たぶん、編集した後が重いというのは、更新と描画（？）を１回のリクエストでやってるからかもしれません。たとえば、metaタグのリフレッシュを使った（２ちゃんねるの書き込んだ後のような）やりかたなら、１回でサーバーに送る命令を分散できるので、負荷対策にはなるかもしれませんね。結局、編集直後にタイムアウトしやすいというのは、変わりませんし。正直xreaでも問題ない気が・・・。 -- Logue
- 更新時に重たいのは、私のところではrecent の更新と、autolink の更新です。全ファイルをオープンするので、ディスクアクセスが半端じゃないです。昔はstatic変数にキャッシュを持っていたのですが、1.4.5で抜けてしまっているので復活希望だったりします。get_filetime()やis_page()など。 -- kawai
- 何か勘違いされていると思います。is_page() のキャッシュは1.4.3までのPukiWikiが重かった一因で、実際にはPHPが既にファイルシステムに対するアクセスをキャッシュする機構をもっているため、存在する必要がないものでした(オーバーヘッドでした)。無くなったのは1.4.4じゃなかったですか? 試されて、うまく行ったらパッチとベンチをBugTrackへお願いします :) -- henoheno
- いえ、勘違いしていないので、BugTrack2 に出しますね。Tuning なので、デフォルトの設定をどちらに倒すかはプロジェクトの判断にお任せします。 :) -- kawai
- BugTrack2/11につづく。 --
pukiwiki.sourceforge.jp/dev/ に戻ってからのコメント†
- (mod_deflateを使用してみた感想) --
- CPU負荷にほとんど変化がなくレスポンスは大幅に向上しました。
テキストファイルが100KB程の場合、圧縮すると17KBほどになり
低速回線がダウンロードにかかっていた時間が大幅に短縮され
結果的にApacheのプロセスが短くなり、CPU負荷はほとんどかかりませんでした。
ref等で画像を表示している場合は圧縮対象から外す為の作業が必要です。BugTrack/738を参照
- BugTrack2/264 attach プラグインの md5 計算、mimetypeのチェックによる負荷の問題 --
- 開発日記/2007-11-05 trackerな日々（改善履歴とその関連リンク） --
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
