处理非常大的 SFTP 上传 - Cocoa
我正在开发一个小型免费 Cocoa 应用程序，其中涉及一些 SFTP 功能，特别是上传功能。 该应用程序即将完成，但是在上传包含大量文件的文件夹时我遇到了一个非常糟糕的问题。
我使用 ConnectionKit 来处理上传：
CKTransferRecord * record;
record = [connection recursivelyUpload:@"/Users/me/large-folder"
to:@"/remote/directory"];
这适用于大多数文件和文件夹。 尽管在本例中 @"/Users/me/large-folder" 有超过 300 个文件。 调用此方法会使我的 CPU 旋转至 100%，持续约 30 秒，并且我的应用程序没有响应（mac 旋转球）。 30 秒后，我的上传已排队并且工作正常，但这并不理想。 显然，无论枚举这些文件，都会导致我的应用程序锁定，直到完成为止。
不太确定该怎么办。 我对任何解决方案持开放态度 - 即使使用不同的框架，尽管我已经完成了我的研究和 ConnectionKit 似乎是目前最好的。
有任何想法吗？
I'm working on a small free Cocoa app that involves some SFTP functionality, specifically working with uploads. The app is nearing completion however I've run into a pretty bad issue with regards to uploading folders that contain a lot of files.
I'm using ConnectionKit to handle the uploads:
CKTransferRecord * record;
record = [connection recursivelyUpload:@"/Users/me/large-folder"
to:@"/remote/directory"];
This works fine for most files and folders. Although in this case @"/Users/me/large-folder" has over 300 files in it. Calling this method spins my CPU up to 100% for about 30 seconds and my application is unresponsive (mac spinning ball). After the 30 seconds my upload is queued and works fine, but this is hardly ideal. Obviously whatever is enumerating these files is causing my app to lock up until it's done.
Not really sure what to do about this. I'm open to just about any solution - even using a different framework, although I've done my research and ConnectionKit seems to be the best of what's out there.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用鲨鱼。 开始采样，开始下载，一旦挂起结束，就停止采样。
如果输出确认问题出在 ConnectionKit 中，您有两个选择：
开源的美妙之处在于#2 是可能的。 这就是我推荐的。 然后，您不仅将拥有一个快速的 ConnectionKit，而且一旦维护者接受您的补丁，其他使用 CK 的人也可以拥有一个。
如果 Shark 发现问题不存在于 ConnectionKit 中（分析规则#2：您将会感到惊讶），那么您将获得 Shark 关于如何修复您的应用程序的指导。
Use Shark. Start sampling, start downloading, and as soon as the hang ends, stop sampling.
If the output confirms that the problem is in ConnectionKit, you have two choices:
The beauty of open-source is that #2 is possible. It's what I recommend. Then, not only will you have a fast ConnectionKit, but once the maintainers accept your patch, everyone else who uses CK can have one too.
And if Shark reveals that the problem is not in ConnectionKit (rule #2 of profiling: you will be surprised), then you have Shark's guidance on how to fix your app.
由于问题几乎肯定出在枚举上，因此您可能需要将枚举移至异步操作。 他们很可能为此使用
NSFileManager -enumeratorAtPath:。 如果这是主要问题，那么最好的解决方案可能是将这项工作移至其自己的线程上。 鉴于所涉及的时间很长，我怀疑他们实际上是在枚举过程中读取文件的。 解决方案是在上传之前惰性地读取文件。Peter 认为 Shark 很有帮助是正确的，但在成为 Shark 的长期粉丝后，我发现 Instruments 往往会更快地给出更有用的答案。 您可以使用 Instruments 更轻松地向 CPU 采样器添加磁盘 I/O 和内存分配轨道。
如果您仅以 100% 阻塞一个核心，我建议将“活动线程”设置为“主线程”，并将“样本视角”设置为“所有样本计数”。 如果您以 100% 阻塞所有核心，我建议将活动线程设置为“所有线程”，将采样视角设置为“运行采样时间”。
Since the problem is almost certainly on the enumeration, you'll likely need to move the enumeration into an asynchronous action. Most likely they're using
NSFileManager -enumeratorAtPath:for this. If that's the main problem, then the best solution is likely to move that work onto its own thread. Given the very long time involved, I suspect they're actually reading the files during enumeration. The solution to that is to read the files lazily, right before uploading.Peter is correct that Shark is helpful, but after being a long-time Shark fan, I've found that Instruments tends to give more useable answers more quickly. You can more easily add a disk I/O and memory allocation track to your CPU Sampler using Instruments.
If you're blocking just one core at 100%, I recommend setting Active Thread to "Main Thread" and setting Sample Perspective to "All Sample Counts." If you're blocking all your cores at 100%, I recommend setting Active Thread to "All Threads" and Sample Perspective to "Running Sample Times."