10:26:47)追加された行はこの色です。削除された行はこの色です。いくらかの負荷対策を施します。(※といっても設定の調整ですけどね)ついでに、理由はどうでもいいから今まで散在していた負荷対策ネタを一つに集めようという、ひとつぶで二度おいしいBugTrackです。同じサーバーに移動しており、負荷周りの問題は解消しています。編集時にkakasiやchasenを呼ばない。PageReadingを読ませない。//←追加max-ageの値はキャッシュさせる時間(秒単位)。//←追加Cache-controlのmax-ageの値はキャッシュさせる時間(秒単位)。Expires内では、max-ageと同じ値をUTIMEに加算してください。Modified'ステータスを返せないので、本体のデータが毎回ダウンロードされる可能性が残ります。ヘッダを出力する」の[[BugTrack/799]]や[[BugTrack2/249]]を参考に、If-Modified-Sinceの判定などを追加してください。-Apacheのモジュールmod_expiresを利用する&br;-[[Apache]]のモジュールmod_expiresを利用する&br;[[mod_expires>http://httpd.apache.org/docs/2.2/ja/mod/mod_expires.html]]&br;pukiwikiにて出力されるhtmlデータ以外をキャッシュさせる(css,js,画像,swfなど)&br;refの改修と同時に行うと、wikiでの添付画像のCache-control値が変な事になるのでキャッシュを指定する方法はどちらかの方法で適応する事。refの改修と同時に行うと、出力されるヘッダーに問題が発生する場合があります。max-age=86400'のような2重定義状態になる事があります。同時に指定してもこのような状態が発生する場合は、refの改修かmod_expiresのどちらかの方法だけを適応する事。恒常的に閲覧負荷をかける原因になります。スキンは当然keitai.skin.phpがベース。keitai.ini.phpの中身をdefault.ini.phpにコピー。*.ref)を更新する時に発生する負荷を、ある程度抑えられます。[#lfe558a6]Wikiに何ページアクセスしようが、CSSには1回しかアクセスされないでしょう。それがページとの違いです。インターネットに公開しているWikiの場合、印刷用のCSSは大部分の閲覧者には必要ではありません。負荷とのバランスを考えて選択しましょう。CSSがPHPスクリプトになりましたので、これを静的なファイルにすることで実行時間を削減することができるでしょう。常時CPU負荷が高いのであれば、初めからマルチ(デュアル)CPUを検討しましょう。起動時間や電気代が増したりエラー(パリティなしの場合)発生の原因になるので、1G以上はホームユーザーにはお薦めできない。[#f21ba756]役割ごとにHDD、ないしパーティションを切り分けることで仕事の並列度を向上。トラブルがあった時にPHPアクセラレーターをoffにして様子を見たりして、障害の切り分けができる人向け。そもそも余計な負荷がサーバーに届かない様にすべき。[#v3fe3086]適材適所で。[#rcd04c96]適材適所で。そのマシンで稼動させる必要がないものはそうしましょう。[#l2c4fe55]適所適材で。GIFで保存すべきのっぺりとした画像をJpegで保存しない。余力が無くなっている)のはそのような影響もあるかもしれませんね。23:55:43};--ちなみに、SF.jpのサーバー運営状況をチェックできるページは存在しません。もっか準備中とのこと。お申し出ありがとうございます。対策を取りつつ様子を見たいと思います。counterを使わない、AutoLinkを切る(!)、不要なユーザー定義ルールやフェイスマークを削る、とか。等で無効化される([[BugTrack/413]],[[BugTrack/486]])ような気が。みなさんコメントありがとうございます。上記は、とりあえず実用的な機能を失わないネタから挙げていっています。どのへんで落ち着くかわからないため、devの設定等もまだ削るかもしれません。AutoLinkを含みます。08:28:18};-ページの下にあるアイコンのうち、上部のメニューで代替可能な物を削除したり、W3CやSFのロゴをFrontPageに移動することも(ここの)負荷対策にはなると思います。14:57:37};-一つのWikiを複数サーバに分ける(逆WikiFarm?)のも、可能なら負荷対策として期待できると思いますが...現実的ではないですね。AutoLinkもオフにしました。Trackbackは[[BugTrack/759]]が落ち着くまでこのままとしたいと思いますです。01:37:06};-個人的にはこの重さには耐えられないなぁ((有償サービスだったらトップページの表示に1秒以上かかったらやばすぎです...))...不測の事態に備えるって意味でも((NFSのエラーってのが非常に嫌な予感がしています...来年にならないと抜本的な対策が行われないようだし...それに以前はよくこのDEVサイトが落ちていたし...))サクッとミラーしませんか?GOが出れば10分か20分位でサーバーの用意は可能なのでwebmaster<at>ishii<dot>mydns<dot>jpまで連絡下さい。03:37:40};-あれっ?急に軽くなった...さっきまでタイムアウトしまくっていたのに。私も辛く感じてきました。今のところorgサイトに余裕がありますので、避難するとしたらそちらにしようと思っています(まずは手元の資源をきちんと使うということで)。同じサーバーに移動しています。上にいたころの話題です-[[箱庭諸島2の改造版:http://logue.be/web/samp/hako21/]]があったのを思い出して考えてみたけど、入力するものはJavaScriptで全て描画する・・・とか。なんかはHTMLで一緒に出力する必要はないし、うまくいけばBotも弾けるかもしれないし。問題なのは、document.getElementById('???').innerHTMLだらけになってしまう。onになっていました。22:38:33};-別鯖に仮移転して気がついたけど、cvs版や、特にrc_5ではだいぶ動作が軽くなってます。「重い」と感じるときは、ページの更新時だと思います。更新中にタイムアウトになってしまうのは、xreaに限った事でもないみたいですからね。直近のCVS版の変更が、何か好影響を与えているのだと仮定した場合に思い当たるのは、現実的でない長さのGETメソッドに対して出力を打ち切る様になっている部分や、逆リンクの実装が(全文検索を回すのでなく)キャッシュを見る様になって極端に高速化している部分ですね。Webクローラーやワームに由来する負荷についてそれなりに打たれ強くなっているのではないかと思われます。編集の部分はいじっていませんから変化が無いでしょう。22:44:06};--cpanelに表示される負荷を見る限りでは、本当にスペックをもてあましてるって感じです。編集した後が重いというのは、更新と描画(?)を1回のリクエストでやってるからかもしれません。metaタグのリフレッシュを使った(2ちゃんねるの書き込んだ後のような)やりかたなら、1回でサーバーに送る命令を分散できるので、負荷対策にはなるかもしれませんね。結局、編集直後にタイムアウトしやすいというのは、変わりませんし。xreaでも問題ない気が・・・。全ファイルをオープンするので、ディスクアクセスが半端じゃないです。昔はstatic変数にキャッシュを持っていたのですが、1.4.5で抜けてしまっているので復活希望だったりします。get_filetime()やis_page()など。何か勘違いされていると思います。キャッシュは1.4.3までのPukiWikiが重かった一因で、実際にはPHPが既にファイルシステムに対するアクセスをキャッシュする機構をもっているため、存在する必要がないものでした(オーバーヘッドでした)。デフォルトの設定をどちらに倒すかはプロジェクトの判断にお任せします。[[BugTrack2/11]]につづく。13:04:07};--CPU負荷にほとんど変化がなくレスポンスは大幅に向上しました。&br;テキストファイルが100KB程の場合、圧縮すると17KBほどになり&br;低速回線がダウンロードにかかっていた時間が大幅に短縮され&br;結果的にApacheのプロセスが短くなり、CPU負荷はほとんどかかりませんでした。&br;&br;ref等で画像を表示している場合は圧縮対象から外す為の作業が必要です。