是什么让我们的网站在生产中“旋转”？

Question

我们刚刚将一个网站部署到生产中。它在我的机器上运行（通过Visual Studio 2015运行）和测试。但是，用户在白天的某个时间点报告它“旋转”（Chrome浏览器标签中的圆圈继续表示它“正在工作”）并且他们无法做任何事情。我不能复制这个。我怀疑这是因为他们一次有5个以上的用户。回收应用程序池可以解决问题。我如何判断发生了什么以及如何解决？

我们有一个使用Telerik Kendo控件和Telerik Open Access连接到SQL Express数据库的asp.net MVC站点。该站点在客户端站点托管Windows Server 2012R2，并且数据库位于同一服务器上（客户端的决定，不是我的;不能更改）。它在IIS 8.5版中配置。我试图将IIS设置与我们的测试环境相匹配。当“旋转”发生时，没有任何押韵或理由;一定数量的用户或一天中的某个时间不会发生这种情况。我们的IT人员已经将应用程序池设置为在他们开始工作之前的清晨进行回收。我的老板认为应用程序池正在“填满”。有没有办法增加应用程序池的大小（甚至不确定这是否是正确的术语）？

我很欣赏有关如何找出问题以及如何解决问题的任何建议。谢谢！

Answer 1

我的猜测是，还有很多不同的事情发生。

首先，SQL Express无意运行生产网站。它不包括默认情况下发生的许多优化，也可以使用完整的SQL Server实例启用/配置。

其次，SQL Server和IIS都是资源占用者。在做他们所做的事情时，他们会消耗大量的RAM和CPU周期。建议他们应该是在他们安装的任何服务器上运行的唯一应用程序，这意味着它们应该位于两个单独的服务器上。否则，他们将不断争夺系统资源。

第三，App Pool会在一段时间后默认回收，并且可以在一天中因任何其他原因自行回收。发生这种情况时，必须进行一定数量的应用程序重新初始化，这可能需要一段时间才能提供请求。这可以通过在部署期间预编译Web应用程序来最小化。

第四，App Pool实际上是一个抽象的概念。它代表一个或多个为您的网站提供服务的流程。默认情况下，每个进程都有一个1000的线程池，通常在Web服务器术语中称为＆＃34; max requests＆＃34;因为1个线程通常等于一个请求。从理论上讲，此数字越大，在请求必须排队之前，您可以同时提供更多的请求。但是，每个线程都有开销，因此您可能很容易变得资源受限或实际上通过将其提高得太高而降低性能。请记住，CPU可以处理多少个同时操作是固定实体。即使你有足够的RAM来处理一些荒谬的线程，如果他们排队等待CPU时间，那么你就没有任何好处。通常，最好是多进程而不是增加线程池，因为每个进程可以使用CPU的单独核心。这是我在App Pool上启用Web工作人员的方法。每个worker对应一个单独的进程和另一个1000个线程的池。但是，您不应该拥有比CPU核心更多的工作人员，因为每个核心一次只能处理一个进程的操作。另外，请记住，每个流程基本上都是您自己的小版本网站。就像您需要在不同网站之间共享会话数据之类的内容一样，您还需要以类似的方式处理您的Web工作者。换句话说，您应该在web.config中设置机器密钥，并使用分散存储来处理会话数据和缓存等事务。如果您在proc会话或MemoryCache之类的东西中使用，那么所有这些都将仅限于一个工作进程。

第五，它可归结为普遍的低效率。即使您的数据库速度较慢，如果您可以通过在可能的情况下更有效地查询/缓存结果来减少需要处理的查询量，您仍然可以通过。使用输出缓存等功能可以减少Web服务器的负载。查找站点中执行速度较慢的站点区域，或者您知道执行复杂任务的区域，并通过重构代码，组合查询，明智的缓存等来找到优化这些区域的方法。

Answer 2

检查您网站服务器的日志文件。

查找导致服务器响应缓慢的请求。确定用户在白天＆＃34;旋转＆＃34; ＆＃39;的某个时刻报告的大致时间，这是Web服务器开始慢慢响应的时​​间浏览器请求。

您的网络服务器的缓慢问题可能是在处理了一个或多个处理不当的请求后才开始的。

要查找您的网站放置其日志文件的位置，请转到IIS并打开“记录”图标。

在那里定义了保存日志文件的目录路径以及生成新日志文件的频率。 （这些图像来自IIS 7.5。）