BugTrack/28

Wikiファイルの増加による負荷の増大†

• ページ: BugTrack
• 投稿者: たらこせる
• 優先順位: 低
• 状態: 完了
• カテゴリー: 本体バグ
• 投稿日: 2002-06-26 (水) 20:29:01
• バージョン:

メッセージ†

HNSからの切り替えで900超過のファイル移動をおこなったところ、どのページにアクセスする場合もかなりの負荷がかかります。

• う・・・・。1.5ですね・・・・ -- ゆう 2002-06-26 (水) 20:35:48
• ロードマップ <- 1.5 -- ゆう 2002-06-26 (水) 21:37:10
• バックエンドにPostgreSQLとかMySQLとかだと楽なんですが、可搬性が低くなるんですよね。 -- ゆう 2002-06-26 (水) 21:37:39
• たしかsngさんも1.xの仕様が固まれば2.0で…という話がありましたね。 -- reimy 2002-06-26 (水) 21:44:18
• 海外のPHPで書かれたWikiEngineもSQLを使ってるものがけっこうあるようです。参照 -- reimy 2002-06-26 (水) 21:56:39
• いったん旧日記コンテンツを削ることにしようと思います。HNS2WIKIも1.5以降ですね。 -- たらこせる 2002-06-26 (水) 22:56:55
• とりあえずすぐにできることでいえば、skinファイルからスタイルシートを別ファイルにしてしまう。スタイルシートはキャッシュから読み込まれるから、少しは高速化する(わずかですが) -- reimy 2002-06-27 (木) 03:51:33
• 最新バージョン(CVSにあるRev1.4)のスキンをスタイルシート別ファイルにしたものを添付しておきます＞ゆう -- reimy 2002-06-27 (木) 04:00:51
• 使い方→pukiwiki.skin.ja.php、pukiwiki.skin.en.phpとdefault.ja.css、default.ja.cssをskinディレクトリに置いてください。default.ja.css、defalt.en.cssの転送はテキスト(EUC)で、パーミッションは644でOKです。 -- reimy 2002-06-27 (木) 04:04:14
• 解凍して従来のものと入れ換えるだけでOKです。単純に分離しただけですので表示はまったく変わりません。 -- reimy 2002-06-27 (木) 06:37:26
• データの管理にDBとファイルと選べるといいのかも。データの読み書きする部分をラッピングしちゃうのがいいのかな。 -- kawara 2002-06-27 (木) 11:22:34
• 1.5では各構造に分けてラッピングする予定です。WikiEngineもそこだけキレイに独立させたいし。 -- ゆう 2002-06-27 (木) 12:40:54
• とりあえずglobal変数をなくす方向で書き換えるつもりです。 -- ゆう 2002-06-28 (金) 03:06:16
• あと、高速化の方法としては表示をhtmlファイルで行なうという手もありますね。sngさんのところでも提案されてましたが。PHPでHTMLを生成して出力し、ページを読むときはhtmlファイルを読む。編集・更新のときだけPHPで行なう*1。これだとサーバーへの負荷も少なくて済みますし、HTMLファイルですから高速です。 -- reimy 2002-06-28 (金) 09:13:19
• うーん、静的html生成の場合、ページ内でリンクしている WikiName が消失してたとき感知できないんじゃないかと。更新時（というか消された時)に自分を参照しているページもチェックするようにすればいいのかな。消されない場合はデッドリンクにならないから問題ないですね。 -- とおりすがり 2002-06-30 (日) 14:43:53
• デッドリンクは編集に飛ぶからいいのでは？ -- reimy 2002-06-30 (日) 18:37:03
• ん～。たしかに致命的な事にはなりませんが、デッドリンクを示す「?」が出なくなるのはちと使いづらいかなと。。。 -- seagull 2002-06-30 (日) 18:54:23
• リンクされている全ページを書き換えるのは…むちゃくちゃ重くなりそう -- reimy 2002-06-30 (日) 19:12:14
• 書き換えられるタイミングは、すでに古くなったページを初めて閲覧した時でいいので、 -- seagull 2002-06-30 (日) 19:38:32
• 最悪でも現在と同じパフォーマンスではないかと。。 -- seagull 2002-06-30 (日) 19:39:52
• あー、ダメだ。メニューバーのrecentがあると依存関係広すぎて静的生成の意味が無くなる。。 -- seagull 2002-06-30 (日) 19:42:14
• おちついて考えると、あらかじめページ名(ファイル名)が判っているのに、なんでファイル数で負荷が左右されるんだ？ -- seagull 2002-06-30 (日) 19:51:31
• 横からすいません。PukiWikiのファイルを見つけるアルゴリズムがどうなっているのかはわからないのですが、全走査が原因ならばRDBの様にインデックスファイルを用意するのも手かと思います。ただ、インデックス更新の衝突が課題ですが… -- 木下牛 2003-02-12 (水) 09:13:33
  • 1.4で、ページ名の関連をRDBに格納して、全ファイルを走査する処理をなくす仕掛けを実験中です。 -- ぱんだ 2003-02-13 (木) 15:36:36
  • やはりRDB化ですか。レンタルサーバはなかなかRDB対応が少ないのでポータビリティという面ではちょっと落ちてしまいますね。 -- 木下牛 2003-02-15 (土) 00:46:48
    • PHPをインストールしているレンタルサーバーなら何らかのRDBはインストールされてると思うんだけどなあ。現状の速度ではもう限界にきてるので、改善されないようならそろそろPukiWikiをやめざるをえないなあと思案中。 -- reimy 2003-02-15 (土) 05:20:32
    • 私が探したときはPHPとRDBが使えるレンタルサーバって結構少ないし値段も高かったです。 -- 木下牛 2003-02-16 (日) 01:15:19
  • これは YukiWiki みたいに Wiki ページの格納方法を選べるようになるってことですか？ それとも RDB 必須になるってことですか？ 正直、必須になると抵抗感はかなり上がると思いますが。-- とおりすがり 2003-02-15 (土) 11:33:26
• よく考えたらインデックスファイルの更新のタイミングってページの追加・削除のときだけなのでインデックスファイルの悲観的ロックで更新の衝突を防いでもたいしたパフォーマンス劣化はないかもしれません。 -- 木下牛 2003-02-16 (日) 01:24:43
• sourceforge.jpでもMySQLが使えるので、ここでも実験できますよ。 -- reimy 2003-02-16 (日) 04:46:31
• 当方のレンタルサーバも DB は解放されていないので、DB は選択制にして欲しい、なぁ。 -- 未亜 2003-02-16 (日) 19:23:37
• BugTrack/763 負荷対策のまとめ -- 2005-04-14 (木) 20:58:46
• 開発日記/2003-02-17, BugTrack2/150 -- 2010-05-24 (月) 16:00:04

• BugTrack
• 開発版
  • リポジトリ
  • 開発日記
• :CategoryDev
  • PukiWiki2
  • PukiWiki/1.5
  • PukiWiki/1.4
  • PukiWiki/1.3
  • メーリングリスト
  • 開発談義
  • 雑談
• 開発者向け情報
  • Books
  • プラグイン

最新の16件