日記帳
本ページはプロモーションが含まれています
カテゴリー
Links
blog(ブログ)マスター
アンドロイドの巣
ゼロから始めるベランダ菜園
タイトル
ラジコン
2024年5月
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

アーカイブ

2010年11月 のアーカイブ

phpのバグ dirname関数は日本語対応未熟(php 5.3)

php6は、正常に動作しましたが

現行のバージョンは以下のコードでエラーが起きます
UTF8の文字に対してdirnameは、問題ないですが
現状 utf8でファイル名を取得できるのか?

// bug: php 5.3.3 , 5.2.14
// (php6:ok)

mb_language("ja");
mb_internal_encoding("SJIS");

$path = "c:\\tmp\\".chr(0x83).chr(0x8b); // japanese common charset (katakana ru)
$file = $path."\\test.txt"; // c:\tmp\ル\test.txt
printf(" \$file : %s\n" , $file);
printf(" dirname(\$file) : %s\n\n" , dirname($file));

if ( strcasecmp($path , dirname($file)) != 0 ) exit(" error : bug\n");

print "ok \n";
?>

» 続きを読む

2010年11月10日 改修により 速度は、正常化した。

と思ったのもつかの間

また 激 遅になっている

どうしうようもない クソ サーバー
PukiWikiの耐久性テスト 2010

執筆:2010/11/20
著作権:okamerin.com

pukiwiki 1.4.8 snapshot 動作テスト 2010 その1

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

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

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

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

検証したい項目
  • 記事数増加に伴う動作速度との関係
    • 人気記事順 #popular プラグイン
    • 最新の更新 #recent プラグイン
    • 最終更新
  • ページナビゲータにした方がよさそうなもの
    • 一覧
    • ファイル一覧
  • タイムアウトしそうなもの(記事数が大量の場合)
    • 一覧
    • ファイル一覧
    • 単語検索
    • ページ更新
    • 画像
  • 共有サーバーで問題を起こしそうなところ
    • 画像を使ったページの同時アクセス
      画像も1アクセスとられてしまうので
      数人の同時アクセスで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万件で1秒なので、キャッシュがなくても問題にはならないだろう。
コードを最適化すればさらに効率よくすることができる。

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

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

 
ページの更新にかかる時間
(ストップウォッチを使用)
file.php:page_write,put_lastmodified
修正なし
修正あり
200件 約1秒 -
1000件 約1秒 約1秒
5000件 約2秒 約1秒
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のほうがいいだろう。
困ってからデータコンバートして移行するのもいいが手間と時間を考えると
最初から耐負荷仕様のものを選んだ方が賢明である。


wget 1.12 for windows

執筆 2010/11/17

今日のお題
wget 1.12 と wget 1.11.x for windows
を検証してみましょう

ダウンロード
    ソース: gnuのサイトにあります。
    バイナリ: 配布サイトまたは、自分で構築
    wget-1.12-win32.zip

1.11.4から1.12への主なポイント
  • ソースレベルで前版とかなり違う
  • CSSがサポートされました
  • Internationalized Resource Identifiers (IRIs, RFC3987)のサポート
    libidn と libiconvが必用らしい。
  • windows : 1.11.4までは、wopenではなくfopenで書き込みのためutf8のurlは保存時に壊れていました。
    1.11.4: url.cのurl_file_name関数のfnameの修正で対応できます。
    ※unix環境では、1.11.4でも問題はないようです。 
  • そのままでは、Visual C++でコンパイルできなくなっています。
    wget-1.12/windows/READMEを参照

  その他詳しくは、wget-1.12/NEWSを参照

【構築へのヒント】
未改善点
・不完全なアトリビュートタグで失敗する 例<img src="a.gif" alt=>
  パッチ:  src/html-parse.c @@ -944,7
           /* <foo bar=> */
     -    goto backout_tag;
     +    continue;
・htmlコンバートオプションで失敗するらしい
  パッチ:  src/retr.c  @@ -828,7
    -    if (redirection_count && 0 != strcmp (origurl, u->url))
    +    if (0 != strcmp (origurl, u->url))

【msvcrtのdllが邪魔という場合】 埋め込みで構築します
  windows\Makefile.src
  +LDFLAGS    = $(LDFLAGS) /NODEFAULTLIB:msvcrt
 このオプションになっていないこと自体 タコ仕様。

【opennsslを内蔵したい】 埋め込みで構築します
  環境変数:LIBにopennsslのライブラリ(.lib)へのパスを加えれるとよい
  opennsslの欠陥のたびに構築しないでいいように
  通常は、動的ライブラリへのパスを設定し、動的リンク(dll)をお勧めします
  静的リンクもできます。

【考察】
  • このプロジェクトの特徴 安定版の修正版がなかなかない。
    マルチOSに対応した手軽な代用品があればいいのですけどね。

  • Unix?から派生したプロジェクトなのでwindowsサポートが弱い
    Unix環境を持っていれば、そちらの方がgetに失敗しない可能性が高い。
    しかしUnix環境はウイルスチェックが甘いので気をつけましょう。

  • その他見つけた欠陥
    • 特殊ファイル名を拒否しない
      DOS の予約語 (nul、aux、con、com1-9、lpt1-9, prn など)
      吹っ飛ぶ例:http://localhost/nul
      アドレスによっては、周辺機器に悪影響がでる可能性があります。
      「Naming a File」(http://go.microsoft.com/fwlink/?LinkId=76838) を参照してください。
      要点は信用できないサイトをwgetでgetしないこと ということ です。
      問題箇所は、url.cのurl_file_name関数あたりでしょうか。
      ※unixやcygwin版は普通に動くようです

  • FATシステムへの書き込み(NTFSしか使っていないので検証不能)
    1.11系では、FATシステムでは、@関係で失敗していましたが1.12系はどうなんでしょう。
    命名規則が同じなら落ちるでしょう。

  • wgetからサイトを守る方法
    • useragentで拒否
    • useragentを偽装した場合
    • robots.txt
    • ipやhostで遮断
  • 保存ファイル名を安全に
    1.11系までにあったファイル名の文字化け類が直ったといっても安全ではない。
    はやりのutf8だろうとか決めつけは厳禁です。
    %16進数のurlは、欧文、sjis、euc、utf8なのかはっきり言って短いとコードページの区別がつきません。
    パッチをあてて 1文字につき2バイト+数バイトかかってしまうが、総パス名の制限260を減らしてでも、
    一部のファイル名 及び 英数字と一部の記号以外は、16進数文字に強制変換してしまうほうが安全かもしれない。
    utf8の命名フォーマットから外れ+上記の条件で強制変換というルールもいいと思います。
    url.cのurl_file_name関数のfnameの修正で対応できます。
【結論】
 中途半端な実装のツール。
   とりあえず、windowsなら簡単に構築できるパッチをあてた 1.11.4でもいいと思う。

sqlite2からsqlite3に移行していると
いくつかの不具合を発見してしまった。
とりあえず、教えたけど 直るかは不明。
ソースを10分くらい解析すればパッチくらい作れるけど
レンタルサーバーでは通用しないというか面倒なので
対処法で解決するほうが無難。

sqlite3のSELECT 文 評価の際の内部バグ。

一つ紹介しておこう

"列名"が必ず""列名""でくくられて変更されてしまう欠陥。
もし、遭遇した場合は、
回避するには、SELECT "列名" as '新しい名前'で回避するしかない
"列名"を使い countやsumなどを使った場合に注意が必要だ。
※version2には、この欠陥は存在しない


追記
 移行完了
 確かに、説明にあるようにDBファイルが小さくなって速くなった気がする。

 また今後、ドライバ関数の変更に振り回されないように
共通の独自クラスを作って、その中で、PDOとSQLite3クラスを判別して処理するように工夫をした。
 今後なにか別のクラスが発生した場合は関数10個程度に、追加・書き込みするだけで済む。
 SQL文とその関数を修正しなくて済むようになったので、かなりいい。
公式サイトのformatchng.htmlには、2と3は、完全に互換性がないと書いてあります。
ということで、変換が必要になります。

公式サイトから、sqlite.exe sqlite3.exeをダウンロードします
(※sqlite.exe(sqlite-2_8_17.zip): ソース sqlite-2.8.17.tar.gz


コマンドプロンプトなどで
変換するコマンド
直接生成する場合
sqlite.exe old.db .dump | sqlite3.exe new.db

一度テキストに保存したい場合
sqlite.exe old.db .dump > old_db_dump.sql
ここで、必要に応じて、old_db_dump.sqlを修正します
sqlite3.exe new.db < old_db_dump.sql

※問題点
sqlite.exe(2.8.17) のダンプがキーワードをエスケープしない欠陥があるので
定義済みキーワードを使ったテーブル、列名などがある場合、
取り込みでエラーを起こす可能性があります
その場合、一度テキストにダンプして一括修正後、取り込みが必要になります
sqlite3.exeのダンプでは、問題ないようです。

例 sqlite.exe のダンプ: INSERT INTO item VALUES(1);
例 sqlite3.exe のダンプ: INSERT INTO "item" VALUES(1);

例: create table "where" (id text);
INSERT INTO "where" VALUES(1);

追記
sqlite.exe(sqlite 2.8.17)のパッチ

sqlite-2.8.17-47fee16ba9bd8ab2.diff
--- SQLite-47fee16ba9bd8ab2/src/shell.c 2007-01-08 16:20:28.000000000 +0900
+++ SQLite-47fee16ba9bd8ab2/src/shell.c 2010-11-04 23:00:00.000000000 +0900
@@ -421,7 +421,7 @@
p->zDestTable = 0;
}
if( zName==0 ) return;
- needQuote = !isalpha(*zName) && *zName!='_';
+ needQuote = *zName!='_';
for(i=n=0; zName[i]; i++, n++){
if( !isalnum(zName[i]) && zName[i]!='_' ){
needQuote = 1;

追記: 2011.12
バイナリデータを含んでいた場合、DUMPに失敗することがわかりました。
patch2を作りました。
別記事になります。
sqlite patch p2
で検索してください。


PR

[PR]