タイトル

PukiWikiの耐久性テスト 2016

---

---

pukiwiki 1.5.1  動作テスト 2016

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

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

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

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

» 続きを読む

PukiWikiの耐久性テスト ２０１０

---

---

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については、将来廃止予定の構文を使っていると警告がでるだけで、とりあえず支障はないようだ。

【結論】

ローカルファイルに書式いれて、それに従って
HTML合成するツールは自前で作って持っているのですけど
欠点があって
・静的コンテンツなので、広告をいれかえにくい。
・更新すると再構築して転送するのが面倒
動的に静的htmlから内容抜き出して、
合成表示するツールも作ってはいますが、
汎用できる形にしていないので
ページが増えるとコードが肥大して困るかなぁ・・・
というかんじ・・・(-_-)
　zoopsだと　ユーザー登録なんかいらないし、速度が遅いし
プラグイン作るにも仕様がへんてこだし。
かといって blogだと　表示がいまいちだし・・・
で、きわめつけが、セキュリティホールがありそうで恐い。
二つを足してα引いて、β足して、みたいな
ミラクル動的HTMLが欲しいのですが
やっぱりないですねぇ・・・
ということで、
やはりローカルなＰＣのソフトと一緒で
if
　使い勝手が悪い or 使いたい物がない　or 買うと高い
then
「自分で作っちゃえ」
; 方針でいこうと思います。
　探したり　試行錯誤していることにたくさんの時間が・・・
最初から自分で作った方が早かったかもしれないです。
　ということで、　さくっと　サクサクっと
サクッと　のんびり作っていこうと思います。