我有一个简单的Web应用程序模块,它基本上接受从PageLoad
通过移动客户端应用程序保存zip文件的请求。
现在,我要做的是解压缩文件并读取其中的文件并进一步处理..包括将条目输入数据库。
更新:zip文件及其内容的大小会相当小,因此服务器不应承受太多负担。
更新2:我刚刚阅读了when IIS queues requests(全球/应用级别)。那么这是否意味着我不需要实现复杂的请求处理机制,IIS可以自己处理应用程序?
更新3:我正在寻找卸载下载zip的处理,不仅是为了最大限度地减少开销(在性能方面),而且为了避免{{{ 1}}处理文件并将记录更新到同一个表中时。在多个设备请求页面和后台任务处理数据库并行更新的情况下会导致异常。
截至目前,我已经将两个解决方案归零:
倾向于table-locking
我将尝试实现,因为它似乎不太依赖于配置。 v / s在服务器端手动配置作业/计划。
那么,你们为此目的推荐我什么?
此外,在请求并保存在服务器端的zip文件之后,客户端&执行此操作后将释放服务器端连接。不想让我的IIS负担。
想象一下,有几百个客户同时请求该页面。
我实际上之前没有使用它们,所以任何样品或操作方法都会更受欢迎。
答案 0 :(得分:4)
我建议使用TPL和Rx扩展:将解压缩的文件列表设为可观察的集合,并为每个项目异步启动新任务。
答案 1 :(得分:1)
我建议使用队列系统。
收到文件后,您将把路径保存到线程同步的队列中。同时,后台工作者(或者最好是另一台机器)将检查此队列中是否有新文件,并使该条目出列以进行处理。
这样您就不会启动未知数量的线程(每个zip文件),并且可以在一个位置处理zip文件。这样,当负载过重时,您还可以更轻松地将zip处理代码移动到另一台机器上。您只需要访问一个公共队列。
最简单的可能是使用带有Queue
对象的静态lock
。它是最容易实现的,不需要外部资源。但是,当您的应用程序回收时,这将导致队列丢失。
你提到丢失zip文件不是一个选项,如果你不想依赖外部资源,这种方法不是最好的。根据您的负载,使用外部资源可能是值得的 - 这意味着将zip文件上传到另一台计算机上的公共存储,并将消息添加到另一台计算机上的队列中。
以下是本地队列的示例:
ConcurrentQueue<string> queue = new ConcurrentQueue<string>();
void GotNewZip(string pathToZip)
{
queue.Enqueue(pathToZip); // Added a new work item to the queue
}
void MethodCalledByWorker()
{
while (true)
{
if (queue.IsEmpty)
{
// Supposedly no work to be done, wait a few seconds and check again (new iteration)
Thread.Sleep(TimeSpan.FromSeconds(5));
continue;
}
string pathToZip;
if (queue.TryDequeue(out pathToZip)) // If TryDeqeue returns false, another thread dequeue the last element already
{
HandleZipFile(pathToZip);
}
}
}
这是一个非常粗略的例子。每当zip到达时,您都会添加到队列的路径。同时,后台工作者(或多个,示例s线程安全)将处理一个接一个的zip,从队列中获取路径。 zip文件将按照它们到达的顺序处理。
您需要确保您的应用程序不会同时回收。但是,在本地计算机上拥有的所有资源都是如此,当您的计算机崩溃时它们将会丢失。
答案 2 :(得分:0)
我相信你过早地进行了优化。
您提到了表锁定 - 您使用的是哪种数据库?如果添加新行或更新现有行,则大多数配置中的大多数现代数据库都将:
我建议从一个简单的方法开始
//Unzip
//Do work
//Save results to database
得到一些证明它太慢了。