overlastのブックマーク - はてなブックマーク

Flashでグラフ(XML/SWF Charts)

# あおり気味のタイトルに変更:D Gigazine:　Flashできれいなパイチャートや円グラフを無料で作る「amCharts」これよりカッチョイイやつを昔ぴろさんから教えてもらったのでご紹介. XML/SWF Charts http://www.maani.us/xml_charts/index.php SwfにXMLの形でデータを渡すことで,多彩なグラフを書くことができる. ギャラリーは↓.パイチャート,円グラフ,棒グラフなどの各種グラフはもちろん,モーションつきのグラフとかも作れる(ギャラリーの各をクリックするとXMLのコードが見られます). http://www.maani.us/xml_charts/index.php?menu=Gallery ライセンスはこのあたり http://www.maani.us/xml_charts/index.php?menu=License

overlast 2006/12/29

リンク

AsyncIOについて(その1) - 最速配信研究会(@yamaz)

最近のOSにはAsyncIO(AIO)という新しいI/Oの仕組みが導入されているようだ.lighttpdの次期バージョンではAIOを導入することで8割もパフォーマンスが上がったようで非常に興味深い. またあちこちのBlogを見る限りNonBlockingI/OやNonBlockingI/O+シグナルとAIOが混同されている気がしたので,それら整理してみたい. はじめに I/O処理であるシステムコールのread/writeは対象がディスクだったり,ソケットだったりデバイスだったりするわけだが,通常これらのIO処理はCPU処理やメモリ処理に比べ非常に遅いことが知られている. 通常readが行われるとreadが終わるまで,永遠に処理は戻ってこず,プロセス的には待ち状態になってしまう.これは「Blocking」と呼ばれる. 遅いディスクやデータがいつ来るかわからないソケットなどに対するIO処理では

overlast 2006/11/23

aio
linux

リンク

AsyncIOについて(その2) - 最速配信研究会(@yamaz)

AsyncIOについて(その1)の続き. NONBlockでIO処理をする方法としてselectとシグナルを使う方法があるというのが前回の話だったが, selectはselectよりkqueue,epollで述べたとおり, ビジーループがかかるためあまり効率はよくなく,シグナル方式は制約があるためあまり使い勝手がよくない. というわけで新しく出てきたのがPOSIX Asynchronous I/O(AIO)という機構だ. これはIOのwaitをイベントドリブン形式にしてビジーループをなくそうというものだ. プログラムの流れとしては下記のようになる. 1. 対象となるファイルディスクリプタにシグナルハンドラもしくはイベントハンドラを登録しておく 2. aio_read/aio_writeを呼び出すと制御はすぐにユーザに戻る. 3．対象のファイルディスクリプタの処理が終わると登録されていたハン

overlast 2006/11/23

aio
linux

リンク

squid2.6のCOSSの話(その２) - 最速配信研究会(@yamaz)

squid2.6のCOSSの話の続き COSSのパフォーマンスのよさに関して「俺だまされてない?」というモヤモヤ感が高かったんだけど,あちこちの方々と議論した結果これが正解だろうという結論に行き着いた. ありがとう！＞あちこちの方友人との会話. yamaz: おっすおっす。いる？ xxxxx: お久しぶりです! yamaz: squid2.6のCOSSって知ってる? xxxxx: 初耳です。＜COSS yamaz: http://blog.nomadscafe.jp/archives/000705.html yamaz: http://wiki.squid-cache.org/SquidFaq/CyclicObjectStorageSystem yamaz: このあたりの話なんだけど、 yamaz: なぜコレが速いかっていう見解って持ってる? xxxxx : 3年ぐらい前、apacheを

overlast 2006/10/30

squid

リンク

「コネクションプーリング都市伝説」はほんとに都市伝説?（その3) - 最速配信研究会(@yamaz)

前回のシリアル/パラレル処理の視点に立ってコネクションプールについて考えてみたい. コネクションプールが遅いとははてなおやさんが考察しているように普通にmod_perl でコネクションプールを素直に張るとコネクション数が爆発する. 図にすると図1のような感じで個々のapacheがコネクションを複数持つので,サーバ台数が増えるとコネクション数が飛躍的に増えることがわかると思う. 図1 コネクションが爆発してる様子(正直書くのも大変) コネクション数が増えると単純にコネクションを維持するコストも増えていくので，このあたりが「コネクションプーリング都市伝説」の根拠になっていると思われる. これはこれで全くその通りで間違いない. さて,ここでもうちょっと大きな視点に立って,クライアント<->サーバ間の通信路が 1個の伝送路をパケットによって多重化しているととらえてみたい.そうするとここでシ