asp.net-mvc – 应用程序池回收导致非常长的响应时间

发布时间：2020-12-16 03:26:50 所属栏目：asp.Net 来源：网络整理

导读：我已经读过某个地方,当启用重叠时,应用程序池回收不应该对最终用户非常明显,但在我的情况下,响应时间至少比通常长10倍(取决于负载,来自常规的响应时间) 100毫秒长到5000毫秒).这也不是针对单个请求,而是在池回收之后的几个请求(我在测试时使用了~10个并发连

我已经读过某个地方,当启用重叠时,应用程序池回收不应该对最终用户非常明显,但在我的情况下,响应时间至少比通常长10倍(取决于负载,来自常规的响应时间) 100毫秒长到5000毫秒).这也不是针对单个请求,而是在池回收之后的几个请求(我在测试时使用了~10个并发连接).

所以问题是：

>在我看来,我不做任何事情,这需要很长时间才能启动应用程序 – 一般来说,那只是IoC容器和路由初始化,甚至我也会做一些事情 – 这就是重叠应该注意或不？
>在池回收期间是否破坏了sql连接池,这可能是响应时间长的原因吗？
>描述需要这么长时间的最佳方法是什么？也许可能有想法,从IIS / .NET方面可能需要这么长时间,以及如何避免这种想法.

解决方法

>重叠仅意味着旧工作进程将在新工作进程启动时继续运行.一旦新的启动,它就开始处理所有请求. “已启动”并不意味着初始化(可能包含在Application_Start中,应用程序中的任何静态构造函数,或任何一次,代理构建等有争议的任务)都已完成.这意味着新请求必须在这些进程完成时等待,即使“旧”工作进程可能仍然可以在短时间内使用.此外,如果您的应用程序使用任何类型的缓存,您的新缓存将是“冷”,这意味着在缓存预热之前需要一些额外的处理时间. >是 – 您的新应用程序将具有新的SQL连接池. >根据我的经验,在生产环境中,经过严格测试的代码和需要一致,高性能的应用程序,我选择完全禁用应用程序池回收.应用程序池回收是一种“功能”,用于抵制IIS不稳定的感觉,实际上通常真正不稳定的是它托管的应用程序.在我看来,这是一个允许人们部署不到稳定代码的拐杖.如果它导致您出现问题,请将其关闭,并确保您的应用程序没有任何内存泄漏等,这可能会导致长期应用程序不稳定.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!