Choose your virtual waiting room wisely with 6 critical considerations & a 20-point checklist. Get free guide×
Apache Kafka More than 80% of all Fortune 100 companies trust, and use Kafka. Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. Manufacturing 10 out of 10 Banks 7 out of 10 Insurance 10 out of 10 Telecom 8 out of 10 10/10 Largest insurance
メッセージキュー について書いている連載の続きとして、今週末は分散型メッセージングを実行するための様々なライブラリを詳細に分析していきたいと思います。今回の分析では、APIの特性、デプロイメントやメンテナンスの容易さ、そしてパフォーマンスの質を含めて2、3種類の異なる側面に着目します。メッセージキューは2つのグループに分類できます。ブローカレス(brokerless)とブローカード(brokered)です。ブローカードなキューはエンドポイント間に何かしらのサーバを挟んでいますが、ブローカレスなメッセージキューは、メッセージ送信の際でも間に何も挾まないP2Pです。 今回分析するのは以下のシステムです。 ブローカレス nanomsg ZeroMQ ブローカード ActiveMQ gnatsd Kafka Kestrel NATS NSQ RabbitMQ Redis 取り掛かりとして、ほぼ間違
Node.jsでWebアプリを書いてるんだけど別に大量のリクエストをさばくわけでもないしWebSocketも使ってないし、じゃあなんでそんなことしてんの、という話。 まず結論だけ書くと、 並列度が低くてよいが長時間かかることが確定的な処理を非同期的に走らせる必要がある場合、普通はそのような用途でもJobQueue/Workerを使って構成するがそういうのは管理も面倒だしインストールも面倒くさくなるのであんまりやりたくない。Node.jsなら普通のWebアプリケーションフレームワークだけでラクに書けていいんじゃね? というひとつの提案です。 同期実行のケース 普通Webアプリケーションフレームワークというのは、一連の処理はクライアントにレスポンスを返すことで完了する。そしてひとつのプロセス/スレッドはリクエストをディスパッチされてからレスポンスを返すまでがそのリクエストに占有される。 ここで
ØMQ(zeromq)について簡単に調査したのでメモ。元ネタはØMQ - The Guide。 概要 N-N通信を実現する、socket API風軽量メッセージングライブラリ。 自動的な再接続や、メッセージのキューイングを行ってくれる。 複数のメッセージングパターンと呼ばれるものを組み合わせることによって、柔軟なメッセージ配信を行うことができる。 ライブラリについて socket APIライクなC APIを持つ。以下socketは、zeromqのsocketを指す。 zeromqはコンテキストというものを通じて使う。1コンテキストに、I/Oスレッドが1つ割り当てられる。基本1プロセスに1コンテキストでOK。複数のcontextを持つことはできるし、その場合は同じ個数のI/Oスレッドが走る。 zeromqのsocketは、プロセス内通信(スレッド間通信など)、プロセス間通信、TCP、UDPマ
Summary and Overview One of the infrastructure tools that we've identified for the future internal architecture of Second Life is messaging. Message queuing systems allow systems that send messages to not have to worry about how they will be delivered, and allow consumers of messages to gather whichever ones interest them, at their own pace. Ideally we'd have a completely scaleable system that cli
ご存じのとおり、App EngineのJVM(App Server)はクラスタ化されていて負荷分散される――というのがGoogleの説明です。しかし、WebブラウザからApp Engineに届くHTTPリクエストや、Task Queueのタスクによって呼び出されるHTTPリクエストは、実際にどのような感じで複数のJVMに配られるのでしょうか? どれくらいの量のリクエストが届いたとき、何台のノードに負荷分散される? 負荷分散のアルゴリズムは?(単純ラウンドロビン、sticky session/session affinity、負荷状況に応じた転送など) 新しいJVMの追加や、既存のJVMの削除のタイミングは? これらについてはGoogleから情報が公開されておらず、謎です。そこでApp Engine利用者の皆さんが実際の経験やテストを通じて情報を交換しながら想像たくましくするしかないわけです
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く