我在networking驱动器(传统硬盘)上有一个集中的文件夹位置,由不同应用程序服务器上运行的一些Web服务共享。 这些服务将通过HTTP请求conitinually处理传入的文件,并将写入此位置。
每个请求将获得具有唯一名称的自己的子文件夹。 一旦保存了特定请求的所有文件,保存文件的服务将通知另一个内部服务,该服务将从该请求文件夹中读取这些文件并执行进一步的任务。
例如,
如果D:/MyNetworkFolder/
是父目录,并且ServiceA处理Request1和ServiceB处理Request2,则这两个服务都将尝试将请求的传入文件(总大小高达2GB)保存在D:/MyNetWorkFolder/Request1
D:/MyNetworkFolder/Request2
。 一旦为一个请求保存了所有文件,另一个服务将从D:/MyNetworkFolder/RequestNumber.
读取这些文件D:/MyNetworkFolder/RequestNumber.
并执行其任务。
因此,在高峰时段,总是会有一组服务试图将新文件写入networking文件夹,另一组服务试图从networking文件夹中保存的文件中读取。 可能还有另一种服务试图删除完全处理的文件。
这种types的并行文件处理是可能的吗? 它会影响应用程序的I / O性能或硬盘的健康状况,因为多个服务试图同时从同一个父位置读/写? 我们的另一个select是确保每个服务获得自己的物理networking驱动器或考虑使用SSD。
所有服务器都运行在Windows Server 2008及更高版本上,Web服务使用C#和.NET编写。
多个Web服务是否可以同时写入集中式networking目录/文件夹位置?
总之是的。
在实践中,您将需要对应用程序和存储进行基准testing,并正确调整其大小
您可能还想考虑:
在附注中,在2016年,我不会用Windows Server 2008作为目标平台来构build新的自定义应用程序…
Is this type of parallel file processing possible? Would it affect the application's I/O performance or the hard disk's health because multiple services are trying to read/write from the same Parent location at the same time?
您基本上描述了共享networking文件夹从共享networking文件夹的黎明以来如何工作。 性能将取决于您的基础设施,但这样做并没有什么内在的性能影响。
这一切都是完美的,可能的和标准的。 文件服务器能够处理几个客户,都希望一次请求读取和写入。
至于performance和健康,这些都归结为指标…
性能:您可以为文件服务器,应用程序或两者定义可接受的性能度量标准,并使用性能监视工具来确保这些度量标准得以保留。
健康:如果您购买合理的质量组件,那么您应该能够实现体面的正常运行时间。 一旦你超过了某一点,那么你应该考虑高可用性的解决scheme,因为没有保证组件永远不会失败,所有的操作系统毕竟需要停机维护。