タグ

TCPとnetworkに関するtoritori0318のブックマーク (7)

  • 負荷が低いのにアクセスを捌けきれない時の対応 - Carpe Diem

    概要 MongoDBCPU使用率やロードアベレージが高くないのに処理が詰まっている現象が起きました。 その時間にbatchが動いていてアクセスが急に増えることが原因と言うのは分かっているのですが、負荷的には十分余裕があり不思議な状態でした。 そこでdstatで見るポイント - Carpe Diemでも述べたように、負荷の状態から判断する基準があります。 ロードアベレージを確認する 1が高ければCPU、ディスクI/O、メモリにボトルネックがある 1が低ければTCPコネクションにボトルネックがある 今回の現象から判断するに、TCPコネクションに原因がありそうです。 原因調査 Too many open filesは出ているか ファイルディスクリプタが足りない場合はコネクション数が足りずに処理が詰まってしまいます。 そしてその場合Too many open filesというエラーが出ます。 し

    負荷が低いのにアクセスを捌けきれない時の対応 - Carpe Diem
  • モバイル対戦アクションゲームの通信最適化テクニック

    © 2018 SQUARE ENIX CO., LTD. All Rights Reserved. モバイル対戦アクションゲームの 通信最適化テクニック 通信遅延やパケロスへの対策をがんばる テクニカルディレクター 石森礼二 © 2018 SQUARE ENIX CO., LTD. All Rights Reserved. 前置き 通信の遅延には、それをごまかすテクニックがありますよね。 • ユーザーの操作をそのユーザーの画面にとりあえず即反映する 通信の結果を待たず、右キーを押したらすぐ右に移動する • 受信した通信結果が矛盾したら、通信を正として訂正する 実はすでに敵に吹っ飛ばされていたので右に移動はできなかったとか こうすれば、通信の劣悪さを感じづらくなります。 ただ、通信が劣悪だと矛盾が頻発するため“対戦”アクションゲームとし ては通信もなるべく頑張る必要があります。 ※ひとりプレ

  • ネットワーク ゲームにおけるTCPとUDPの使い分け

    2017年10月27日、モノビットエンジン勉強会inサイバーコネクトツーにて、中嶋謙互が講演しました「ネットワークゲームにおける TCPとUDPの使い分け」のスライドになります。ネットワークゲームを製作する際にご参考頂けますと幸いです。 登壇者: 株式会社モノビット 取締役 CTO 中嶋謙互Read less

    ネットワーク ゲームにおけるTCPとUDPの使い分け
  • TCPを(少しは)理解しておくべきその理由 | POSTD

    この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 (訳注:日語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 )を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました( またPythonでTCPスタックを書いたらどうなるかについても書きました )。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ

    TCPを(少しは)理解しておくべきその理由 | POSTD
  • LinuxでTCP_DEFER_ACCEPTが有効でもaccept後readできない理由

    listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jpという記事の中で、listen backlog があふれた後に accept(2) すると、その後の read(2) が EAGAIN を返したり、接続が不安定になるという事象が説明されていました。気になったので調べてみたことをまとめます。 結論から言うとこれはLinuxの仕様です。manのtcp(7)を見ると、 TCP_DEFER_ACCEPT (since Linux 2.4) Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of

  • listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jp

    TCP_DEFER_ACCEPTは、LinuxでサポートされているTCPのオプションで、サーバ側で使用した場合にはaccept(2)からのブロック解除をTCP接続が完了したタイミングではなく最初のデータが到着したタイミングで行ってくれるオプションです。 Webサーバ・アプリケーションサーバではリクエストが到着してからaccept(2)のブロックを解除するので、リクエストの到着をWebサーバ・アプリケーションサーバで待つ必要がなくなり、特にprefork型のサーバでは効率的にプロセスを使えるようになるという利点があります。PerlではStarletがこの機能を有効にしています ところが、某サービスでTCP_DEFER_ACCEPTが有効にも関わらず、accept後のreadでデータが読めず、最悪の場合、デフォルトのtimeoutである5分間プロセスがストールすることがありました。strace

  • TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋

    昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日海外の間を結ぶ長距離ネットワーク(いわゆるLong Fat pipe Network)において、通信時間を削減するにはどうしたらいいか?」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間(伝送遅延)を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日国内のホスト同士であれば、RTT(往復遅延時間)はだいたい10〜30ms程度ですが、日・北米間だと10

    TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
  • 1