[
https://issues.apache.org/jira/browse/SSHD-1217?focusedWorklogId=672171&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-672171
]
ASF GitHub Bot logged work on SSHD-1217:
----------------------------------------
Author: ASF GitHub Bot
Created on: 29/Oct/21 20:21
Start Date: 29/Oct/21 20:21
Worklog Time Spent: 10m
Work Description: tomaswolf commented on pull request #206:
URL: https://github.com/apache/mina-sshd/pull/206#issuecomment-955025850
> Great - it just occurred to me that perhaps we should consider making this
new behavior **configurable** where the feature is enabled by default. This
way, if any of the normal clients is somehow affected and we suspect this code
is to blame we can have a "kill-switch" for it. On the other hand, one could
make the claim that we already have way too many configuration properties. Up
to you - I trust your judgement.
Initially I thought "this is more a bug fix than a feature". But there is
one case where indeed this bypassing of the `FileSystem` abstraction might make
a difference. If the user installed his own subclass of
`SftpFileSystemProvider` that does funny things, then not using
`Files.newDirectoryStream()` for the iteration might make a difference.
So take a look at #207, please. That is a solution that does _not_ bypass
`Files.newDirectoryStream()`, yet it has the exact same effect as this change
here. It caches the `SftpClient.Attributes` on the `SftpPath`. This is inspired
by the Java `FileTreeWalker`, which also does this and re-uses the cached
attributes inside the walk. My change re-uses them in the directory iteration,
but not otherwise. The same mechanism is then also used to reduce multiple
calls to `readRemoteAttributes` where it's safe to do so.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 672171)
Time Spent: 2h 10m (was: 2h)
> Slow performance listing huge number of files on Apache SSHD server
> -------------------------------------------------------------------
>
> Key: SSHD-1217
> URL: https://issues.apache.org/jira/browse/SSHD-1217
> Project: MINA SSHD
> Issue Type: Improvement
> Affects Versions: 2.6.0
> Reporter: Roberto Deandrea
> Assignee: Thomas Wolf
> Priority: Minor
> Fix For: 2.7.1
>
> Attachments: sftp-sshd-fe-listing-pr206.log.zip,
> trace.ssh-frontend-sftplist.finest.log.zip
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Hi Thomas,
> I noted slow performance listing files on the front-end Apache SSHD server in
> the same scenario as https://issues.apache.org/jira/browse/SSHD-1215
> The front-end Apache SSHD server is configured with a Filesystem built upon
> SFTPFileSystemProvider to proxy files to an Apache SSHD back-end server.
>
> In the /inbox folder of the Apache SSHD backend server I have 2000 files.
> The client sftp ls commands take 2 secs on the backend Apache SSHD server,
> instead it takes about 48 secs on the front-end Apache SSHD server.
> For greater number of files in the /inbox folder times are getting worse.
>
> I have full traces of sftp list commands to front-end Apache SSHD server
> that is attached to this jira.[^trace.frontend.sshd.log.zip]
> I looked through the traces on the front-end server and it seems to me that
> for every files in the folder the sftp client on the front-end server creates
> a SSH_MSG_CHANNEL_DATA generating tcp traffic that slow down the performance
> of the list command.
> Obviously this does not happen when a sftp client connects directly to the
> backend Apache SSHD server.
> Can you take a look at traces on the front-end Apache SSHD server ?
> Do you think it's possbile change something to improve performance of list
> files in this situation ?
>
> Thanks in advance
>
> Kind Regards
> Roberto
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
