gRPC を使って1万接続を達成するまでの話
先日、Wata で１万接続を達成した という記事を書きましたが、gRPC で1万接続するにあたって引っかかったところを纏めました。 Wata サーバは簡単に言えば PubSub サーバです。今回達成したのは Publisher が 1 で Subscriber が 10,000 の配信です。Wata の詳細については Wata プロジェクトについて を参照してください。 gRPC C++ の非同期 API をストリーミングで扱う方法が分からない本番での Wata クライアントは Unity のアプリケーションになるわけですが、テスト時に１万の Unity アプリケーションを立ち上げるのはかなり辛いものがあります。 なので gRPC で通信するテスト用の Wata クライアントを書くわけですが、少ない台数でやるためには、1台で大量の接続を捌く必要があります。 1スレッド1クライアントだと死ぬ
JavaScriptのStreams APIで細切れのデータを読み書きする
近年、PCに搭載されるメモリは爆発的に増えました。16GBや32GBのメモリが搭載されているのが当たり前の時代です。性能の制限が強いスマートフォンですら4GBほど搭載していることがあります。ストレージの読み書き速度もどんどん加速し、昔では扱えなかったようなデータ量をリアルタイムで処理できます。インターネット回線も同様に大量のデータを扱えるようになりました。 しかし現実的な大きさのデータを一度に扱おうとすると、現代でもそれなりに処理時間がかかります。ユーザはレスポンスに対して敏感で、反応が0.1秒でも遅れるとストレスを感じます。しかし時間がかかるものはかかるのです。この問題は一見どうしようもないように思えます。 そこで登場するのが「データを細切れにして処理する」というコンピュータにおける万能の薬です。細切れにして逐次処理すれば、少しずつデータを処理することができ、素早いレスポンスを実現するこ
uu59のメモ | Sinatra 1.3で追加されたstreamのHTTP解剖学
注：rack 1.3.3以前だと落ちます。rack 1.3.4以上にアップデートしましょう。 Sinatra 1.3でstreamヘルパーが追加された。 require "rubygems" require "sinatra" get '/' do stream do |out| out << "It's gonna be legen -\n" sleep 0.5 out << " (wait for it) \n" sleep 1 out << "- dary!\n" end end get '/normal' do sleep 1.2 "normally response" end 全部の処理が終わるまで待って一気にレスポンスを返すのではなく、out << "string"のように逐次レスポンスを返す。なお、これの実装はRails 3.1で追加されたものやPHPのデフォルトの挙動、Tw
Twitter Streaming APIをRubyで試してみる - しばそんノート
Streaming APIとは TwitterのStreaming APIをご存知でしょうか。 Twitter API Wiki / Streaming API Documentation 2009年4月頃から試験的に公開されているAPIなので、ご存知な方も多いと思います。2009年8月現在でまだαテスト中ですが、これを利用すると、push型でリアルタイムに情報を受け取ることができます。 TwitterのAPIは基本的にpull型なので、クライアントが能動的にリクエストを発行しなければ情報を受け取ることができません。しかし、1時間あたりのリクエスト回数、1リクエストあたりの最大データ数など、APIには様々な制限がかけられていますので、例えばリアルタイム性の必要なプログラムや、大量のtweetsが必要な統計プログラムなどの用途で通常のAPIを利用するのは厳しいものがあります。 そのような時は
Flying faster with Twitter Heron
We process billions of events on Twitter every day. As you might guess, analyzing these events in real time presents a massive challenge. Our main system for such analysis has been Storm, a distributed stream computation system we’ve open-sourced. But as the scale and diversity of Twitter data has increased, our requirements have evolved. So we’ve designed a new system, Heron — a real-time analyti
Handling five billion sessions a day – in real time
Since we first released Answers seven months ago, we’ve been thrilled by tremendous adoption from the mobile community. We now see about five billion sessions per day, and growing. Hundreds of millions of devices send millions of events every second to the Answers endpoint. During the time that it took you to read to here, the Answers back-end will have received and processed about 10,000,000 anal
Twitter Streaming API Architecture
Follow a Tweet from creation to timeline and Streaming API delivery. The design of streaming within Twitter is influenced by the entire Twitter architecture, the direction of the platform, data syndication policies and Quality of Service requirements. We'll discuss these influences and our system implementation.Read less
第2回 大量トラフィックを支えるインフラ～独自プロトコル、ファイルシステムの実装もいとわない！～ | gihyo.jp
ドワンゴのエンジニア魂 第2回大量トラフィックを支えるインフラ～独自プロトコル、ファイルシステムの実装もいとわない！～ 大量のユーザーを抱える「ニコニコ動画（ニコ動）」「ニコニコ生放送（ニコ生）」をさらに進化させるべく、ドワンゴでは土台となる基盤を見直し、大幅なアップデートを実施した。ドワンゴのエンジニアである原耕司氏（写真1）、太田健氏（写真2）、川平航介氏（写真3）の3名にお話を伺い、プロトコルや分散ファイルシステムまで独自に開発したという、このプロジェクトの真相に迫った。 将来のサービス拡充に向けて土台を整備 ――今回、サービスの基盤部分を大幅に刷新された理由は何でしょうか。 原：ニコ動は、サービスの提供開始から時間が経ったことで裏側のコードが複雑になっており、これから新たな機能をバンバン追加するのが厳しい状況になっていました。そこで、将来的なサービス拡充に対応で
リアルタイムとバッチの違い - kuenishi's blog
昨日、分散DB本読書会のあとに品川のラーメン屋でリアルタイムとは何ぞや〜みたいな話になった。自分の思いついたポエムをここに書いておこう。現場の問題とはあまり関係がない。 Stream Data Processing: A Quality of Service Perspective (Advances in Database Systems)という本によれば、DSMS (Data Steram Management System) とDBMS (Database Management System)の違いは、クエリを発行するデータ集合の性質にある。つまり、DBMSは今ある有限のデータに対して操作を行うための仕組みで、DSMSはこれからやってくる無限のデータに対して操作を行うための仕組みと定義されていた。このDSMSというやつは、古式ゆかしいストリーム処理システムのことで、まあいわゆるCEP
HLSについて知っていることを話します
SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】DeNA
ASCIIcasts - “Episode 266 - HTTPストリーミング”
266: HTTPストリーミング (view original Railscast) Other translations: Other formats: Written by Naomi Fujimoto 今回のエピソードでは、引き続きRails 3.1の最初のベータ版の機能を紹介します。今回はHTTPストリーミングを見ていきましょう。この話題はRuby on Railsブログのポストでも詳しく取り上げられているので、まずはその記事を読むことをお勧めします。ここではRailsアプリケーションでの設定方法と、使用時に発生する潜在的問題について説明します。 HTTPストリーミングを実際に試すため、前回のエピソードで作成した簡単なToDoアプリケーションを使用します。アプリケーションのコントローラでストリーミングを有効にします。デフォルトでは有効になっていないので、アクションごとかコントロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Streaming@Twitter
Heron
Consuming streaming data
Loading...
Wget - Download streaming media?
http://blog.monoweb.info/article/2012012423.html
http://blog.yanaoki.org/2010/11/25/twitter_user_streams_api/
GitHub - jugyo/earthquake: Twitter terminal client with streaming API support.
『mSpot』は無料で2GBまで使えるiPhone・Androidにも対応した音楽用クラウドスペース！ | ライフハッカー・ジャパン
