不幸的是，使用大型数据集时，序列化和反序列化结构总是很费时间。DataTable特别是，它们是相当复杂的对象，因为它们具有行和列，这些行和列通常附加有许多元数据-
即使它看起来像是基本表。

DataTablevs List<POCO>：

考虑是否真的需要将序列化为DataTable。您能否创建一个更简单的POCO并序列化一个List<YourRecord>？换句话说，如果您不需要字段和列上的额外属性，并且可以序列化为更简单的格式，则可能更快，更节省空间。然后还原到DataTable必要的位置。

另一个选择是将拆分DataTable为较小的集合，将它们序列化并存储在较小的部分中。您可能会发现这种性能更高。 您应该能够对此进行基准测试。

基准测试：

最终，Redis缓存应在重新查询数据源的时间上有所改进。您可以使用术语takes too much time，但是如果从缓存中获取数据需要2秒钟，而查询数据源则需要8秒钟，那么这是一个很大的提升。但是唯一可以确定的方法是进行基准测试。

• 设置环境，以便仅运行必要的工具。 在运行基准测试时不要执行其他任务，因此不会引入任何偏见。

• 记录序列化一个序列所花费的时间DataTable。多次执行此操作并取平均值。

  var start = DateTime.Now;
  

  // Serialize
  var duration = DateTime.Now - start;

• 使用不同大小的DataTables进行试验，看看是否找到可接受的时间。

• 尝试使用其他序列化库，例如JSON.NET。尽管可以很好地保留所有ServiceStack，但这可以帮助您确定这是ServiceStack.Text的不足还是大型数据集的问题。

• 重复进行反序列化的过程。

记忆：

如果使用大型数据集，那么您的应用程序和缓存是否都具有足够的内存？您的应用程序中的内存可能是瓶颈。在执行操作时，您应该观察系统的活动监视器，并确保您不会耗尽内存并让系统执行分页。如果发现这种情况，请考虑增加RAM或将DataTable分成较小的数据集，如前所述。

潜伏：

如果要通过网络而不是在同一台计算机上连接到Redis服务器，是否检查了网络的延迟？您可能希望在应用程序服务器和缓存服务器之间ping通，并确保您的ping通较低。特别是如果您发现缓存简单对象比较慢。

Redis？

如果您发现无法缩短缓存和还原时间，那么使用Redis可能不是一个很好的选择。也许static DataTable在应用程序内存中使用会更合适。换句话说，通过将缓存保留在应用程序内存中，就不必担心序列化和反序列化了。当然，您可能需要注意确保应用程序有足够的可用内存来执行此操作。
但是，如果您不得不选择此选项，我会感到惊讶 。

摘要：

最终，如果没有看到您的数据集或对正在构建的服务的了解，最终只会获得关于如何最大程度地缩小问题根源的通用建议。关键建议是，DataTable如果要使用更简单的结构，则不要使用“
a”，而是对每个操作进行基准测试以确定任何瓶颈。

我希望这有帮助。