我遇到了一个我发现很难解决的问题。我有一个 MVC 应用程序，其中包含一个相当大量的视图。确切地说，它有大约 2200 个 TextBoxFor 控件。我在本地没有遇到任何异常，但是当我将应用程序部署到 IIS 服务器（版本 10）时，我遇到了 stackoverflow 异常。我相信这与这个大视图的渲染有关，但我不确定。我看过，我没有看到无限循环，因为我的这个视图的控制器方法只是一个“返回视图（模型实例）；” 而且我在视图中看不到任何可能导致任何无限循环的东西。我怀疑它只是被这么多正在呈现的 TextBoxFor 控件所重载。任何帮助表示赞赏。
问问题
104 次
1 回答
1
老实说，如果不能真正坐在服务器前，可能无法回答这个问题。但是，有几点值得注意：
这仅在生产中发生也就不足为奇了。在开发中，只有你。在生产中，100 或 100 名客户可能在同一时刻访问该网站。这就是为什么您应该在生产服务器上进行负载测试的原因。仅仅因为您的应用程序在本地运行良好并不意味着一旦您部署它就不会完全崩溃。
目前尚不清楚您是部署为 32 位还是 64 位，但如果由于某种原因您部署为 32 位，则每个进程的内存利用率有 4GB 的硬性限制，它实际上可能低于如果您没有配置 IIS 以允许它使用所有可寻址空间。另一方面，64 位应用程序的可寻址空间的唯一限制几乎是系统可用总 RAM 的限制（当然不包括专用于操作系统、本身和任何其他运行的 RAM应用程序。如果你有一个虚拟化服务器，我会尝试的第一件事就是简单地向它扔更多 RAM，看看异常是否消失。现在，这不一定是最好的问题的解决方案，因为应用程序仍然臃肿且效率低下，但它至少为您提供了一些喘息的空间。
单页上的 2200 个控件简直荒谬。其中每一个都会导致消耗一定数量的 RAM，并且可能是您遇到的问题。但是，即使您的服务器足够强大，可以同时发出 1000 个请求，这些请求都加载了 2200 个控件，生成的 HTML 文档也会非常大，并且可能会给客户端机器带来很大的压力来呈现。简而言之，您应该研究减少一次性收集的信息量的方法。我什至不确定谁会用 2200 个输入来填写表格。分部分收集数据或简单地将其分解为多个步骤。它不仅会减少服务器上的负载，还会减少客户端上的负载，并为用户提供更好的 UX 引导。
于 2017-10-02T17:32:51.617 回答