commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [Commons-VFS] low performance on small files
Date Sat, 10 Apr 2010 15:00:19 GMT
Yes, your comment makes sense. I can't say why it behaves this way without looking at the code.
I don't use the FTP protocol support myself and didn't write it, so my motivation for improving
it isn't that great. I have gotten in the habit of applying patches to the FTP support that
I can verity since it seems to be fairly popular. But I'm spread pretty thin between my day
job and all the open source projects I contribute to.

Ralph

On Apr 10, 2010, at 4:46 AM, Kirill Safonov wrote:

> Hi,
> 
> Does my last remark make sense?  
> FTPClientWrapper executes lot of FTP commands without changing and restoring
> the current directory. I'm just curious why it does this for ls().
> 
> Regards,
> Kirill
> 
> -----Original Message-----
> From: Kirill Safonov [mailto:kirill.safonov@gmail.com] 
> Sent: Wednesday, April 07, 2010 11:11 AM
> To: 'Commons Users List'
> Subject: RE: [Commons-VFS] low performance on small files
> 
> Thanks, Ralph,
> 
> There's one more relevant point: to issue LIST command,
> FTPClientWrapper.listFilesInDirectory() changes the current directory back
> and forth, resulting in 3 extra commands. Is there any FTP server-side
> limitation that prevents from doing "LIST <path>" instead of "CD <path>;
> LIST; CD <back>"?
> 
> Regards,
> Kirill
> 
> -----Original Message-----
> From: Ralph Goers [mailto:ralph.goers@dslextreme.com] 
> Sent: Wednesday, April 07, 2010 1:31 AM
> To: Commons Users List
> Subject: Re: [Commons-VFS] low performance on small files
> 
> Your analysis sounds right and is probably true on most of the protocols. If
> you have suggestions on ways to improve this they would be most welcome.
> iss
> Ralph
> 
> On Apr 6, 2010, at 9:36 AM, Kirill Safonov wrote:
> 
>> Hello community,
>> 
>> Commons VFS appears to be very inefficient when handling lots of small
> files
>> via FTP. 
>> 
>> Indeed, to upload a single file (in my case it's
>> /opt/lampp/htdocs/ftp_root/FtpJava/src/foo2/qqq.txt - sorry for such a
> long
>> path) in does:
>> 
>> ------ refresh the file by calling 'LIST' at the parent directory (since
>> it's was not resolved before)
>> 
>>> PWD 
>> 257 "/opt/lampp/htdocs/ftp_root" 
>>> CWD FtpJava/src/foo2 
>> 250 Directory successfully changed. 
>>> PORT 192,168,0,112,39,215 
>> 200 PORT command successful. Consider using PASV. 
>>> LIST 
>> 150 Here comes the directory listing. 
>> 226 Directory send OK. 
>>> CWD /opt/lampp/htdocs/ftp_root 
>> 250 Directory successfully changed. 
>> 
>> ------ transfer the file
>> 
>>> PORT 192,168,0,112,39,216 
>> 200 PORT command successful. Consider using PASV. 
>>> STOR FtpJava/src/foo2/qqq.txt 
>> 150 Ok to send data. 
>> 226 File receive OK. 
>> 
>> ------ refresh the file again by calling 'LIST' for the parent directory
>> (FtpFileObject.onChange() calls FtpFileObject.getInfo(true))
>> 
>>> PWD 
>> 257 "/opt/lampp/htdocs/ftp_root" 
>>> CWD FtpJava/src/foo2 
>> 250 Directory successfully changed. 
>>> PORT 192,168,0,112,39,236 
>> 200 PORT command successful. Consider using PASV. 
>>> LIST 
>> 150 Here comes the directory listing. 
>> 226 Directory send OK. 
>>> CWD /opt/lampp/htdocs/ftp_root 
>> 250 Directory successfully changed.
>> 
>> This way lot of time is taken by refreshing siblings by issuing LIST for
> the
>> same directory, while single refresh at the end of the group transfer is
>> enough.
>> 
>> Did anyone experience this, did anyone tweak this behavior?
>> 
>> Thanks,
>> Kirill
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message