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

我们有一个代理，它从JMS队列中获取消息并将其发送到FTP文件夹。我们现在发现，当FTP上的目标目录已经包含很多文件时，发送到FTP的速度非常慢。（即，当我在一个目录中有大约2000个文件时，它已经需要几秒钟）

这里是我们代理的代码（从JMS获取消息（纯文本）并将其写入FTP）：

我的队列
myQueueConnectionFactory
队列
内容类型
文本/纯文本

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>

我现在的分析是：

只有在使用FTP和VFS时，速度才慢。使用本地文件系统时，速度很快

文件很小，所以现在不是上传时间

网络很快

！速度取决于FTP目录中已有的文件数

可能的解决方案

• 解决速度问题。禁用目录列表
• Workaround：在输出端创建新文件夹（没有一个文件夹被填满太多）

是否有人也发现了同样的问题？如何提高到大目录的FTP速度？

---

感谢您的帮助

一般来说，如果您有性能问题，您应该进行基准测试

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

你也应该考虑到性能问题可能与FTP无关。仅仅因为这是你看到问题所在的频道，并不意味着（仅仅作为一个例子）操作系统在处理大文件夹（如NT以前）时不仅速度慢。FTP是您看到此错误的方式，但这并不意味着它与原因有关

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

---

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

你在FTP上总是会遇到文件量问题，这是一个常见的问题，与JMS无关，要确认这一点，使用像filezilla这样的ftp客户端，尝试列出2000个文件所在的目录…

我相信，无论您是否执行显式目录列表，总会有一个推断目录列表来确定文件写入操作是覆盖还是创建

这就给你留下了另一个解决办法

---

您应该在输出端创建新文件夹。实现一个散列方案来帮助命名文件夹，这样您就知道文件夹不会被填满太多。例如，而不是<代码>文件1234。Ext<代码>考虑<代码>文件/ 1/2 / 3/4。p> 似乎每次发送消息时都会创建到FTP的连接。有没有可能改进这种性能？持久连接到FTP？我们发现速度取决于FTP目录中的文件数！哇-似乎发送到FTP总是会对所有文件产生一个ls。

<?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>