Studying HTTPFX取引所の照会とテクニカル、経済指標の見方等を解説していきます。
Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件
« Pathtraq 最新ランキング ガジェットを公開しました | メイン | Q4M (Queue for MySQL) 0.3 リリース » 2008年03月10日 高速なCometサーバを書いてみた件 もう昨年の２月になりますが、Comet について調査を行いました。その際の成果をまとめたスライドは既に公開していた (Comet の正しい使い方) のですが、同時に実際に作ってみた実装についても、オープンソース化することとなりました。コードは CodeRepos に置いておきますので、どうぞご覧ください。 (Revision 7754: /lang/perl/fastr) 使い方は example ディレクトリ以下を見ていただくとして、ベンチマークの結果とチューニング手法について、記録と記憶に残っている範囲からまとめておきたいと思います。 パフォーマンスについて まず、パフォーマンスに
Comet - Wikipedia
この項目では、Webアプリケーション技術について説明しています。その他のCometについては「コメット」をご覧ください。 この記事には独自研究が含まれているおそれがあります。 問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2009年5月） Comet（コメット）とは、Web アプリケーションを構築する際に利用される技術で、この技術を使うと、サーバで発生したイベントをクライアントからの要請なしにクライアントに送信することができる。 Comet はこのような通信を実現するための複数の手法をまとめた概念である。これらの手法はブラウザにプラグインを追加することなく、（JavaScript のような）デフォルトの機能で実現されるものである。理論的には Comet は、ブラウザがデータを要求する形の既存のウェブのモデルとは異なっている。実際は Comet
Lingr and Comet - 技術解説編:Kenn's Clairvoyance
さて、お待たせしました。いよいよCometとLingrについての技術解説です。 ■Comet解説 さて、まずはCometとは何で、どういう背景によって生まれたのか、についての解説から始めます。 まず前提として、Webアプリケーションにおいては、通信開始のトリガーは常にクライアント側が握っています。つまりURLを入力したりボタンをクリックしたときなどに通信が発生することになるわけですが、このようなアーキテクチャは、サーバ側で発生した変化をリアルタイムにクライアント側に通知することが原理的にできないことを意味します。 チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。 そのため、一定期間ごとにブラウザがサーバに
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
