1

JMS キューからメッセージを取得して FTP フォルダーに送信するプロキシがあります。現在、FTP 上のターゲット ディレクトリにすでに多くのファイルが含まれている場合、FTP への送信が非常に遅いことがわかりました。（つまり、ディレクトリに約2000個のファイルがある場合、すでに数秒かかります）

プロキシのコード (JMS からメッセージ (プレーンテキスト) を取得し、FTP に書き込みます):

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse" name="myProxy" statistics="disable" trace="disable" transports="jms">
<parameter name="transport.jms.Destination">myQueue</parameter>
<parameter name="transport.jms.ConnectionFactory">myQueueConnectionFactory</parameter>
<parameter name="transport.jms.DestinationType">queue</parameter>
<parameter name="transport.jms.ContentType">
    <rules>
        <jmsProperty>contentType</jmsProperty>
        <default>text/plain</default>
    </rules>
</parameter>
<target faultSequence="rollbackSequence">
    <inSequence>
        <log level="custom">
            <property name="STATUS" value="myProxy called"/>
        </log>
        <property name="ClientApiNonBlocking" scope="axis2" action="remove"/>
        <property name="OUT_ONLY" value="true"/>
        <property name="transport.vfs.ReplyFileName" expression="fn:concat(get-property('SYSTEM_DATE','yyyyMMddHHmmss_SSS'), '_result.txt')" scope="transport"/>

        <send>
            <endpoint key="myFTPendpoint"/>
        </send>
    </inSequence>
</target>

FTPEndpoint は次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<endpoint xmlns="http://ws.apache.org/ns/synapse" name="myFTPendpoint">
    <address uri="vfs:ftp://USER:PASSWORD@SERVER.com/path/toSomewhere?vfs.passive=true"/>
</endpoint>

今のところ私の分析：

  1. VFS で FTP を使用する場合にのみ遅くなります。ローカル ファイル システムを使用すると、高速になります。
  2. ファイルは小さいので、アップロード時間ではありません
  3. ネットワークが速い
  4. !速度は、FTP のディレクトリに既にあるファイルの数に依存します!

可能な解決策？

  • 速度の問題を修正します。ディレクトリ リストを無効にしますか?
  • 回避策: 出力で新しいフォルダーを作成します (1 つのフォルダーがいっぱいにならないようにします)。

誰かが同じ問題を発見しましたか? また、大きなディレクトリへの FTP 速度を改善するにはどうすればよいでしょうか? 助けてくれてありがとう

4

3 に答える 3

1

明示的なディレクトリリストを作成するかどうかに関係なく、ファイルの書き込み操作が上書きか作成かを判断するために、常に推測されるディレクトリリストがあると思います。

これにより、他の回避策が残ります。

出力に新しいフォルダを作成する必要があります。フォルダーの命名を支援するハッシュスキームを実装して、フォルダーがいっぱいになりすぎないようにします。たとえば、をfile1234.ext検討する代わりにfile/1/2/3/4.ext。

于 2012-10-04T03:30:43.923 に答える
1

一般に、パフォーマンスの問題がある場合は、ベンチマークを行う必要があります。

コマンドラインFTPクライアントから同じアクションを実行してみて、スローポイントがどこにあるかを確認してください。各コマンドを1つずつ実行すると、ファイルが多いフォルダーと空のフォルダーを配置するときに、どの正確なステップの実行が異なるかを確認できます。

また、パフォーマンスの問題はFTPでは発生しない可能性があることも考慮する必要があります。それが問題が発生しているチャネルであるからといって、（純粋に例として）大きなフォルダ（以前はNTのように）を処理するときにOSが遅いだけではないという意味ではありません。FTPはこのエラーが表示される方法であり、原因に関連しているわけではありません。

これをテストするには、サーバーに直接アクセスし、ファイルが含まれているフォルダーにアクセスします。

最後に、それらのどれもあなたに手がかりを与えない場合、私はおそらく別のエンドポイントで同じことをして、永続的な問題があるかどうかを確認しようとします。

于 2012-10-03T15:40:22.683 に答える
1

その量のファイルを使用すると、FTP で常に問題が発生します。これは一般的な問題であり、JMS とは関係ありません。確認するには、filezilla などの ftp クライアントを使用して、2000 個のファイルが存在するディレクトリを一覧表示してみてください...

于 2012-10-04T00:02:50.817 に答える