5

多分誰かが私にその質問に答えることができます。最近の作業中に、Linuxで使用するとアプリケーション(FTP経由で更新をダウンロードする)が非常に遅いことに気付きました。私はMacでそのようなものを開発しているので、Mac OSではダウンロード速度がそれほど遅く感じられなかったので、以前はその問題に気づきませんでした。しかし、Linuxに移行すると、アプリケーションの動作は大きく異なります。

FTPサーバー(Ubuntuサーバーで実行されているPure FTP)はクライアントと同じLANに接続されているため、インターネット速度の問題は考慮されません。パフォーマンスが低いため、ApacheFTPClientをedtFTPj/Freeに変更しました。違いはまだ顕著ですが、許容範囲内です。テストケースとして、サイズが約30MBの同じファイルを常にダウンロードしました。次に、FTPサーバーログをチェックして、転送速度を確認しました。

自分で見て。上記のVMWareはMac上で動作します。特に明記されていない限り、JavaはOracleJava1.7です。

Apache Commons Net 2.3

コードは次のようになります

  FTPClient ftp = new FTPClient();
  ftp.connect("srv0006");
  ftp.login("anonymous", "asd");
  ftp.setFileType(FTP.BINARY_FILE_TYPE);
  File target = new File("/tmp/pub.tar");
  FileOutputStream fos = new FileOutputStream(target);
  ftp.retrieveFile("/pub.tar", fos);
  fos.close();

これがftpログからの結果です

MacOSはIntelliJIdeaから始まりました

downloaded  (30452736 bytes, 21200.67KB/sec)

MacOSはシェルから始まりました

downloaded  (30452736 bytes, 21471.75KB/sec)

Windows 7(VMWare内)

downloaded  (30452736 bytes, 65243.15KB/sec)

Oracle Javaを実行しているOpenSuse(VMWare内)

downloaded  (30452736 bytes, 5274.56KB/sec)

OpenJDKを実行しているOpenSuse(VMWare内)

downloaded  (30452736 bytes, 7663.68KB/sec)

Ubuntu 12.04.1 LTS

同じLANにギガビットイーサネットで接続された別のPCで実行されています。他のUbuntuマシンはまったく同じように動作しました。20分後に転送を終了します。転送速度を参照してください。

downloaded  (7077888 bytes, 6.10KB/sec)

edtFTP4j 2.4.0

この後、edtFTP4jに移動しました。結果ははるかに良かった。

  FileTransferClient ftp = new FileTransferClient();
  ftp.setRemoteHost("srv0006");
  ftp.setUserName("anonymous");
  ftp.setPassword("asd");
  ftp.connect();
  ftp.downloadFile("/tmp/pub.tar", "/pub.tar");
  ftp.disconnect();

結果は著しく変化しました:

MacOSはIntelliJIdeaから始まりました

downloaded  (30452736 bytes, 109431.60KB/sec)

MacOSはシェルから始まりました

downloaded  (30452736 bytes, 110333.66KB/sec)

Windows 7(VMWare内)

downloaded  (30452736 bytes, 91318.64KB/sec)

Oracle Javaを実行しているOpenSuse(VMWare内)

downloaded  (30452736 bytes, 89312.46KB/sec)

OpenJDKを実行しているOpenSuse(VMWare内)

downloaded  (30452736 bytes, 89041.05KB/sec)

Ubuntu 12.10(VMWare内)

downloaded  (30452736 bytes, 81154.99KB/sec)

i5 Notebook、Wifi(50 MBit / s)で実行されているUbuntu 12.04.1 LTS

downloaded  (30452736 bytes, 2883.84KB/sec)

i5 Notebook、ギガビットイーサネットで実行されているUbuntu 12.04.1 LTS

downloaded  (30452736 bytes, 93822.44KB/sec)

Ubuntu 12.04.1 LTS

前述のPCで実行されている(6.10KB /秒のtxレートのPC)

downloaded  (30452736 bytes, 11633.38KB/sec)

わかりません。ここで何が起こっているのか、誰が手がかりを持っていますか?

さようなら、トルステン..。

4

4 に答える 4

1

いくつかのコードからそれを特定するには、あまりにも多くのことが起こっています。

デフォルトのネットワークパケットサイズ(MTU)、ハードウェアインフラストラクチャ、JVM、OS構成などから何でもかまいません。

あなたはより高いレベルでたくさんのささいなことで遊ぶ必要があります。ハードウェア/OSレベルでMTUサイズをチェックし、それをAPIのソケット作成のデフォルト設定に対応させるようなものです。インフラストラクチャはバッファリングされているか、ウィンドウスケーリングが行われているか、ウイルスチェックが自動化されていますか。

Net Commonsのバッファサイズのデフォルトは1024だと思いますが、それで遊ぶことができます。

それを超えて、あなたはスニファーにドロップダウンして何が起こっているのかを見る必要があります。スイッチが正しく構成されておらず、一方のAPIと他方のAPIの方がうまく機能している可能性があります。

もっと良い答えができたらいいのにと思いますが、ネットワーキングのパフォーマンスに関して言えば、それ自体が研究分野です...

于 2013-01-17T17:59:12.540 に答える
0

多くのシステムでは、FTPのパッシブモードとアクティブモードの間にも大きな違いがあります。特に、サーバーが1つのモードのみを許可し、クライアントがデフォルトで他のモードを使用しようとする場合。私の記憶が正しければ、アクティブモードはパッシブモードよりもわずかに高速ですが、禁止モードを使用すると、転送が100倍または1000倍以上遅くなる可能性があります。そうでない場合は、単にブロックアウトします。

両方のモードが許可されている場合でも、ファイアウォールはアクティブモードをそのままにして、パッシブモードの速度を低下させることがよくあります(またはその逆ですか?)。

于 2013-01-17T18:55:56.357 に答える
0

ここでの 1 つの原因は、さまざまなプラットフォームでのソケットの送受信バッファー サイズです。Windows では、これらは 8k という途方もなく低く設定されているため、TCP スループットが大幅に制限されます。一部の Windows サーバーのバージョンでは、これらが非常に大きな値に設定されています。どれか聞かないで。Unix および Linux プラットフォームの値は 43 ~ 48k 前後です。

于 2013-01-17T18:19:26.967 に答える