在我的web服务中,我打开文件流到本地磁盘上的文件。我保持这种服务的一生。对于每个查询,我使用文件流来读取磁盘。 我这样做是为了避免在每个查询中重新打开文件流。这条路径的延迟很关键(应少于几毫秒)。我使用SSD来将磁盘IO时间保持在0.1ms或更短。长时间保持C#文件流打开是否安全?
文件流可以在很长一段时间(天)内变坏(无效)。在每个查询中重新打开文件流是否安全?如果我必须重新打开,每秒不断重新打开文件流的开销是多少?
在我的web服务中,我打开文件流到本地磁盘上的文件。我保持这种服务的一生。对于每个查询,我使用文件流来读取磁盘。 我这样做是为了避免在每个查询中重新打开文件流。这条路径的延迟很关键(应少于几毫秒)。我使用SSD来将磁盘IO时间保持在0.1ms或更短。长时间保持C#文件流打开是否安全?
文件流可以在很长一段时间(天)内变坏(无效)。在每个查询中重新打开文件流是否安全?如果我必须重新打开,每秒不断重新打开文件流的开销是多少?
只要你需要保持文件打开是安全的。
它是否适合您的情况 - 您需要自己决定。重新打开文件不应该很慢(即使在常规驱动器上),但是您需要尝试测量自己的身份,但您知道确切的性能目标。
选择这个作为答案,即使另一个给出了很好的建议,因为这是我的问题的唯一直接答案。 – user201511
我会让文件打开的唯一问题是,如果应用程序因任何原因失败,并且无法从其当前位置恢复以关闭流;在KERNEL32
的CreateFile
切入点,它是用来打开文件作出如下声明:
当应用程序使用完对象通过的CreateFile返回的句柄,使用CloseHandle函数关闭句柄。这不仅可以释放系统资源,还可以对共享文件或设备以及将数据提交到磁盘等事情产生更广泛的影响。在适当的时候,在这个主题中有具体细节。
所以我认为这是更合适的每一次打开和关闭FileStream
。
我同意,将文件留待长时间阅读似乎是一种风险,违背了开放,阅读和关闭资源的最佳做法。 – AdamV
谢谢,它听起来像是正确的做法是每次重新打开。 – user201511
@ user201511,请记住将其标记为我自己和社区其他人的答案。 –
如果您担心延迟问题,是否有原因导致您没有在静态内存中加载文件内容?我认为这个问题应该是你应该用什么样的模式来快速访问内容。 – AdamV
该文件太大而不适合内存。我有一个索引,可以让我直接找到正确的偏移量并从那里读取。它不应该超过1 IO。读取的数据量很小。 – user201511
您是否编写过测试工具以尝试打开单个文件流而不打开和关闭。我建议你试着写一个测试,并比较结果。 – AdamV