10

一些背景故事：我正在开发一个 Web 应用程序，该应用程序需要相当多的时间来准备/处理数据，然后再将其提供给用户进行编辑/操作。数据请求任务 ~ 15 / 20 秒完成，几秒处理。在那里，用户可以即时操作值。对值的任何操作都需要完全重新处理数据。

更新：为避免混淆，我只进行 1 次数据调用（命中 15 秒），然后希望将结果保存在内存中，这样我就不必再次调用它，直到用户 100% 完成使用它. 因此，第一次拉取需要一段时间，但是，使用 Ajax，我将访问内存中的数据以不断更新并将响应时间保持在 2 秒左右（我希望如此）。

为了提高效率，我将初始数据移动到内存中并使用 Ajax 调用回服务器，这样我就可以减少处理时间来处理此用户更新时发生的重新计算。

这是我的问题，考虑到性能，什么是存储这些数据的最佳方式，假设在任何给定时刻只有 1 个用户将使用这些数据。

此外，用户可能会在此过程中工作几个小时。当用户使用数据工作时，如果他们的会话以某种方式中断，我将需要某种故障保护来保存用户的当前数据（在数据库或序列化二进制文件中）。换句话说，我需要一个具有适当钩子的解决方案，以允许我在用户断开连接/分心太久的情况下转储内存对象的数据。

到目前为止，这是我的想法：

会话状态 - 优点：锁定一个用户。具有符合我的故障安全要求的会话结束事件。缺点：我当前选项中最慢的性能。会话结束事件有时很难确保正确触发。

缓存 - 优点：良好的性能。可以访问依赖项，这可能是以后的奖励，但在当前范围内并不真正有用。缺点：除了基于时间间隔的写入之外，没有简单的故障保护步骤。全球范围 - 必须确保用户不会与彼此的工作发生冲突。

静态 - 优点：最佳性能。易于维护，因为我可以直接利用我当前的班级结构。缺点：除了基于时间间隔的写入之外，没有简单的故障保护步骤。全球范围 - 必须确保用户不会与彼此的工作发生冲突。

有人对我应该选择的选项有任何建议/意见吗？

谢谢！

更新：忘了提，我正在使用 VB.Net、Asp.Net 和 Sql Server 2005 来执行此任务。

4

6 回答 6

2

我将投票给秘密选项#4：为此使用数据库。如果您谈论的是 20 秒以上的数据周转时间，那么考虑到您提供的选项的限制，您不会通过尝试在内存中执行此操作来获得任何收益。您也可以在数据库中设置它（给它一个自己的表，如果需求那么大，甚至可以给它一个单独的数据库）。

于 2009-01-30T18:45:29.717 回答
0

使用 Session，但不要依赖它。

简单地说，让用户“命名”数据集，并为用户主动保存它，无论是自动的，还是通过像“保存”按钮这样简单的东西。

您不能仅仅因为会话（通常）绑定到用户浏览器实例而依赖会话。如果他们不小心关闭了浏览器（单击 X 按钮、他们的 PC 崩溃等），那么他们将丢失所有工作。这会很讨厌。

一旦用户对数据的“持久”状态进行了这种控制，您就可以依靠 Session 将其保存在内存中并将其用作缓存。

于 2009-01-30T18:34:34.280 回答
0

我认为您几乎只是用优点/缺点回答了您的问题。但是，如果您正在寻找一些同行验证，我会投票给 Session。尽管性能较慢（您知道慢多少吗？），但无论如何您的处理都需要很长时间。你认为用户会知道 15 秒和 17 秒之间的区别吗？两者在网络术语中都是“永远”的，所以选择似乎最容易实现的那个。

也许有点跑题了。我建议将这些长处理调用放在异步（不要与 AJAX 的异步混淆）页面中。

看看这篇文章，如果没有意义，请回复我。

http://msdn.microsoft.com/en-us/magazine/cc163725.aspx

于 2009-01-30T18:34:58.320 回答
0

我建议在将初始结果发送给用户时，在新的数据库表中创建数据副本（我们称之为 EDIT）。如果性能是一个问题，请在后台线程中执行此操作。

当用户编辑数据时，更新表（如果性能成为问题，也可以在后台线程中）。如果必须使用线程，则必须确保在开始更新行之前完成第一个线程。

这允许用户在对结果感到满意时离开、返回，甚至重新启动浏览器并提交。

于 2009-02-09T16:34:00.090 回答
0

我会使用在任何页面加载中存储数据的缓存方法。您可以命名要存储数据的缓存以避免冲突。

为了跟踪用户所做的更改，我会采用更老式的方法：每次用户进行更改时附加到文本文件，然后每隔一段时间扫描该文件以将更改保存回 DB。如果您根据用户/帐户或其他会话唯一指示符命名文件，则不会出现冲突问题，并且应用程序（或其他一些支持应用程序，这通常可能是一个更好的主意）可以扫描所有此类文件并即使会话结束也更新数据库。

可以调整第一部分以错开更多的写入：将更改保存到 Session，然后每隔一段时间将其写入文件，然后以更大的间隔扫描文件。您可以将其调整为性能并选择可能的用户更改损失级别。

于 2009-02-11T22:04:46.573 回答
0

其他人提到的一种可能的替代方法是将数据存储在客户端上。假设数据集不是太大，并且操作它的代码可以在客户端处理。您可以将数据存储为 XML 数据岛或 JSON 对象。然后可以操纵/处理这些数据并处理所有客户端，而无需往返服务器。如果您需要将此数据持久保存回服务器，则最终生成的数据可以通过 AJAX 或标准回发来发布。

如果这不符合您的要求，我会按照其他评论的建议将其存储在 SQL 服务器上。

于 2009-02-12T00:23:03.137 回答