Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（＆ サーバのベンチマーク手法の話）
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか:Web屋のネタ帳 on CNET - CNET Japan
結論。DNSラウンドロビンという古くからある技術を取り巻く状況の変化を見過ごしている結果、負荷分散と可用性確保のために高価なロードバランサー機器を導入しているWebサイトは、実は大幅に金を無駄にしているのかもしれない。 一部の人には「今頃気がついたか」と笑われる可能性が高い話だ。 筆者が気づいたきっかけはとあるブログに書かれたこんな一節である。 あまり知られていないことかもしれませんが、DNS があるホスト名に対して複数の IP アドレスを返した場合、多くのウェブブラウザは、その全てのアドレスに対して接続を試みます (接続に成功するまで)。 Kazuho@Cybozu Labs: DNS ラウンドロビンと高可用性 (High Availability) 「えっ？そうだったの？だとすれば、、、」というのが筆者の素直な感想である。これだけでピンと来ている人はいいのだが、詳しくない人のために
フレッツ光接続で非常に遅いページがあるのはNTTがIPv6使って身勝手なサービスしてるせい - モーグルとカバとパウダーの日記
Bフレッツやフレッツ光ネクストで非常に速い速度で繋がっているにもかかわらず、ページの表示に非常に時間が掛かる場合がある。 これはフレッツの公式のサポートページにも載っている問題だ。 MacOS 10.4.xでの特定WEBサイト表示遅延の事象の回避方法｜フレッツ公式｜NTT東日本 IPv6を使わないようにするとこの問題は解決するのだが、この解決法ではIPv6を使うサービスは逆に使えなくなってしまう。 というか、この問題のせいでIPv6対応しようとするといろいろと不具合が発生してしまうのだ。 （2011/5/27 追記） BフレッツのIPv6アドレス割り当てに関する注意事項｜フレッツ公式｜NTT東日本 http://flets.com/customer/ipv6_setting.html ここにNTTが提供している「フレッツIPv6セットアップツール」というものがあるので、それをインストールす
ポートスキャンプログラムの構造解説と作成 Perl « ORBIT SPACE
原本に一部間違いや遠回りをしていると思われる点がありましたので修正してあります。 [perl] #!/usr/bin/perl #————————————————-# # Name: Port Scan Program # 原作: Perl scan port # (URL: http://www.perlmonks.org/?node_id=806461) # 解説: ORBIT SPACE # 目的: ポートスキャンプログラムの構造の # 理解とモジュール利用方法等の理解 # を行う為に今回構造の解説とプログ # ラムの変更を行いました。 #————————————————-# #モジュール使用宣言 use IO::Socket; # Very Simple Scan Port Write in Perl # MAIN PROG print “Perl Sca
Google、HTTPを補う高速化プロトコル「SPDY」発表
GoogleがWebページ表示をスピードアップするプロトコル「SPDY」を発表した。テストではページ読み込み速度が最高で64％短縮できたとしている。 米Googleは11月12日、Web高速化を実現するためのアプリケーションレイヤープロトコル「SPDY」（スピーディーと発音する）を発表した。Googleが目指しているWeb高速化の一環で、HTTPをサポートし、Webページ表示の遅延時間を最小限に抑えるという。 SPDYに関するホワイトペーパーによると、同社はSPDYとともに、同プロトコル対応版のGoogle ChromeブラウザとオープンソースのWebサーバも開発した。これらのアプリケーションをHTTPとSPDYで稼働テストしたところ、ページ読み込み時間が最高で64％短縮できたという。 SPDYはセッションレイヤーをSSLの上に追加するので、単一のTCP接続で複数の相互データストリームを並
米国はネットを高速化する気が無いらしい（その２）-困るのはGoogleでは？ - My Life After MIT Sloan
前回の 「米国はネットを高速化するつもりがないらしい（その１）－バックボーンはつらいよ」はかなり反響があり、私も驚いた。 で、流石に3日間でのべ2万人が読んでるとなると、いろーんな方々が読んでるだろう。 こーなると、ブログだから好きなことを書けばよいというわけにもいかず。 自分としては偏るつもりはないので、背景も含め、正しくアメリカの状況を伝えた方が良いかな、と思ったので、今日はまず、その話から。 前回の話はインターネットに限った話、で遅くなるってことです。 バックボーンプロバイダーが構造的に儲からない、というのは前回書いた論理の通り、本当の話。 実際インターネットのバックボーンとかろうじてISPをやってる企業が、以前アメリカにはたくさんあったが、バタバタ死んだり、買収されたりした。 （今でもかろうじて生き残ってるが、苦しいとこがたくさんあります） ところが、ComcastとかAT&Tのよ
自分のサーバの性能を知っておく - tokuhirom's blog
http://github.com/kazuho/manymanythreads ↑kazuhoさんがCで書いたエコーサーバーと、そのベンチマークツールによって、自分のサーバでどんぐらいのQPSがでるのかがわかる。 たとえば自分のマシン(SC440)だと ./testechoclient -c 1 -n 1000000 -f -p 5050で、 77906.624081 reqs./sec. (1000000 in 12.835879 seconds)ぐらいでる。 一番単純なエコーサーバーをうごかしたときの性能を把握しておくことによって、どのぐらいの速度がでてしかるべきなのかが把握できるようになるという。 【追記】 ここで知った echo server の限界性能をもとに、その後、自分がなにかサーバ等を書いた場合に最適化したらどのぐらいの速度がでるかを予測できる(経験が必要だとおもうけど)
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
ウノウラボ Unoh Labs: PubSubHubbubとは
yamaokaです。 Twitterのみならず、FriendFeedやFacebookなど よりリアルタイムに近い更新がwebで求められるようになってきています。 従来、更新情報の配信はRSSなどのフィードやAPIを通して行われてきました。 しかしその場合、配信している側のサーバーに 定期的にリクエストを投げないと更新があったかどうかわかりません。 サーバーへのアクセスが多くなった場合、結構な負荷になります。 さらにお行儀の悪いクライアントが存在すると、頻繁なアクセスを繰り返し、 あたかもDoS攻撃のような状況が起こることもありえます。 そこで考えられたオープンなHTTPベースのプロトコルがPubSubHubbubです。 Google ReaderとFriendFeedが対応している他、 日本国内ではlivedoor Blogとliverdoor Readerがそれぞれ対応しています。 で
なぜか4ポートもあるネットワークカード「Intel PRO/1000 PT QUAD PORT Server Adapter」をGIGAZINEで使ってみた
ネットワークをいくつかに分けている場合や、1台で複数の外部接続をしなければならないサーバを使用している場合には、ネットワークインターフェイスカード(NIC)を複数使用しなければならないことがあります。 GIGAZINEの場合、画像配信サーバに必要なNIC数が「4」を超えてしまうおそれがあり、そろそろスロット数の限界が見えてきたため、4ポートのネットワークカード「Intel® PRO/1000 PT Quad Port Server Adapter」(約5～6万円)を試してみることにしました。 詳細レビューは、以下から。 こんな感じで梱包されてやってきました。 とりあえず開けてみるとCDが裏返って入っていました。ちょっとだけ寂しい気分になってしまいます。 気を取り直して中身の確認。中身は、ネットワークカード本体とCDのみ。いたってシンプル。 厳重に梱包されています。 開けてみました。上部から
Geekなぺーじ : みんなが知らずに使ってるAkamai
Akamaiさんでのセミナーに参加してきました。 個人的にはAkamaiさんと言えば「あまり一般的には知られていないけど使っていない人はほぼいない」企業というイメージがあります。 あまりに内容が楽しかったので、セミナーで色々質問しまくって聞いてしまいました。 想像以上に色々凄いと思いました。 ブロガーのyasuyukiさんが企画し、Akamaiさんにお願いして実現したプライベートセミナーでした。 元々はyasuyukiさんがAkamaiさんのセミナーを聞いて「面白い」とtwitter上で囁きまくっていて、その後「プライベートなセミナーやったら来ますか？」とのオファーを頂きました。 昔からAkamaiさんのCDN技術には非常に興味があったので「是非お願いします」とお願いしました。 セミナー参加者募集はyasuyukiさんのブログとtwitter上で行われ、16人の参加者がいました(アカマイさ
ニコニコ大百科のアーキテクチャ - グニャラくんのグニャグニャ備忘録@はてな
Twitter mongrelP: @tasukuchan グニャラくーん、ニコ百の鯖がEeePCという話が持ち上がってますがただの監視用ですよね（しんぱいそうなめでみている） http://twitter.com/mongrelP/status/1524183917 ニコニコ大百科のアーキテクチャについてメモしておきます。 本当は、このネタでRuby Kaigiに申し込もうと思ったけど、すっかり忘れていたのでエントリを起こしておきます。Rubyあんま関係なかったし。 全てのリクエストを受付、セッション情報も保持するEeePC 次世代サーバプラットフォーム EeePC ニコニコ大百科宛ての全てのリクエストは、全てEeePCに送られます。 実物の写真を載せておきます。 EeePCは2台稼動しており、１台はホットスタンバイです。 EeePCは、SSDとUPSを備えた次世代サーバプラットフォーム
ダイクストラ法, 貪欲アルゴリズム - naoyaのはてなダイアリー
現実逃避をしながらウェブを眺めていたら ダイクストラ法（最短経路問題） にたどり着きました。単一始点最短路問題におけるダイクストラ法の解説です。 何を思ったのか、図を眺めていたところ動かしたい衝動に駆られて、気付いたらパワポでアニメーションができていました。 http://bloghackers.net/~naoya/ppt/090319dijkstra_algorithm.ppt 実装もしてみました。隣接ノードの表現は、ここではリストを使いました。 #!/usr/bin/env perl use strict; use warnings; package Node; use base qw/Class::Accessor::Lvalue::Fast/; __PACKAGE__->mk_accessors(qw/id done cost edges_to prev/); package Q
VirtualBox on Mac OS X で、ゲスト OS に ssh/http アクセスするまで - 腹八分目。
背景 ちょっとてこずったので、メモを残しておきます。 ホスト OS ... Mac OS X 10.5 仮想化ソフト ... VirtualBox 1.6.2 ゲスト OS ... debianミラーサイト にある debian-40r4a-i386-netinst.iso やりたいことは、 ゲスト OS 上でプログラミング、ウェブプログラミングを勉強・実験するテスト環境を構築したい ・・・だけなので、ゲスト OS にデスクトップ環境はいらない できるだけ軽く動作させたい ホスト OS から ssh でログインしてプログラムを打ち込む ホスト OS のブラウザからゲスト OS の httpd にアクセスして実験する です。 ゲスト OS のインストール VirtualBox のインストールは省きます。 ゲスト OS として、ごくごくふつうに debian をインストールしました。詳細は省き
Mac で hosts を変更する方法
要するに hosts がどこにあるかというだけの話。 基本的には自分用メモだけど、 やり方を書いといたら誰かが見るかもしれないので一応。 ターミナルを起動する。 管理者権限で hosts ファイルを開く。 $ sudo vi /private/etc/hosts /private/etc へは /etc からシンボリックリンクが貼られているので こちらでも OK です。 $ sudo vi /etc/hosts 管理者パスワードを入力する。 文書の末尾で a を押して入力モードにする。 新しい行に、IP アドレスとホスト名を入力する。 （例） 121.119.178.66 www.msng.info esc を押して入力モードを終了。 ZZ と打って保存終了。 何か OS を再起動させろとか書かれているのも見たけど 少なくともうちの Mac OS (10.5.5) では 再起動しなくてもす
ICMPパケットでトンネルがはれる、ptunnel - UNIX的なアレ
ちょっと面白いモノを見つけたので紹介します。 ICMPパケット(pingですね)で相手先とトンネルをはることができる、ptunnelというコマンドです。 インストール方法 Ubuntu/Debian # sudo apt-get install ptunnel CentOS # wget http://dag.wieers.com/rpm/packages/ptunnel/ptunnel-0.61-1.2.el5.rf.i386.rpm # sudo rpm -ivh ptunnel-0.61-1.2.el5.rf.i386.rpm 使い方 使い方はいたって簡単。ptunnelを使用するクライアント側、受けるサーバー側両方にインストールする必要があります。 また、ptunnelは基本的にすべてrootのみ利用可能です。 クライアント側 # sudo ptunnel -p {ProxySer
Perl でローカルのアドレスを取得する - naoyaのはてなダイアリー
ifconfigの出力をsedでパース — ありえるえりあ まだ Linux を触り始めて間もない頃に、サーバーを構築していてローカルの IP アドレスをシェルスクリプトから利用する必要があって、どうやって取得するべきだろうかと小一時間悩んだのですが結局分からず Perl の正規表現で ifconfig を parse したことがありました。ioctl() を使ってデバイスを操作する必要がある、ということを知ったのは数年後、割と最近のことです。なんということでしょう。 では、Perl で IP アドレスを取得する場合ですがモジュールを使ってよいのであれば IO::Interface がよいだろうと思っています。IO::Interface は Pure Perl ではありませんが、XS で ioctl() を呼び出しているので比較的高速且つ素直な実装だと思います。 #!/usr/local/
Perl and UNIX Network Programming (YAPC::Asia 2007) - naoyaのはてなダイアリー
YAPC::Asia で Perl UNIX ネットワークプログラミングについての発表をしてきました。UNIX ネットワークプログラミングの基礎の概論、I/O多重化の話、Perl のモダンなネットワークライブラリの話です。資料を以下に置いておきます。 http://bloghackers.net/~naoya/ppt/070404Perl_and_UNIX_Network_Programming.ppt (ppt, 122k) なお、会場では口頭で触れましたが、資料中のソースは簡単のためエラー処理を飛ばしています。また、途中で出てくる図は例えば vfs のページキャッシュをはしょってあったりとこれも簡単のため省略事項がある点にご注意ください。 それからフォントが Consolas なので Consolas が入ってない環境だと変になる、かも。
ウノウラボ Unoh Labs: WEBサービス運用における監視体制
こんにちは satoです WEBサービスは作るよりも運用の方がコストがかかるとも言われています。 運用を極力自動化して、コストを減らしたいものです。 ここではウノウで使っているツール類を紹介したいと思います。 1) 疎通、生存監視 webの生存監視などは nagiosを使って監視しています。 nagiosには - いつ(土日を除く、10時～22時までの間で など) - どのタイミングで(N回連続で ,復旧したら など) - 何が起こったった時に(疎通が取れない など) - どうするか(メールで通知する) などを細かく設定できる監視ツールです。 ウノウでは MySQL、memcached、HTTP、ping、DNS、SMTPなどの監視をnagiosで行っています。 2) システムやアプリケーションLOG ログの監視には swatch を使用しています swatchの機能には -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TCPで通信するクライアントをデバッグするとき - suztomoのはてなダイアリー
