非同期プロトコルのクライアント - sdyuki-devel
非同期プロトコルとは、サーバーから返ってくる応答が、必ずしも要求した順番通りに返ってこないプロトコル（ソース無し。オレオレ定義）。 順不同で返ってくる応答と要求を対応づけるのはクライアントの仕事で、典型的には要求の中にシーケンス番号を入れておき、サーバーは要求と同じシーケンス番号を応答の中にも含める。 例：MessagePack-RPC 非同期プロトコルの特徴： イベント駆動型のサーバーの場合、サーバーの実装が簡単になる 同期プロトコルだと順番を揃えてから返さないといけない。サーバーの実装が（要求１つに対してスレッドを割り当てて処理するのではなく）ソケット１つに対してスレッドを割り当てて処理する方式だとあまり関係なくて、特に実装は簡単にならない。 処理が重い要求と軽い要求を続けて送っても、重い要求に詰まって後の応答が返ってこなくなることが無い 同期プロトコルだと、応答を送り返すにはその前の
アプリケーションサーバで非同期処理をするかしないかの分水嶺 - kazuhoのメモ置き場
mala さんのまとめは、わかりやすいなぁと思いました。ただ、傍論なんですが、 既存のマルチスレッド/マルチプロセスのサーバーで、常にリクエスト処理待ちの待機しているプロセスがある状態の場合は(+その並列数でCPUのパフォーマンスが劣化しない場合は)、パフォーマンスが劣化することは無いので非同期処理を使う必要が無いでしょう。実際のところ「1秒あたりに来るリクエストの最大件数」というのは予測できないので、(long-pollやstreamingをしない)普通のアプリケーションにおいても非同期処理の導入はメリットになる(と、考えている)。 非同期アプリケーションサーバーの要件と必要性について - 金利0無利息キャッシング – キャッシングできます - subtech はちょっと気になった。私見では、非同期処理 (スレッド内での I/O 多重化) を行うべきか否か、は、クライアントとの TCP
指向性メモ::2009-07-08::JS_Randezvousを高速化した
cho45さんがJSDeferredを高速化した手法を少し改良して、JS_Randezvousも高速化してみた。 具体的には、キューイングが遅いsetTimeout（引数に0を渡しても大分待たされる）の代わりに、Imageオブジェクトのイベントを使う。 Imageオブジェクトの本来の用途は画像のプリフェッチだと思われる。srcプロパティを設定すると、オブジェクトをdocumentオブジェクトに追加しなくても自動で読み込み処理が開始されるため、documentオブジェクトに余計なノードを追加しなくても非同期なイベント（loadやerror）を発生させることが出来る。読み込む画像ファイルのURLを空のdataスキームにすると、少なくとも現行のブラウザではsetTimeoutより数倍速く非同期処理を行うことが出来る。 src属性に空のdataスキームを渡すと、大体のブラウザは画像ファイルを開くこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
