爲什麼FTP發送取決於其目錄大小？

我們有一個代理從JMS隊列中獲取消息並將它們發送到FTP文件夾。我們現在發現，當FTP上的目標目錄已經包含大量文件時，發送到FTP的速度非常慢。（即當我有一個目錄在2000年左右的文件，它已經花費幾秒鐘）爲什麼FTP發送取決於其目錄大小？

這裏我們代理的代碼（從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 lookes這樣的：對於

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

我現在的分析：

在VFS中使用FTP時速度很慢。使用本地文件系統時 - 速度很快。
文件是微小的 - 所以它不是上傳時間
網絡是快速
速度在目錄中已經依賴於文件的數量上的FTP！

可能的解決方案？

修復了速度問題。禁用目錄列表？
Workaraound：在輸出創建新的文件夾（即不是一個文件夾被塗抹太多）

是否有人還發現了同樣的問題？如何改進大目錄的FTP速度？感謝您的任何幫助

來源

2012-08-14 FiveO

好像每次發送消息時都會創建與FTP的連接。有沒有可能改善這種表現？持久連接到FTP？ – FiveO 2012-08-28 09:42:22

我們發現速度取決於位於FTP目錄中的文件數量！哇 - 似乎發送到FTP總是使所有文件ls。 – FiveO 2012-09-27 06:52:14

我相信，無論您是否執行明確的目錄列表，總會有一個推斷的目錄列表來確定文件寫入操作是覆蓋還是創建。

這使您有其他的解決方法。

您應該在輸出中創建新的文件夾。實施散列方案以幫助文件夾命名，以便您知道文件夾不會被填滿太多。例如，而不是file1234.ext考慮file/1/2/3/4.ext。

來源

2012-10-04 03:30:43

一般來說，如果你有性能問題，你應該基準。

嘗試從命令行FTP客戶端執行相同的操作並查看慢點在哪裏。將每個命令逐一運行，可以讓您查看在將文件放入具有多個文件的文件夾與空文件夾時，確切步驟執行的不同。

您還應該考慮性能問題可能不適用於FTP。僅僅因爲這是你看到這個問題的渠道，並不意味着（純粹是一個例子），操作系統在處理大型文件夾（如NT曾經是）方面不僅很慢。 FTP是你看到這個錯誤的方式，這並不意味着它與原因有關。

要測試這個，我會直接訪問服務器並訪問包含這些文件的文件夾。最後，如果這些都沒有給你任何線索，我可能會嘗試在不同的端點上做同樣的事情，看看是否存在持續性問題。

來源

2012-10-03 15:40:22 joocer

你總是會遇到有關FTP文件數量的問題，這是一個常見問題，並且與JMS無關，爲了確認，使用ftp客戶端如filezilla並嘗試列出2000文件所在的目錄存在...

來源

2012-10-04 00:02:50

爲什麼FTP發送取決於其目錄大小？

回答

相關問題