在 C# 中访问 UNC 路径的最佳方法

发布于 2024-07-20 13:57:11 字数 333 浏览 5 评论 0原文

我们正在构建一个将存储大量图像的应用程序。 我们在 GoGrid.com 有一个虚拟化环境,我们希望利用他们的云存储。

不知道到底如何表达,但如果我们(在我们的代码中)指定 unc 路径和信用来放置或检索图像,这似乎效率非常低(连接、获取图像、断开连接)

如果我们有大量图像或许多用户同时执行此操作,似乎它会让任何普通服务器屈服。

所以我的问题是,如果没有巨大的驱动器来运行您的网站,我们应该如何实现这一目标? 我们再次选择 GoGrid 云星而不是 Amazon S3,因为一切都在一个很好的保护伞下。 可通过 UNC 路径和特定用户名/密码访问云存储。

谢谢!

We are building an application that will be storing a lot of images. We have a virtualized environment at GoGrid.com and we were hoping to utilize their cloud storage.

Not sure exactly how to word this, but if we (in our code) specify the unc path and creds to place or retrieve an image, that seems terribly inefficient (connect, get image, disconnect)

If we have a large volume of images or many users performing this at once, it seems like it would bring any normal server to it's knees.

So my question is, short of having huge drives that your website is running on, how should we aim to accomplish this? Again, we are opting for the GoGrid cloud starge versus Amazon S3 since everything is under one nice umbrella. The cloud storage is accessible via a UNC path and a specific username/password.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

绻影浮沉 2024-07-27 13:57:11

C# 可以像本机路径一样使用 unc 路径,使用本机操作系统文件 i/o。 通常,您不会“连接/检索/断开连接”,而是一旦建立与远程服务器的连接就会保持,就像映射驱动器一样。 仅仅因为您没有驱动器号,并不意味着没有连接。

或者(对 go grid 一无所知),您可以只映射驱动器或使用 Windows 中的脱机文件功能将最常访问的文件保留在本地缓存。

C# can use unc paths like native paths, using the native operating system file i/o. Normally, you don't "connect/retrieve/disconnect", but rather once established the connection to the remote server will be held, as if you mapped a drive. Just because you don't have a drive letter for it, it doesn't mean there's no connection.

Alternatively (and knowing nothing about go grid), you could either just map a drive or use the Offline Files feature in Windows to keep the most frequently accessed files cached locally.

鹿港小镇 2024-07-27 13:57:11

如果您认为随着时间的推移您可能会更改文件访问方法,那么一定要保持抽象。 从简单的 UNC 实现开始,但稍后您可以更改为 Web 服务或 REST 实现。

If you think you might be changing the file access method over the course of time, then be certain to keep it abstract. Start off with a simple UNC implementation, but you would then be able to change to a web service or REST implementation later.

独闯女儿国 2024-07-27 13:57:11

我以前没有使用过大容量访问服务器,但在我看来,您正在寻找非常轻量级的访问 UNC 路径的东西。 Facebook 的架构基于轻量级 HTTP 实现和刀片服务器,使用单个 10TB 文件系统进行负载平衡,但听起来还没有完全实现。 如果您想最大化从连接中获得的内容,请尝试按连接/读取/断开顺序拉取多个文件。 请注意,这会让您的用户等待时间更长一些,而 google 慢 20 毫秒会导致用户数量下降 20%。 除此之外,我不知道还有什么比简单地访问路径更快的方法。

I have not worked with high volume access servers before, but it sounds to me like you are looking for something very lightweight accessing a UNC path. Facebook has an architecture based on a lightweight HTTP implementation and blade servers for load balancing using a single 10TB filesystem, but you don't sound like you're quite there yet. If you want to maximize what you get out of the connects, try to pull multiple files in a connect/read/disconnect sequence. Be warned that this will make your users wait a little while longer, and 20ms slower for google lead to something like a 20% drop in users. Aside from that, I don't know of any faster way to do it than to simply access the path.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文