PukiWikiの耐久性テスト 2016

2016-06-05 23:00

執筆：2016/06/06
著作権:okamerin.com

pukiwiki 1.5.1 動作テスト 2016

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

前回の動作テストから6年が経過しました
前回の記事は →　こちら PukiWikiの耐久性テスト 2010

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

実用に耐えうる物でしょうか。

コミットログを見る限り前回からあまり進歩していなさそうな印象です。
期待できない感じです。

検証したい項目

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

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

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

MenuBar の内容

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

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

挿入したページ件数	表示にかかった時間 HTML convert time (秒)
	popular なし	popular あり
		修正なし	修正あり（パッチ）
1000件	0.020 -0.040	0.600	(キャッシュなし) 0.029
5000件	0.020 -0.040	2.777	(キャッシュなし) 0.029
10000件	今回は、テストしませんでした。
	※PCのほかのタスクの影響で多少時間が前後しています

popularプラグインを組み込まない場合の速度が前回より早くなったようです。

recent,counterの処理を変更したのでしょうか。

次にページを更新をすると時間がかかる問題は直ったでしょうか？

使用したページ

MenuBar

#recent
#counter

#popular
#recent
#counter

1000件

0.020
-0.040

0.563 秒

5000件

約2.777 秒

popularはファイル総当たり検索しているので、修正されていないようですね。
更新速度が遅くなったと感じ始めたらコードの修正が必要。
修正コードが必要な場合は、公式サイトにアクセスして最新版／パッチをゲットしよう。

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

【PHP】
以前の管理者の時は、長い年月まったく更新がなかったが
2015年あたりからpukiwikiの管理者が変わってから、PHP 7.0まで動くように改善したようだ。

【結論】

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

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

データベース保存式に変更すれば格段にいいソフトになれるだけに残念な仕様だと個人的には思います。

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

外部に公開する場合は、セキュリティを考慮すると
数十ページ程度なら

普通に市販のHTMLエディタ(ホームページビルダーなど)で書いた方が安全であり管理の手間も大幅に軽減できるしょう。

小規模の企業サイトでは、ページ数が少ないためcssとjsで外観は簡単に変更できるので、

見栄をはって管理と手間がかかりセキュリティリスクのあるCMSを使うメリットはない。

CMSの維持管理に費用や時間をかけれない場合や、Web IT管理者のおけない弱小企業は、
Webハッキングに強い静的ページが作れるホームページビルダーなどを強くお勧めする。

(外注費やセキュリティにかかる人件費などを考えるとHTML編集アプリ代のほうがお得であることは言うまでもない)
HTMLで静的コンテンツなら、アップロードパスワードの管理さえできていればハッキングに合うことはない。

wiki形式だと体制は統一できますが、少し文章が長くなるとピンポイントの修正がしにくいので、wikiではなく、htmlとして直接ワープロ感覚で編集できるアプリをお勧めします。

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

ブログ内　関連記事: PukiWikiの耐久性テスト 2016

　無料などオンラインゲーム一覧表　

このページの上へ▲

ブログ内　関連記事: PukiWikiの耐久性テスト 2016

トラックバック

トラックバックはありません。

タイトル

Sidebar