Sidebar |
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のバグがあるのに安定版の更新が数年ないようなので 開発が停止していそうな感じですが、実用に耐えうる物でしょうか。 まず、圧縮ファイルの日付を見る限り、あまり進歩していなさそうな印象です。 期待できない感じです。 検証したい項目
記事数増加に伴う動作速度との関係phpコード数行で、データの挿入、削除をループで行う物を作りテストしてみました。
トップページの表示にかかる時間を比較(2回実行) 挿入ページ名 : Plugin/counter/test/_番号 挿入データ:ページ(内容:ファイル名)、カウンタ(内容:番号) (PukiWiki 1.4.8_alpha2)
NTFSフォルダ圧縮を使うと200件程度で、遅延が発生してとても使えるレベルではなかった。 1000件程度で、popularプラグインは遅くなるので、気になり始めたらキャッシュ機能を付加した方がいいだろう。 実験用に修正した物は、除外ページのパターンマッチで鈍足になってしまいます。 キャッシュがなくても 1万件で1秒なので、キャッシュがなくても問題にはならないだろう。 コードを最適化すればさらに効率よくすることができる。 カウンタの問題は解決した。 しかし、ページが増えるとカウンタも比例してファイルが増えるのは、美しくない。 バックアップにも時間がかかることになる。 こういうどうでもいいデータは、すべてデータベースに格納すべきだろう。 次にページを更新をすると問題が発生した。 記事数に比例して、投稿完了までの時間が長くなる。 file.phpに問題があることがわかった。
更新速度が遅くなったと感じ始めたらコードの修正が必要。 修正コードが必要な場合は、公式サイトにアクセスして最新版/パッチをゲットしよう。 埋め込み画像は、転送リソースを消費するので、 サーバーに実行数制限がある場合、数人のアクセスでサーバーエラーになる可能性があります。 また、低速の回線から接続した場合、タイムアウトになってしまうでしょう。 コードを修正して、画像表示用のキャッシュフォルダを用意すると改善できるだろう 【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への主なポイント
その他詳しくは、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)をお勧めします 静的リンクもできます。 【考察】
中途半端な実装のツール。 とりあえず、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 で検索してください。 |
Sidebar |