所以我正在解决遗留应用程序上的一些性能问题，并且我发现了一个非常具体的问题（可能还有其他问题）。
本质上，应用程序使用对象关系映射器来获取数据，但它以非常低效/不正确的方式这样做。实际上，它正在执行一系列实体图提取以填充UI中的数据网格，并且在数据绑定网格（它是ASP.Net Webforms）时，它正在执行额外的提取，这会导致其他提取等。
这样做的净效果是正在执行许多微小的查询。使用SQL事件探查器显示某个页面执行超过10,000个查询（填充单个网格。没有查询需要10毫秒才能完成，并且大多数在Profiler中注册为0毫秒。每个查询将使用并释放一个连接，并且系列查询将是单线程的（每个http请求）。
我对ORM非常熟悉，并确切知道如何解决问题。
我的问题是：在应用程序中执行许多小查询的确切影响是什么？它以何种方式强调系统的不同组成部分？
例如，对网络服务器的CPU和内存有什么影响？它会淹没连接池并导致阻塞吗？对数据库服务器的内存，CPU和I / O会有什么影响？
我正在寻找相对一般的答案，主要是因为我想开始监控可能受影响最大的区域（我需要测量=＆gt; fix =＆gt;重新测量）。在峰值时同时使用该系统可能会有大约100-200个用户。
答案 0 :(得分：0)
它将取决于数据库，但通常每个查询都有一个解析阶段。如果查询使用了绑定变量，它可能会被缓存。如果没有，你就会受到解析，这通常意味着对资源的短暂锁定。即坏的。在Oracle中，CPU和阻塞在解析时比执行更加优先。 SQL Server不那么严重，但在执行时却更糟糕。显然，通过网络做任何10K的任何事情都将是一个糟糕的解决方案，尤其是x 200用户。卷我确定没问题，但这个频率真的会突出comms延迟和类似的东西的所有开销。连接池通常有数百个，而不是数万个，现在你已经创建，排队，管理，销毁，垃圾收集等数十万个对象。
但我相信你已经深知这一切了。抛弃该部分的ORM并编写存储过程以执行单个查询以返回结果集。然后把它放在网格上。