0

我的方法在 for 循环中调用存储过程 300 次,每次存储过程返回 1200 条记录。我该如何改进呢?我无法消除 300 个电话,但有什么其他方法可以尝试。我正在使用通过 ASP.NET 实现的 REST 服务并使用 IBATIS 进行数据库连接

4

4 回答 4

3

我无法消除 300 个电话

消除 300 个电话。

即使您所能做的只是添加另一个调用原始存储过程 300 次的存储过程,汇总结果,您应该会看到巨大的性能提升。

如果您可以编写一个复制原始功能但结构更适合您的特定用例的新存储过程,并且调用一次,那就更好了。

在代码和数据库之间进行 300 次往返非常简单,即使代码和数据库位于同一系统上也是如此

一旦解决了这个可怕的问题,如果需要,您还可以考虑优化其他事情。

于 2012-09-28T12:40:24.523 回答
1

好吧,如果您必须返回 360,000 条记录,则您必须返回 360,000 条记录。但是你真的需要返回 360,000 条记录吗?从那里开始,一路向下。

于 2012-09-28T12:49:59.973 回答
1

措施。

衡量在服务器端代码中花费的时间。测量在存储过程中花费的时间量。测量在客户端部分花费的时间。做一些数学运算,您可以粗略估计网络时间和其他开销。

返回 1200 条记录,我预计网络带宽是主要问题之一;您也许可以调查不同的序列化引擎(具有相同的输出类型)是否有帮助,或者添加压缩(gzip / deflate)支持是否有益(意味着:减少带宽比增加所需的 CPU 更重要)。

如果您调用 REST 服务 300 次,延迟可能很重要;也许您可以稍微并行化,或者进行更少的大调用而不是大量的小调用。

您可以批处理 SQL 代码,因此您只需访问数据库几次(每次都重复调用 SP)——这是完全可能的;只需使用EXEC等(仍在使用参数化)。

您可以查看如何将数据从 ADO.NET 获取到 REST 层。您提到了 IBATIS,但是您是否检查过这与“dapper”相比是否快/慢?

最后,可以研究 SP 性能本身;索引或只是重新构建 SP 的 SQL 可能会有所帮助。

于 2012-09-28T12:40:37.500 回答
0

在不了解太多细节的情况下,该架构似乎存在缺陷。一方面,在使用单个 SP 执行检索 360,000 条记录所需的 6 秒内锁定表被认为是不合理的,但返回通过多个 SP 执行检索的可能不一致的 360,000 条记录集是可以的。这让我想知道您到底想实现什么,以及是否有更好的方法来设计客户端和服务器之间的集成。

例如,如果客户端正在检索自上次请求以来创建的一组记录,那么分页的 ATOM 提要可能更合适。

无论您在做什么,360,000 条记录是在服务器和客户端之间移动的大量数据,我们应该查看该数据传输的架构和目的,以确保当前方法是合适的。

于 2012-09-30T13:17:04.847 回答