なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
「お待たせしない」Webサイトでの接客 (ユーザビリティ実践メモ)
1990年代、電話回線やISDNを使ったダイヤルアップ接続（低速・時間課金）でインターネットに接続することが一般的だった頃は、Webサイトの利用は「時間との勝負」という側面がありました。そのためWebサイトを制作する際も、htmlファイルや画像などを含めたページ当たりのサイズを小さくしてページの表示速度を高め、ユーザを待たせないことが重要視されていました。 ■人間の思考とシステムの反応速度 人間の操作に対するシステムの反応速度については、一般的に次のような関係が見られると言われています。 （参考：「Response Times: The Three Important Limits」 Useit.com（英語）、「10の累乗： ユーザーエクスペリエンスにおける時間スケール」 Jakob NielsenのAlertbox（日本語）） 0.1秒：ユーザは、自分がシステムを「直接」操作していると
はてなブックマークのコンテンツの JavaScript を高速化する - IT戦記
はじめに 「新はてなブックマーク」になったということで、とっても便利になったのですが、ブックマーク一覧ページ*1が若干 JavaScript に時間が掛かっているみたいです。 というわけで 調査してみたいと思います。調査して、改善できそうなところは後で纏めて「はてなアイデア」にでも登録しようと思います。 この日記は調査しながら、過程を書いていくつもりです。 準備 まずは、人のサイトの JavaScript を書き換えて試してみるための環境を作ります。 作業用ディレクトリを作る とりあえず、ホームに HatenaJS というディレクトリを作ります。 $ mkdir HatenaJS $ cd HatenaJS CocProxy をダウンロードしてくる 以下から CocProxy というツールをダウンロードしてきます。 http://coderepos.org/share/wiki/CocPr
ユメのチカラ: 勝手に性能評価(Lingr編)
週末にLingrを利用したチャットイベントがあったそうだ。[JTPA] Lingrイベントの顛末/My Life Between Silicon Valley and Japan昨日のオンラインサロンは、参加者が集まるにつれてLingrが重くなってしまって残念ながら中止となりました。実のところLingrの実装がどうなっているかは全く知らないのだが、何百人もわらわら集まってチャットをやろうという心意気が楽しい。素晴しい。やってみてスケールしなかったというのも主催者側は若干凹むかもしれないが、それもいい経験で、むしろそーゆー得難い経験を得られたと考えた方がいい。 Lingrの開発者の江島さんは、梅田さんのブログで再挑戦を表明しているので楽しみにしたい。 さて、今回の経験から江島さんら実装者の皆さんは何を学んだのだろうか？ぜひ情報公開をしてほしいと思うのだが、わたしだったらどうするか勝手に記して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
