タグ

networkに関するnippondanjiのブックマーク (4)

  • 高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋

    はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか? 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の2倍や3倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立

    高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
  • アラクサラ、データセンタに最適なボックス型10ギガビット多ポートスイッチAX3830Sを製品化 ~仮想化サーバの収容に最適なアドレスエントリ数を実現~

    アラクサラ、データセンタに最適なボックス型10ギガビット多ポートスイッチAX3830Sを製品化 ~仮想化サーバの収容に最適なアドレスエントリ数を実現~ データセンタに最適なボックス型10ギガビット多ポートスイッチAX3830Sを製品化 ~仮想化サーバの収容に最適なアドレスエントリ数を実現~ アラクサラネットワークス株式会社(社: 神奈川県川崎市 代表取締役社長 滝安美弘 以下アラクサラ)は、1Uサイズ(*1)で44ポートの10ギガビットイーサネットを収容可能な、データセンタ向けボックス型スイッチAX3830Sを製品化しました。 クラウドコンピューティングの利用の拡大に伴い、データセンタに設置されるサーバの規模が、加速度的に増加しています。これらのサーバを効率的にネットワークに収容することは、データセンタの設計・運用において、重要な課題となっております。 AX3830Sは、この課題を解決す

    アラクサラ、データセンタに最適なボックス型10ギガビット多ポートスイッチAX3830Sを製品化 ~仮想化サーバの収容に最適なアドレスエントリ数を実現~
    nippondanji
    nippondanji 2011/05/26
    「1Uサイズで44ポートの10ギガビットイーサネットを収容可能」とな??
  • 4Gamer.net — [CEDEC 2010]ネットゲームの裏で何が起こっているのか。ネットワークエンジニアから見た,ゲームデザインの大原則

    [CEDEC 2010]ネットゲームの裏で何が起こっているのか。ネットワークエンジニアから見た,ゲームデザインの大原則 編集部:touge 先週行われた「CEDEC 2010」の講演から「ネットワークゲームの仕組みとゲームデザイン」と題されたセッションを紹介しよう。 「CEDEC 2010」公式サイト 登壇したのは,セガ第三CS研究開発部のテクニカルディレクター 節政暁生氏。節政氏は「ファンタシースター オンライン」シリーズのプログラマとして,長年ネットワークゲーム(オンラインゲーム)の開発を手がけてきてきた人物だ。この講演では,その経験からネットワークゲームゲームデザインにおいて,気をつけるべきことについてのレクチャーが行われた。その内容には一部技術的な要素を含むものの,基的にはプランナーに向けたものであるため,理解にそれほど専門的な知識は必要ない。いわばネットワークの基礎の基礎にあ

    4Gamer.net — [CEDEC 2010]ネットゲームの裏で何が起こっているのか。ネットワークエンジニアから見た,ゲームデザインの大原則
    nippondanji
    nippondanji 2010/09/07
    スタクラのコマンド入力同期方式はトレビアンだな。そんな感じで実装してるんだろうなと思ってプレイしてたけど、改めて文書化されると素晴らしい。アポーだと特許取りそうなレベル。
  • Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由(& サーバのベンチマーク手法の話)

    TCP通信をするプログラムを書く際に「データの送信はまとめて1回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ(1回のwrite(2)で書き込むサイズ)の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ(=パケット数の逆数)による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生

    nippondanji
    nippondanji 2009/12/01
    興味深い。リモートのホストへの転送でブロックサイズが小さいときに性能が低下しないのは、システムコール呼び出しはcswに比べると大したオーバーヘッドじゃないからってことなんだろうなあ。
  • 1