タグ付けされた質問 「latency」

私の研究グループでは、最近、マシンのOSをRed Hat 6.2からDebian 8.3にアップグレードし、マシン間の統合Intel 1G NICを介したTCPラウンドトリップ時間が約110µsから220µsに倍増したことを観察しました。 最初は構成の問題だと思ったので、tcp_low_latency=1アップグレードされていないRed HatマシンからDebianマシンにすべてのsysctl構成（など）をコピーしましたが、問題は解決しませんでした。次に、これはLinuxディストリビューションの問題であると考え、マシンにRed Hat 7.2をインストールしましたが、往復時間は約220µsのままでした。 最後に、Debian 8.3とRed Hat 7.2の両方がカーネル3.xを使用していて、Red Hat 6.2がカーネル2.6を使用していたため、問題はLinuxカーネルバージョンにあると考えました。これをテストするために、Linuxカーネル2.6とビンゴでDebian 6.0をインストールしました。時間は再び110µsで速くなりました。 他の人も、最新バージョンのLinuxでこれらの高いレイテンシを経験しましたか？既知の回避策はありますか？ 最小作業例 以下は、レイテンシのベンチマークに使用できるC ++アプリケーションです。メッセージを送信し、応答を待ってから、次のメッセージを送信することにより、レイテンシを測定します。100バイトのメッセージでこれを100,000回行います。したがって、クライアントの実行時間を100,000で割ると、往復の待ち時間が得られます。これを使用するには、まずプログラムをコンパイルします。 g++ -o socketpingpong -O3 -std=c++0x Server.cpp 次に、ホストでアプリケーションのサーバー側バージョンを実行します（たとえば、192.168.0.101）。IPを指定して、よく知られているインターフェイスでホストしていることを確認します。 socketpingpong 192.168.0.101 そして、Unixユーティリティtimeを使用して、クライアントの実行時間を測定します。 time socketpingpong 192.168.0.101 client 同一のハードウェアを備えた2つのDebian 8.3ホスト間でこの実験を実行すると、次の結果が得られます。 real 0m22.743s user 0m0.124s sys 0m1.992s Debian 6.0の結果は real 0m11.448s user 0m0.716s sys …

8 linux  networking  performance  tcp  latency 

Linuxネットワークアプリケーションのレイテンシを短縮しようとしています。プログラムを特定のCPUコアに「バインド」するには、タスクセットとcpusetの2つのツールがあることを学びました。 どっちがいい？それらは下位レベルで同等ですか？ （性質）アプリケーションには単一のスレッドがあり、遅延を最小限に抑えて高速LANネットワーク経由で単一のTCP接続（再接続なし）を処理することになっています。私は正しい道を進んでいますか？

8 central-processing-unit  performance-tuning  latency  multi-core 

同じサブネット内のリモートリソースにアクセスするサービスのレイテンシは約100〜300ミリ秒ですが、ping（pingサイズは通常送信されるパケットと同じサイズ）を使用すると、5ミリ秒以下の応答が表示されます。他に確認すべきことはありますか？

8 windows-server-2008  networking  windows  latency 

Windowsでネットワーク遅延をどのように測定しますか？ ツールの1つとしてpingを知っています。Windowsパフォーマンスモニターでできますか？ それを測定するために追加する必要がある対抗策のアイデア。 これは、Webサーバーとデータベースサーバーの遅延が1ミリ秒未満である必要があるSharePoint固有のものです。

8 windows  networking  sharepoint  latency 

レイテンシマップを確認して、世界中のさまざまな宛先間で達成された最小のレイテンシを示します。たとえば、デンマークとインドの間で最も低いレイテンシが達成されました。これは、たとえば、オンラインゲーム用のサーバーファームを配置する場所の計画に使用できます。

8 internet  latency 

私は自分のLinode Ubuntu 14 64ビットサーバーをテストしています。これは、それらから入手できる最も基本的なサーバーです。Apache Benchmarkを使用してサーバーをテストしているほか、Pythonで記述したマルチスレッドスクリプトを使用していますが、これについては後で詳しく説明します。ABを使用すると、サーバー自体からローカルに実行すると1秒あたり約7kの要求がありますが、別のネットワーク/インターネットから実行すると約15になります。応答時間は、ローカルでの1000の同時接続の場合、約150ミリ秒です。リモートでは、100の同時接続の場合、応答時間は約1.5〜2.5秒です。リモートテストを実行しているネットワークには十分な帯域幅があり、実行しているコンピューターには十分なRAMとプロセッサ速度があります。それは高速なビジネスネットワークです。私は他の2台のコンピューターで、米国中の他の2つのネットワークを試しましたが、速度はほぼ同じです。 マルチスレッドスクリプトを実行しているときに、100を超える同時要求を試行するとすぐに一時中断します。これは外部ネットワークからのものです。サーバー上のPythonを3+にアップグレードするか、スクリプトを2.7互換に変更する必要があるため、サーバー上でスクリプトをローカルでまだ試していません。これをローカルでテストし、最大1000個のマルチスレッド接続でスクリプトを実行すると、150ミリ秒の応答時間が得られました。これは、単にurllib2を使用しているだけです。 私はこれを直接nginx（静的ファイル）、nginxの背後にあるpywsgiアプリ、およびpywsgiに対して直接テストしています。pywsgiアプリには、基本的な応答で応答する単純なルートがあるため、高速になります。驚くことではありませんが、nginx-> pywsgiが最良の結果を提供します。これは、おそらくリクエストをバッファリングする方法が原因です。この問題を引き起こしているLinodeのネットワークに固有の何かがありますか？内部テストと外部テストの桁違いの違いにより、何が原因であるのか疑問に思います。唯一の方法は、http / sとsshでフィルタリングするiptablesファイアウォールだけです。 dmesgには、私のテストに関する情報はありません。

3 nginx  latency  benchmark  wsgi  concurrency 

サーバーマシンからサーバーの内部ゲートウェイスイッチへのping遅延を監視しています。pingが時々500ミリ秒にも達することに気付きました。これは、スイッチが過負荷であるか、これが完全に正常である可能性を示していますか？

2 switch  ping  latency 

私は、米国とヨーロッパの両方に対して低レイテンシ（<100ms）のWebホストに関する情報を探しています。 ホストは、米国またはヨーロッパにあります。 待ち時間は、米国、英国、オランダ、スウェーデン、ノルウェーにとって最も重要です。 管理されたホスティングを提供できる必要があります。 複数の場所でホスティングすることは私が探しているものではありません。 回答には、複数の場所、できればロサンゼルス、ニューヨーク、ロンドン、アムステルダム、オスロからの少なくともいくつかの待ち時間情報を含める必要があります。また、このホストでのあなたの経験に関するいくつかの情報が推奨され、暴言をせず、パッケージの詳細を提供してください（SLA、専用またはVPSなどの有無にかかわらず）。 私自身の小さな研究から、おそらくニューヨークに拠点を置くホストはこれらすべての場所に低レイテンシーを提供できることを発見しましたが、私自身のpingがオランダからニューヨークへの約85msである以外、バックアップする統計はあまりありません。

1 web-hosting  latency