在编写ASP.NET页面时，您认为您的页面向数据库或服务器进行了太多的往返是什么迹象？
（这是一个普遍的问题，但我说ASP.NET，因为我的大部分编码都是在网络方面）。
答案 0 :(得分：4)
多少钱？ 100万欧元的问题！轮廓。然后简介。如果您的应用程序花费大部分时间进行数据访问，则会出现问题（并且应该查看sql跟踪）。如果它花费大部分时间绘制UI，那么（假设你的视图没有进行数据访问）你应该首先看看其他地方......
答案 1 :(得分：1)
往返行程与延迟相关，而不是移动的数据总量，因此优化它们确实有意义。通常的方法是使用执行多个步骤的存储过程，甚至可能返回多个结果集。
答案 2 :(得分：1)
我所做的是查看ASP性能计数器和SQL性能计数器。要获得准确的测量结果，您必须确保SQL Server上没有随机噪声活动（即，与网站无关的导入批次）。
我看到的相关柜台是：
接下来要衡量的是通常试图了解在请求中花费的时间。在我自己的项目中，我大量使用performance counters I publish myself因此很容易衡量。但是我并不总是那么幸运，只能清理我自己的烂摊子......对我来说，性能分析通常不是一个选择，因为我大多数情况下对我无法检测的现场制作系统进行故障排除。
我的方法是首先尝试解决SQL方面的事情，因为很容易在SQL中找到执行时间的相关统计信息：SQL保留了一个很好的聚合统计信息，可以在sys.dm_exec_query_stats中查看。我也可以使用Profiler实时测量执行持续时间。通过对收集到的这些数字的一些分析，了解访问量最大的页面的正常请求模式，您可以非常好地估计每个Web请求在SQL中花费的总时间。如果这个时间几乎总是需要一个请求来提供页面，那么你就得到了答案。
回答原始问题标题：减少往返次数，减少请求次数。认真。首先，缓存我认为适合缓存的内容是显而易见的。其次，您可以降低复杂性：不要在每个页面上显示不必要的数据，当您可以使用它时缓存和显示陈旧数据，您可以隐藏辅助导航面板上的详细信息。
如果您认为问题是往返次数本身而不是请求数量（即，您将通过在一次往返中批量处理多个请求而获益极大），那么您应该以某种方式衡量往返开销正在扼杀你。通过普通网络连接上的连接池，这通常不是最重要的因素。
最后你应该看看是否可以在集合中完成所有可以完成的事情。如果你有一些半脑的ORM，它可以从ID键集中一次检索一个对象，那就去除它。
答案 3 :(得分：0)
我知道这可能听起来很反复，但客户端服务器往返取决于连接任何一侧有多少程序逻辑。
要检查的第一件事是验证：您必须始终在服务器端验证和清理您的输入，但这并不意味着您也无法在客户端执行此操作，这也减少了仅用于检查输入的往返
第二：您在客户端可以做些什么来减少服务器端过载？您可以在客户端检查或制作计算。还有一些AJAX可用于仅加载正在更改的页面的一部分。
第三：你可以将工作委托给另一台服务器吗？如果您的服务器负载过重，为什么不使用Web服务或只是将逻辑的某一端委托给另一台服务器？
正如马克写道：¿怎么样太多了？这取决于您和您的预算。
答案 4 :(得分：0)
编写ASP.NET页面时，有什么迹象 你在找你的页面吗？ 做太多往返了 数据库或服务器？
当然这一切都取决于你必须描述。但是，这里有一些指标，它们并不意味着存在问题，但往往会表明
Page需要很长时间才能在本地呈现。
要渲染页面，您需要超过30次往返。我把这个数字从我的帽子中取出来，但假设往返行程需要大约3.5毫秒，那么30次往返将使你超过100毫秒的准则（在任何其他类型的处理之前）。
渲染页面所涉及的所有查询都经过了大量优化，执行时间不会超过一毫秒或两秒。每次渲染页面时都不需要执行大量CPU周期的操作。
数据访问是抽象的，不以任何方式缓存。例如，如果GetCustomer将调用DAL，而DAL又发出查询，并且您的页面要求批量检索的100个Customer对象，则可能遇到麻烦。