PukiWikiの耐久性テスト ２０１０
執筆：2010/11/20
著作権:okamerin.com
pukiwiki 1.4.8 snapshot 動作テスト 2010 その１

今日の講義は、
PukiWikiの耐久性テスト

ホームページ代わりにコンテンツ管理として利用できないか
以前検証して動作に不安があったので、ホームページ代わりには不適との結果になったのですが、
数年経過したので、再度検証してみることにしました。

1.4.7のバグがあるのに安定版の更新が数年ないようなので
開発が停止していそうな感じですが、実用に耐えうる物でしょうか。

まず、圧縮ファイルの日付を見る限り、あまり進歩していなさそうな印象です。
期待できない感じです。

検証したい項目
  • 記事数増加に伴う動作速度との関係
    • 人気記事順　#popular プラグイン
    • 最新の更新　#recent プラグイン
    • 最終更新
  • ページナビゲータにした方がよさそうなもの
    • 一覧
    • ファイル一覧
  • タイムアウトしそうなもの(記事数が大量の場合)
    • 一覧
    • ファイル一覧
    • 単語検索
    • ページ更新
    • 画像
  • 共有サーバーで問題を起こしそうなところ
    • 画像を使ったページの同時アクセス
      画像も１アクセスとられてしまうので
      数人の同時アクセスで500エラーになりやすい
      refプラグインを改造し画像を静的にキャッシュして、サーバーにそれを使うように変更したほうがいい
  • その他いろいろ
  • PHP 5.3

記事数増加に伴う動作速度との関係

phpコード数行で、データの挿入、削除をループで行う物を作りテストしてみました。

MenuBar の内容
#popular(5,^(MenuBar|SandBox|FrontPage)$)
#recent(10)
#hr
RIGHT:&edit(MenuBar,noicon){edit};
#counter

トップページの表示にかかる時間を比較(2回実行)
   挿入ページ名 : Plugin/counter/test/_番号
   挿入データ：ページ(内容：ファイル名)、カウンタ(内容：番号)
(PukiWiki 1.4.8_alpha2)

挿入したペー ジ件数
表示にかかった時間
HTML convert time (秒)
popular
なし		 popular
あり
修正なし 修正あり
（パッチ）
1000件 0.131
0.137		 0.743
0.721		 (キャッシュなし)
0.279
0.295
(キャッシュあり)
0.219
0.268
5000件 0.157
0.142		 3.167
3.137		 (キャッシュなし)
0.426
0.380
10000件 0.163 6.253 (キャッシュなし)
0.731
10000件
(NTFS
フォルダ圧縮あり)		 0.239
0.275		 105.256
104.108		 (キャッシュなし)
1.274
1.249
(キャッシュあり)
0.292
　 ※PCのほかのタス クの影響で
多少時間が前後しています

NTFSフォルダ圧縮を使うと200件程度で、遅延が発生してとても使えるレベルではなかった。
1000件程度で、popularプラグインは遅くなるので、気になり始めたらキャッシュ機能を付加した方がいいだろう。

実験用に修正した物は、除外ページのパターンマッチで鈍足になってしまいます。
キャッシュがなくても １万件で1秒なので、キャッシュがなくても問題にはならないだろう。
コードを最適化すればさらに効率よくすることができる。

カウンタの問題は解決した。
しかし、ページが増えるとカウンタも比例してファイルが増えるのは、美しくない。
バックアップにも時間がかかることになる。
こういうどうでもいいデータは、すべてデータベースに格納すべきだろう。

次にページを更新をすると問題が発生した。
記事数に比例して、投稿完了までの時間が長くなる。
file.phpに問題があることがわかった。

　
ページの更新にかかる時間
(ストップウォッチを使用)
file.php:page_write,put_lastmodified
修正なし		 修正あり
200件 約1秒 -
1000件 約1秒 約1秒
5000件 約2秒 約1秒
１万件 約4秒
フォルダ圧縮あり
約50秒
約39秒		 約1秒
フォルダ圧縮あり
約1秒
#popular
#recent		 使用を停止 使用
条件
使用したページ MenuBar
アクション 未編集でページの更新クリック
その他 #counterあり

更新速度が遅くなったと感じ始めたらコードの修正が必要。
修正コードが必要な場合は、公式サイトにアクセスして最新版／パッチをゲットしよう。

埋め込み画像は、転送リソースを消費するので、
サーバーに実行数制限がある場合、数人のアクセスでサーバーエラーになる可能性があります。
また、低速の回線から接続した場合、タイムアウトになってしまうでしょう。
コードを修正して、画像表示用のキャッシュフォルダを用意すると改善できるだろう

【PHP】
   PHP 5.3については、将来廃止予定の構文を使っていると警告がでるだけで、とりあえず支障はないようだ。

【結論】
ページ(データ)数に比例して、ページ更新が遅くなります。
ページ内のプラグインによっては、さらに鈍化させます。
数人／分の訪問のプチホームページ程度なら、問題はないだろう。
動作を鈍化させることがあるのでプラグインを利用する際は注意が必要だ。
また、一覧は全部名前を列挙するので、改善した方がいいだろう。

しかし上記の問題は、
カウンタと日付データをSQLiteに同時複製した単純な修正で
このように速度の改善ができました。
SQLiteは、クラッシュしやすいのでMySQLなどを使えば安全です。

現状では、小規模ならホームページ代わりに、ならないことはない。
システムが単純なのでローカル環境で個人・社内のメモ帳 的な使用にはいいかもしれない。

外部に公開する場合は、セキュリティを考慮すると
普通に市販のHTMLエディタ(ホームページビルダーなど)で書いた方が安全であり管理の手間も大幅に軽減できるしょう。

小規模の企業サイトでは、ページ数が少ないためcssとjsで外観は簡単に変更できるので、
見栄をはって管理と手間がかかりセキュリティリスクのあるCMSを使うメリットはない。
CMSの維持管理に費用や時間をかけれない場合や、Web IT管理者のおけない弱小企業は、
Webハッキングに強い静的ページが作れるホームページビルダーなどを強くお勧めする。
(外注費や人件費などを考えるとHTML編集アプリ代のほうがお得であることは言うまでもない)

動的コンテンツがいい場合やページが数百になる場合は、
ブログなどコンテンツ管理システム系のソフト（wordpress , joomlaなど）やMediawikiのほうがいいだろう。
困ってからデータコンバートして移行するのもいいが手間と時間を考えると
最初から耐負荷仕様のものを選んだ方が賢明である。