我们有一个站点位于地球的一侧，而另一侧则是客户。
它的asp.net和表单上的复杂业务规则的加载。因此，在许多情况下，用户会根据业务规则采取某些操作并返回网站以更改表单。
所以现在客户抱怨网站滞后。
对于我们来说，滞后几乎不可察觉，所以我认为这里几乎是纯粹的地理距离。
提高绩效有哪些选择......
a）将镜像数据中心放在客户所在国家附近 b）重写整个应用程序，尝试完全在客户端脚本中实现业务规则（可能不可行）
除此之外，任何人都可以提出任何可能提升绩效的提示或技巧。
我们已经在db和web服务器之间进行了大量缓存，但在这种情况下，这不是问题，因为无论如何它们并排......
问题是客户端和服务器之间的30,000英里往返......
（我注意到反过来也很慢 - 当我在客户国家使用网站时，它们似乎总是很慢......）
答案 0 :(得分：6)
我也有这个问题。我的一些客户在新西兰，我在英国。除非你计算深空探测器，否则这是你可以获得的那么大的往返。
从这里开始：
http://www.aspnet101.com/2010/03/50-tips-to-boost-asp-net-performance-part-i/ http://www.aspnet101.com/2010/04/50-tips-to-boost-asp-net-performance-part-ii/
其中许多都是服务器提示，但这些页面中的细节提示可能会对您有所帮助：
此外，在Firefox中，安装 YSlow Add-on 。这将为您提供有关如何改进特定页面的提示
如果所有这些都不够，您可以负担得起时间和投资，将应用程序转换为 ASP.NET MVC 将使您的页面在带宽上更轻松。您可以逐步执行此操作，首先更改问题最多的页面，并随着时间的推移更换您的网站，而不会影响您的用户。但只有在用尽了你的问题的答案后发布的许多想法之后才这样做。
如果要进行重写，另一个选择是使用 Silverlight 考虑使用富Internet应用程序。这样，您可以在客户端浏览器中执行适当的C＃业务规则，并仅返回服务器以获取小数据包。
最明显的短期解决方案是在您的客户所在的国家购买一些托管空间，但如果您的祖国有其他客户，则必须考虑数据库同步。< / p>
答案 1 :(得分：1)
第一步是您可能希望从访问您网站的客户端获取一些性能信息。类似于Firebug（在Firefox中），显示页面上每个项目的每个请求所花费的时间。你可能会惊讶于瓶颈实际上是什么。也许只为图像添加CDN（内容传送网络）就足够了。
如果您的网站有任何外部引用或在客户端上运行的跟踪（网络趋势等），甚至可能是瓶颈，那么它可能与您的网站无关
答案 2 :(得分：1)
这可能听起来很明显，但在这里：我尝试将客户端和服务器之间的信息交换限制在绝对最小值，可能是通过在第一次调用时尽可能多地缓存信息，并使用javascript。
例如：如果您的应用在用户按下“给我一个新的空白表单”时轮询服务器，您可以在第一次调用时发送“隐藏”（即在javascript字符串上）空白表单，并且当用户按下按钮时，它用javascript替换可见的。没有服务器轮询=感知响应能力的大幅提升。
另一个例子是ajax服务，每次用户更改一个字段时都会呈现一个复杂的表单。低效（但通常更容易实现）的方法是让服务器以html“发送”完整的表单。一种更有效的方法是让服务器返回一条短消息（可能用json编码），让客户端再次使用javascript从消息中构建表单。这里的诀窍是，在某些情况下，您可以在收到消息之前开始呈现表单，因此“感知响应性”也会更好。
最后，看看你是否可以缓存;如果用户要求您提供已有的信息，请不要再次拉取服务器。例如，在javascript数组中保存页面的“当前状态”，因此如果用户按下“后退”或“前进”，您可以从那里恢复，而不是轮询服务器。
答案 3 :(得分：1)
你正在处理一个“长脂管”，这意味着带宽足够（它仍然可以达到x KB / s），但滞后增加了。在减小请求的大小之前，我会先考虑减少请求的数量和频率。
您不必在Javascript中重新实现100％的业务规则，但确实开始简化验证。恕我直言，这有可能为你带来最好的收获。
但是，当然，不要相信我的话，调查瓶颈发生的地方 - 即响应时间或转移时间。大多数现代浏览器的开发人员插件最近可以做到这一点。
答案 4 :(得分：0)
您应该注意的一件事是页面的ViewState有多大。对于每个回发，它将发送视图状态。如果它很大并且互联网线路“慢”，那么你将会陷入滞后。
修复此问题的方法是仔细检查代码并关闭不需要它的控件的viewstate，compress the viewstate然后再将其发送到客户端，使回发更小，cache the viewstate在服务器上并使用guid或类似方法在aspx文件中替换它，使回发更小。
当然，请确保您为整个网站启用了压缩（gzip），以便首先压缩您发送的内容。
还要确保将缓存标头添加到所有静态内容，以便客户端缓存这些文件（js，css，images）。
使用Fiddler或类似的东西来监控您的应用程序来回传输的数据量。
答案 5 :(得分：0)
首先，感谢大家提供所有信息。
只是一些额外的背景。该站点使用我编写的动态表单生成引擎构建。
基本上我创建了一个系统，在db中描述表单布局并动态渲染。
这是一个非常有用的系统，它允许快速更改，也意味着我们的输出，包括屏幕，pdf和xml输出与这个描述同步，我称之为表格地图。例如，在所有渲染中自动显示添加新控件或重新排序表单 - form，pdf，xml和标准显示
然而，它确实引入了必须在每个请求上构建页面的开销，包括回发帖子我一直在和我公司的一位建筑师交谈，我们可能需要在全球范围内安装一些副本 - 不可能为一个欧洲数据中心的不同国家的人们运行全球系统。
有些形式是巨大的，客户不愿意看到感觉并将它们分成更小的部分 - 所以这也增加了开销。
我还没有尝试过的唯一一件事就是运行像gzip这样的东西来减少已经发送过的有效负载......