Facebookの数千台規模のmemcached運用について - ゆううきブログ
Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログの続きとして、Facebook の memcached 運用に関する論文を読んだ。 タイトルなどは以下の通り。 NSDI はネットワークシステムに関するトップレベルのカンファレンス。 Scaling Memcache at Facebook Rajesh Nishtala, Hans Fugal, Steven Grimm, Marc Kwiatkowski, Herman Lee, Harry C. Li, Ryan McElroy, Mike Paleczny, Daniel Peek, Paul Saab, David Stafford, Tony Tung, Venkateshwaran Venkataramani NSDI'13 In Proceedings of the
GoogleのHTTPロードバランサーの破壊力があり過ぎる #gcpja - Qiita
そもそもGoogle Compute Engineのロードバランサー、GCE LBは、1インスタンス・1グローバルIP・ウォームアップなしでいきなり100万リクエスト／秒を捌けてしまう謎性能を備えていて、既存の他社クラウドのLBだけこれで置き換えたい！ という声もちらほら聞かれるほどの強力LBサービスであった。 From Compute Engine Load Balancing hits 1 million requests per second! そして今回、正式公開ではないLimited Preview版ではあるものの、GCE LBの新機能としてHTTP Load Balancingが発表された。その性能と機能の破壊力があり過ぎるので、GCPブログ記事のリンクをシェアするだけではあまりにもったいない！ と思い、要点を訳してみた。 DNSに頼らない、1グローバルIPによるUS、EU、A
ハイパフォーマンス ブラウザネットワーキング、読むべき本だった - terurouメモ
Twitterで「なんかやばそうな本が出るぞ！！！」みたいな事を言っていたら、それが偶然拾われて、献本して頂く流れになりました。オライリーさん、ありがとうございます。 とりあえずざっと全体を流し読みした（と言っても3時間弱は読んだ）ので、書評っぽいことを書いておく。 ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化posted with amazlet at 14.05.10Ilya Grigorik オライリージャパン 売り上げランキング: 4,747 Amazon.co.jpで詳細を見る 読むべき人間 以下に該当する人間に対しては必読に値する本だと思う。 HTTPを扱うアプリケーション*1のアーキテクチャを設計する人間 Webサーバ等のHTTPに関連するインフラを担当する人間 HTTP 2.0、WebSocket、Server-S
ハイパフォーマンス ブラウザネットワーキング書評 - Block Rockin’ Codes
Intro 執筆段階から、 Web で無料閲覧できた High Performance Browser Networking が、紙の本として出版され、その翻訳本が完成したということで、献本を頂きました。 原著には本当にお世話になったし、 HTML5Experts.jp で書いた Make the Web Faster の連載でもよく参考にした本なので、日本語で読めるようになったのは非常にありがたいですね。 本当はレビュアの依頼を頂いたのですが、色々あって他の方に振ったりしてしまったので、せめて全力で書評させていただきます。 やっと献本頂いたイリヤ本ゆっくり読める。日本語で読めるのは素晴らしい。 #http2study pic.twitter.com/Zy00OOy6ve— Jxck (@Jxck_) 2014, 5月 11 Make the Web Faster ところで、 Google
Google Hosted Library – Webを速くするためにGoogleがやっていること Make the Web Faster 03 –
Google Hosted Library – Webを速くするためにGoogleがやっていること Make the Web Faster 03 – Jxck Googleは、よく使われるJavaScriptのライブラリなどをGoogleのインフラを使って配布しています。 これを Google Hosted Library と呼びます。 この、Hosted Libraryの導入を単純に「自分で配布しない分が楽になるだけ」、くらいな感覚で使っている方も多いと思います。しかし、実はこれはみんなが使えば使うほど、得をする仕組みになっていることを見落としてはいないでしょうか？ 今回はそんな、Google Hosted Libraryについて、その仕組となるCDNやキャッシュの技術などについて解説します。 よくある Web ページ 例えば自分が配信するindex.html内でjquery.2.0.3
Googleの新プロトコルQUICを試す - ぼちぼち日記
1.QUIC仕様の公開 以前、「Googleが仕掛ける新プロトコルQUICとは何か」のブログエントリーを書いたのが2月末の事でした。それから4か月経ち、今朝Googleが初めてQUICの公表(Chromium Blog: Experimenting with QUIC)を行いました。 IE11のSPDY/3対応が判明した直後でした。なんというタイミングでしょうか。 また、近いうち（来週？）には HTTP/2.0 の Implementation Draft が公開される予定です。8月上旬には、GoogleやMicrosoft等が集まって初めての HTTP/2.0 の相互接続試験を行う予定です。ただ今HTTP関連のプロトコルが急激に進化する真っ最中です。目が離せません。 2. で、QUICとは何なのか？ 先のChromium BlogのエントリーでQUICは、 「Quick UDP Inte
ネットワーク通信を行う場合に検討すべきこと
特にモバイルアプリで頻繁にネットワークが切れる可能性がある場合こういった対策を考えた方がいい。 接続のタイムアウト通信を行う場合には基本的にタイムアウトの設定をする。 「どのくらいの秒数でタイムアウトするか」は難しいが、「課金や決済等の2重投稿が問題になる通信」は長く、「ページの表示等の2重投稿が問題にならない通信」は短くするのがいい。 ただし、2重投稿が問題になる通信でも、「タイムアウト後は再送信前にサーバに最初の通信が成功したかどうか確認する」のであればタイムアウトは短くても機能的な問題は少ない。 （または、サーバ側が2重送信前提で処理を行う） 自動再接続特にストリーミング等で「常時コネクションを張り続ける」系の実装を行う場合、一度通信が切断しても自動的に再接続する実装が行われることが多い。 ただ、このときにコネクションの管理が正しく行われず複数のコネクションが同時張られる状態になると
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
第2回 IPv6をハックしよう～IPv6ハッカソン～ | gihyo.jp
IPv6始まりました 2011年6月8日に、世界中のWebサービスの提供者が1日（24時間）だけ自社のサービスをIPv6対応させて影響を探ってみようというWorld IPv6 Dayというイベントが開催されました。 参考：Wolrd IPv6 Day に関する情報提供サイト http://www.attn.jp/worldipv6day/ 大きな混乱も問題もなくIPv6でのサービス提供は充分可能ということが実証できたようです。また、ISPによるIPv6接続サービスも提供され、一般家庭でも普通にIPv6が使えるようになりました。 参考：家庭でIPv6対応の接続サービスを導入 - Wold IPv6 Day 情報提供サイト http://www.attn.jp/worldipv6day/ipv6-service.html IPv6はすぐに使えるテクノロジーとして存在しているのです!! 流行りも
Geekなぺーじ : インターネットインフラエンジニアであるか見分ける10の質問
元ネタ「インフラエンジニアであるか見分ける10の質問」にインスパイアされて考えてみました。 最近は「インフラエンジニア」と言ったときにサーバ系のエンジニアを指すことが多く、インターネットそのものを運用するような通信事業者系のインフラエンジニアを何と呼ぶべきか良くわからないので、タイトルが被ってしまっていますが、TCP/IPを扱う通信系インフラエンジニアであれば普通に話題を知ってそうな簡単なものを考えてみました(タイトルを「ネットワークエンジニア」に変更しました)。 「インターネットインフラ系のエンジニアであれば何となくの概要は知ってそうだけど、他の分野の人にとってはとっさに答えが出て来なさそう」もしくは「他分野の人も回答はできるかも知れないけど回答の内容で何となくインフラエンジニアであるかどうかの予想可能」という思想なので、「簡単過ぎる」と「難しい」が別れるように考えたつもりですが、もしか
ping とか traceroute とかでネットワークの勉強
普段、あまりネットワークに関係する仕事をやってなかったけど、 勉強したことをメモメモ。まちがってたら、指摘ください。 こちらまでご連絡おまちしてます まずは、ping /Users/satoshi% ping -c 10 www.yahoo.co.jp PING www.ya.gl.yahoo.co.jp (203.216.227.176): 56 data bytes 64 bytes from 203.216.227.176: icmp_seq=0 ttl=53 time=16.000 ms 64 bytes from 203.216.227.176: icmp_seq=1 ttl=53 time=25.958 ms 64 bytes from 203.216.227.176: icmp_seq=2 ttl=53 time=15.543 ms 64 bytes from 203.216
【コラム】イマドキのIDE事情 (83) HTTPモニタでHTTP通信を覗いてみよう! | エンタープライズ | マイコミジャーナル
HTTPモニタとは? WebアプリケーションやSOAP、JSONなどでHTTPベースのプロトコルを利用した通信を伴うアプリケーションを開発している場合、デバッグや障害解析などのために実際にHTTPでどのような内容の通信が行われているかを参照したいことがある。このような場合に利用できるのがHTTPモニタだ。 HTTPモニタにはさまざまなものがあるが、今回はFirefox拡張であるLive HTTP Headers、EclipseのWTPに標準で付属するTCP/IPモニタ、Windowsのスタンドアロンアプリケーションとして利用可能なFiddler2の3つを紹介する。 Live HTTP Headers Live HTTP HeadersはFirefoxの拡張として利用可能なHTTPヘッダのモニタリングツールだ。 インストール後、Firefoxの[ツール]メニューの[Live HTTP hea
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linux女子部 iptables復習編
High Performance Browser Networking - Velocity
http://chiplog.quicinc.com/
httpコマンド便利 | Ore no homepage
Introduction to Linux IP Routing Fundamentals (Part 1)
サーバーを作ろう
IBM Developer
http://www.machu.jp/posts/20100416/p01/