为什么FTP发送取决于其目录大小?

时间:2012-08-14 09:51:25

标签: ftp wso2 wso2esb vfs

我们有一个代理服务器从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. 使用FTP和VFS时速度很慢。使用本地文件系统时 - 速度很快。
  2. 文件很小 - 所以不是上传时间
  3. 网络快速
  4. !速度取决于FTP目录中已有的文件数量!
  5. 可能的解决方案?

    • 解决速度问题。禁用目录列表?
    • Workaraound:在输出处创建新文件夹(不是一个文件夹被填充太多)

    有人也发现了同样的问题吗?如何改进FTP到大目录的速度? 谢谢你的帮助

3 个答案:

答案 0 :(得分:1)

通常,如果您遇到性能问题,则应进行基准测试。

尝试从命令行FTP客户端执行相同的操作,并查看慢点的位置。逐个运行每个命令将允许您在放入包含许多文件与空文件夹的文件夹时查看哪些确切步骤的执行方式不同。

您还应该考虑性能问题可能不适用于FTP。只是因为那是你看到问题的频道,并不意味着(纯粹作为一个例子)操作系统在处理大型文件夹(如以前的NT)时不仅速度慢。 FTP就是你看到这个错误的方式,这并不意味着它与原因有关。

为了测试这一点,我将直接访问服务器并访问包含文件的文件夹。

最后,如果这些都没有给你任何线索,我可能会尝试在不同的终点上做同样的事情,看看是否存在持续性问题。

答案 1 :(得分:1)

你总是会遇到FTP问题,这是一个常见问题,并且与JMS无关,要确认,使用像filezilla这样的ftp客户端并尝试列出2000文件存在的目录...

答案 2 :(得分:1)

我相信无论您是否进行明确的目录列表,都会始终使用推断的目录列表来确定文件写入操作是覆盖还是创建。

这将为您提供其他解决方法。

您应该在输出中创建新文件夹。实现散列方案以帮助文件夹命名,以便您知道文件夹不会被填充太多。例如,代替file1234.ext考虑file/1/2/3/4.ext