Seo tools

Neo Inspiration

  • Search

    • About Me

      • inspi 改め
        jakk@webアーキテクト(自称)
        php,javascript,seoなど
        得意技は extract();



  • Categories

  • Ranking

  • Comments

  • Others


  • Archive for 10 月, 2008

    phpでマルチスレッド

    水曜日, 10 月 29th, 2008

    またまた自作フレームワーク用に組み込みたかった機能の話

    特にfile_get_contentsなどの相手側の応答いかんで処理時間がかわるような場合
    同時にだーって流しておきたいなーとはおもったんですが、
    考えていたやりかたはモジュール版だと使えないということが発覚・・
    (pcntl_forkって関数)

    で今回みっけたのは curl_multi
    PHP curl_multi example of parallel GET requests

    注意点としては、各ハンドラが独自にキャッシュしてるから
    ハンドルを変更せず再度 curl_multi_exec しても
    トライせずにキャッシュを返すことかなぁ
    (その場合一旦ハンドラを解除して再セットすればOKらしい)

    なので、こんな感じでクラスを作って
    localhostのphpファイルを呼び出せば
    簡単にマルチスレッドでプログラムが動かせると。

    まあよっぽどのことがないと使わないとおもいますが。

    というかこれ、どこまでいけるんだろう。

    Class Parallel {
    
        public $result;
    
        public function __construct() {
        }
    
        public function execute($urlList = array()) {
            if (count($urlList) > 0) {
                $channel = array();
                $uniqueUrls = array();
                $uniqueUrls = array_unique($urlList);
    
                //マルチプロセスハンドラ
                $multiHandle = curl_multi_init();
    
                //URLに一つづつチャンネルを割り当てる
                foreach ($uniqueUrls as $k=>$v) {
                    $channel[$k] = curl_init($v);
                    curl_setopt($channel[$k], CURLOPT_RETURNTRANSFER, 1);
                    curl_multi_add_handle($multiHandle,$channel[$k]);
                }
    
                while (CURLM_CALL_MULTI_PERFORM == ($execReturn = curl_multi_exec($multiHandle,$isActive))) {
                }
    
                while ($isActive && $execReturn == CURLM_OK) {
                    if (curl_multi_select($multiHandle) != -1) {
                        while (CURLM_CALL_MULTI_PERFORM == ($execReturn = curl_multi_exec($multiHandle,$isActive))) {
                        }
                    }
                }
    
                if ($execReturn != CURLM_OK) {
                    return false;
                }
    
                $resultData = array();
                foreach ($uniqueUrls as $k=>$v) {
                    $curlError = curl_error($channel[$k]);
                    if ($curlError == “”) {
                        $resultData[$k] = curl_multi_getcontent($channel[$k]);
                    } else {
                        $resultData[$k] = ‘error’;
                    }
                    curl_multi_remove_handle($multiHandle,$channel[$k]);
                    curl_close($channel[$k]);
                }
    
                curl_multi_close($multiHandle);
    
                $this->result = $resultData;
                return true;
            } else {
                return false;
            }
        }
    
    }
    

    XML DB

    火曜日, 10 月 28th, 2008

    10万くらいのRSSをうまく管理するのはどうすっかなーと
    新しいシステムについてつらつら考えていたのだけれど、
    ふとXMLベースのDBってどうなんだろうと思い出して調査開始。

    キャッシュがきかない、トランザクションがきかない
    とかI/O周りの負荷が高すぎて
    結局具合のいいパーサかいてやるか
    一旦mysqlに格納しちまったほうがよさそうだなー

    と思いつつとりあえず使ってみた。

    Xprioriってのでテスト
    Xpriori

    ここらへんを参考にXquery(SQLの代わりに投げるDB用クエリ)をいじってみる
    Xquery

    ・・・
    スキーマレスDBっていうのは
    RSSのようにスキーマがガンガン変わるようなものを
    一括で管理するにはいいとおもったんだけど、
    どうも勝手がちがったw

    JOINとかは1ファイル1テーブルで、JOINはファイルを結合してくイメージだから・・
    あかんw10万ファイルをJOIN(実質MAX1000くらいなんだろうけど)
    とか気が遠くなるこれw

    10万ファイルをDBに格納してRSSを生成しなおすのと(こっちは格納コストが高い)
    ファイルとして保持して、Xqueryで生成するのと・・(こっちは生成コストが高い)
    うーん ちょっと簡単にはコスト計算できそうもないので、要検証。
    パーサ書くほうが楽しいしとりあえずやめよっかなーとか。

    余談だけどXqueryに関するこの記事をよんで
    めっちゃ面白そうだとはおもった
    http://d.hatena.ne.jp/stemy/20060708/1152385620

    DB分割とか

    月曜日, 10 月 27th, 2008

    大きい開発がはじまったので、
    作りためた自作フレームワークを完成させよう~

    と思ったんだけど、肝心のDB分割の部分がうまく整理できていないので、
    そこらへんのメモ。

    キーで分割するか、テーブルで分割するか

    ○テーブル分割
    ・IDテーブルはこのDBサーバ、blogテーブルはこのサーバみたいな。
     さらに細かくblogテーブルのこのカラムはこのサーバみたいなやり方もあり。

    ・パーティション・マップを用意してテーブル<>サーバのマッピングをする。

    ・色々JOINとかが超めんどい
    (そもそもその規模だとJOIN使うな的な話も多い)

    ・分割するなら例えばBlogテーブルのテキストカラムだけ
    外だしするとかクエリベースで切り貼りするイメージ。

    ・シームレスなラッパーは書くのがきつそう

    ○キーで分割
    ・単純にID1~100はこのサーバ 200~300はこのサーバみたいな。

    ・キーの決め方がハードコーディングになると汎用性がさがるけどリソースをうまく使いきれそう

    ・キーの決め方がアルゴリかましてるとID100を別サーバに移動みたいなことがきつい。
     だけどサーバ増設が伴っても比較的ラクに対応できそう。

    ・マッピングを使う どっかにID1はこのサーバって書いてく。
     このマッピングが書いてあるDBの負荷は大丈夫なん?

    ・シームレスなラッパーは書くのが楽そう

    ○タイムスタンプベース
    ・そこまで必要なサイトってDbいくつ必要なんだというw

    —-

    テーブルで分割の場合よりも、キーで分割のほうが
    サーバの拡張のイメージが付きやすいし、管理コストも楽そうだから
    こっちを採用予定。

    とりあえずログインサーバとメインDB1,メインDB2でわけようかな。
    キーで分割して、マッピング使用、ログインサーバでマッピングさせてしまう予定
    (ログインサーバの負荷がきになるけど)

    あ あと自作フレームワークは neo という名前に!
    (そういうとこだけ早いというw

    参考サイト
    http://www.itmedia.co.jp/enterprise/articles/0808/28/news013_1.html
    http://itpro.nikkeibp.co.jp/article/NEWS/20060330/233820/

    2008/11/22 03:41:15