C# 减少到服务器/数据库的往返

在编写ASP.NET页面时，您会发现哪些迹象表明您的页面与数据库或服务器的往返次数过多

---

（这是一个一般性的问题，但我说的是ASP.NET，因为我的大部分代码都是在web端编写的）。

多少钱算是太多了？100万欧元的问题！轮廓然后是个人资料。如果你的应用程序大部分时间都在访问数据，那么你就有问题了（应该查看sql跟踪）。如果它花费了大部分时间来绘制UI，那么（假设您的视图没有进行数据访问），您可能应该首先查看其他地方…

往返与延迟的关系比移动的数据总量的关系更大，因此为它们进行优化确实很有意义。通常的方法是使用执行多个步骤的存储过程，甚至可能返回多个结果集。

我知道这听起来可能是重复的，但客户机-服务器往返取决于连接任意一侧有多少程序逻辑

首先要检查的是验证：您必须始终在服务器端验证和清理您的输入，但这并不意味着您不能在客户端也这样做，从而减少只用于检查输入的往返

第二：在客户端，您可以做些什么来减少服务器端过载？您可以在客户端检查或进行计算。还有一种AJAX，可以用来只加载正在更改的页面的一部分

第三：你能把工作委托给另一台服务器吗？如果您的服务器负载过大，为什么不使用web服务，或者干脆将逻辑的某些方面委托给另一台服务器呢

正如马克所写：“怎么会太多？”？这取决于你和你的预算

在编写ASP.NET页面时，有哪些标志 您是否查找您的页面是否为空 往返于某个地点的次数过多 数据库还是服务器

当然，这一切都取决于你的个人资料。然而，这里有一些指标，它们并不意味着有问题，但往往会表明

• 页面在本地渲染需要很长时间
  • 阅读这个问题：，尤其是
• 要呈现页面，您需要30多次往返。我从帽子里拿出了这个数字，但假设一次往返大约需要3.5毫秒，那么30次往返将超过100毫秒的指导原则（在任何其他类型的处理之前）

• 呈现页面时涉及的所有查询都经过了大量优化，执行时间不会超过一两毫秒。没有任何操作需要在每次呈现页面时执行大量CPU周期

• 数据访问被抽象出来，而不是以任何方式缓存。例如，如果GetCustomer将调用DAL，而DAL又发出一个查询，并且您的页面请求在批处理中检索不到的100个Customer对象，那么您可能会遇到麻烦

---

我要做的是查看ASP性能计数器和SQL性能计数器。为了获得准确的测量结果，您必须确保SQL Server上没有随机干扰活动（即导入与网站无关的运行批）

我看到的相关计数器是：

• ：这准确指示服务器接收的Transact-SQL批处理的数量。在大多数情况下，它可以与从网站到SQL的往返次数1:1相等
• ：此计数器是每个数据库的实例，因此我可以快速查看哪个数据库中存在“活动”。通过这种方式，我可以关联网站数据往返（即我的应用程序逻辑请求，转到应用程序数据库）和ASP会话状态和用户内容（转到ASP会话数据库或tempdb）
• ：这与上面的计数器（每秒事务数）相关，因此我可以了解站点的读写比率
• ：使用此计数器，我可以获得站点每秒看到的请求数。与每秒SQL批处理请求数相关，它很好地指示了每个请求的平均往返次数

接下来要衡量的事情通常是试图了解在请求中花费的时间在哪里。在我自己的项目中，我使用了大量的数据，因此很容易测量。但我并不总是那么幸运，只清理我自己的烂摊子。。。对我来说，评测通常不是一个选项，因为我大多数时候都会对无法检测的实时生产系统进行故障排除

我的方法是首先尝试整理SQL方面的内容，因为在SQL中很容易找到执行时间的相关统计信息：SQL保留了一个很好的聚合统计信息，可以随时查看。我还可以使用分析器实时测量执行持续时间。通过对收集到的数据进行一些分析，了解访问次数最多的页面的正常请求模式，您可以很好地估计每个web请求在SQL中花费的总时间。如果这段时间加起来几乎是一个请求提供页面所需的所有时间，那么您就有了答案

为了回答最初的问题标题：为了减少往返次数，你会提出更少的请求。认真地首先，缓存适合缓存的内容是显而易见的。其次，可以降低复杂性：不要在每个页面上显示不必要的数据，可以在不受影响的情况下缓存和显示过时的数据，可以在辅助导航面板上隐藏详细信息

如果您觉得问题在于往返次数本身，而不是请求数量（即，在一次往返中批量处理多个请求会给您带来巨大的好处），那么您应该以某种方式衡量往返开销是什么在扼杀您。对于正常网络连接上的连接池，这通常不是最重要的因素

最后，你应该看看是否所有可以在集合中完成的事情都是在集合中完成的。如果你有一个半脑的ORM可以从ID键集中一次检索一个对象，那就把它扔掉。

a web s