OPEN コンソーシアム / エルサレム・プロジェクト OPEN.AD.JP (現在構築中) 連絡先: 筑波大学 登
OPEN コンソーシアム / エルサレム・プロジェクト OPEN.AD.JP (現在構築中) 連絡先: 筑波大学 登
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
自宅ルータをコレガのルータから、KVM上のVyattaに移行しました。 きっかけは設定ミスって繋がらなくなったときの、GUI&記憶ベースの復旧作業がとてもめんどくさかったからです。 というわけで今回やった作業や構成について簡単にメモ書いておきます。 とても簡単なのでみんなもぜひ!!! 移行前の構成 よくある構成ですね。 移行後の構成 KVMのホストサーバに物理NICを増設して仮想ブリッジを追加、VyattaVMだけグローバル/ローカル両方に接続する形です。 いちおう写真も! 今回追加購入した機器はこの2つです。 BUFFALO Giga対応 電源内蔵 5ポート スイッチングハブ LSW3-GT-5NS 出版社/メーカー: バッファロー発売日: 2008/02/10メディア: Personal Computers購入: 5人 クリック: 39回この商品を含むブログ (9件) を見るインテル
September 10, 2013 市販のルータ兼無線アクセスポイント君が 2日に1回再起動しないとAirPlayできなくなってしまったので この際自宅のネットワーク環境を一新すべく Vyattaを導入した。その際のメモ。 参考URL 自宅ルータをVyattaに移行しました - IT 東京 楽しいと思うこと Vyatta_QuickStart_R6.1_v02_1.pdf 環境 Ubuntu: 12.04.3 LTS (KVM HOST) Vyatta: VC6.6R1 ネットワーク 買ったもの 追加NIC用に「Intel Gigabit CT Desktop Adapter EXPI9301CT」 無線LAN用に「PLANEX FFP-PKA04D」 スイッチは前職で頂いた8ポートのスイッチングハブを利用 構築 ブリッジのインタフェースを2つつくる eth0 Internal eth1
インターネットのネットワークに多少なりと興味がある方なら、指定の目的地までの経路探索をしてくれる、みんな大好きtracerouteコマンド。 そんなtracerouteの色々をメモしておきます。 tracerouteの仕組み 既に多くの解説サイトがあるので、そちらに譲りますw tracerouteはTTLを1ずつ増やしながらパケットを送信することで、経路情報を取得する。 TTLとはパケットの生存期間を表し、ルータを1つ経由することに1ずつ減算される。 ルータはTTLが2以上のパケットが届いた場合、TTLの値を1だけ小さくし次のルータへ転送する。 TTLが1のパケットが届いた場合、届いたパケットを破棄しICMP time exceededパケットを送信者に返す。 tracerouteはまず、TTLを1にセットしたパケットを送信する。最初のルータに届いた時点でTTLがゼロになり、ICMP ti
FedEx Bandwidth もし可能であればいつ、インターネットの帯域がFedExに打ち勝つのか? —Johan Öbrink テープを満載したワゴン車の帯域をあなどるなかれ。 —Andrew Tanenbaum, 1981 2040年 数百ギガバイトのデータを転送したいとしたら、通常はインターネット越しに送るより、FedExでHDDを送るほうが速い。これは何も目新しいアイディアではなく、スニーカーネットと呼ばれているもので、Googleが内部的に大量のデータを転送するのにも使っている手法だ。 しかし、今後も常にそうだろうか? Ciscoの推定によれば、インターネットの総トラフィックは、毎秒167テラビットである。FedExは654機の貨物飛行機を所有しており、一日あたり120万キログラムもの積載容量がある。重さ78グラムのラップトップ用のSSDは、1テラバイトの容量がある。 つまり、
kernelのチューニングについて まぁ個人的な所感なんですけど。。 10年前ぐらい前、とあるシステムで原因のリンクダウンが頻発するトラブルがあり、まったく原因がわからなかったのですが、当時の先輩がkernelのソースコードをいじくって直したことがありました(なんかパッチ送ってました)。 私はその頃ペーペーだったのですが、なにこの変態と思いつつも、その技術力にとても感動しました。 10年たった今はだいぶ安定しておりkernelレベルのチューニングはあまり必要性を感じていませんが、どうしてもって時はこうやるよって感じのメモです。 まぁTIME_WAIT値を変えるぐらいなら大したことないんですけどね。あのリンクダウンってどうやって解決したのかな。10年たった今でもさっぱりわからん。変態め 環境等 OS: CentOS 5.8 (64bit) kernel: kernel-2.6.18-308
上を行くかどうかは知りませんが :-p Ajaxはクライアントの都合でサーバーに通信を仕掛けるpull型の通信ができ、Cometはサーバーが好きなタイミングでクライアントへデータを送りつけるpush型の通信ができるわけですが、新たに双方向の通信ができる技術を開発しました。 具体的には、JavaScriptとサーバーの間で双方向のRPCができます。すなわち、サーバーからクライアント側のJavaScriptのメソッドが呼べるし、逆にクライアント側からサーバー側のメソッドを呼ぶこともできます。 サーバー側で call("addMessage", "Hello!") とやると、JavaScript側の function addMessage(msg) { ... } という関数が呼ばれたりします。 この技術を使って、試しにチャットシステムを作ってみました > デモ (ソースコード)*1 リアルタイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く