はてなダイアリーの高速化の裏側 - stanaka's blog
先週、ダイアリーがリニューアルされました。今回のリニューアルはダイアリーの応答時間の改善が目玉の一つとなっており、そのために１週間リリースを延ばし、改善の時間を確保していました。今回は、この改善について記しておきます。 はてなでは「推測するな、計測せよ」の原則にしたがって、ダイアリーのユーザーページの全アクセスの応答時間を解析し、ヒストグラムを作っています。また、特定の閾値(1秒、2秒とか)以内に何%のリクエストを返却できている割合をグラフ化しています。 このグラフを見ると、応答時間時間は時間とともに劣化することが一目瞭然です。実際に今年初めの値と比較すると10%〜20%程度の悪化が確認されました。あとは、これをひたすら改善していくのみです。今回実施した主な対策は、以下の通りです。 ネットワーク パケットロスが発生しているようなトラフィック経路上のボトルネックの解消(L2スイッチの置換、物
Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（＆ サーバのベンチマーク手法の話）
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
ウノウラボ Unoh Labs: サーバのネットワーク速度の調査/測定方法
こんにちは。kyagi です。先日データセンタ内のサーバ群のうち、なぜか特定の１台だけネットワークの速度が極端に遅いという問題がありました。今回はサーバマシンのネットワーク速度の測定方法と原因についてお話しします。同様のトラブルが発生している方のお役に立てば幸いです。問題解決までの手順としては以下になります。 1. 現在の状態を調べる 2. ハード/ソフト含めて考えられる原因をいくつか挙げる 3. 原因について改善されるまでひとつひとつ検証していく まず現在の NIC の HW 情報とドライバを lspci で調査します。ここでは Broadcom の NetXtreme BCM5722 という NIC を使用していることがわかります。 # lspci -vvv | grep Ether 01:00.0 Ethernet controller: Broadcom Corporation
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
Geekなぺーじ : みんなが知らずに使ってるAkamai
Akamaiさんでのセミナーに参加してきました。 個人的にはAkamaiさんと言えば「あまり一般的には知られていないけど使っていない人はほぼいない」企業というイメージがあります。 あまりに内容が楽しかったので、セミナーで色々質問しまくって聞いてしまいました。 想像以上に色々凄いと思いました。 ブロガーのyasuyukiさんが企画し、Akamaiさんにお願いして実現したプライベートセミナーでした。 元々はyasuyukiさんがAkamaiさんのセミナーを聞いて「面白い」とtwitter上で囁きまくっていて、その後「プライベートなセミナーやったら来ますか？」とのオファーを頂きました。 昔からAkamaiさんのCDN技術には非常に興味があったので「是非お願いします」とお願いしました。 セミナー参加者募集はyasuyukiさんのブログとtwitter上で行われ、16人の参加者がいました(アカマイさ
「はてな流大規模データ処理」を見てきた - もぎゃろぐ
KOF2008：関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 ＃ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量：五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
