asp.net WCF 服务缓慢...禁用 asp.net 应用程序回收有帮助吗？
我有一个 WCF 服务，需要一定的响应时间（不到 1 分钟）。
我的问题是，服务经常需要很长时间才能响应（有时超过 2 分钟），最常见的是在早上。
我认为这是因为应用程序已回收并且第一次运行必须重新编译。
还有其他原因可能会发生这种情况吗？
是否可以关闭应用程序回收？ 如果是的话，会导致任何副作用或不稳定吗？ 我假设 ASP.NET 应用程序设置为回收肯定有一个原因。
是否还可以采取其他措施来提高首次运行性能？
I have a WCF service that requires a certain response time (under 1 minute).
My problem is that every so often, most often in the mornings the service takes a long time to respond (sometimes over 2 minutes).
I'm thinking this is because the app has recycled and the first run must recompile.
Are there other reasons this might happen?
Is it possible to turn off app recycling? And if it is, will that cause any side effects or instability? I'm assuming there must be a reason why asp.net apps are set to recycle.
Is there anything else that can be done to improve that first run performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，您可以阻止 AppPool 回收。 另一种选择是创建一个保持活动的作业来持续 ping 服务以防止工作进程休眠。
Yes you can prevent the AppPool from recycling. Another option would be to create a keep-alive job to continually ping the service to keep the worker process from sleeping.
基本上，以下规则规定了应用程序何时回收或卸载：
使用保持活动状态来 ping 服务可以解决 2，然后您只需处理 1。
根据您的 IIS 版本，配置此问题的方法略有不同。
空闲超时我认为通常默认为“infinte”，但可以通过 processModel 元素进行配置配置文件的（idleTimeout 属性）。
至于首次运行性能 - 如果不查看您的应用程序，很难说您是否运行过类似 DotTrace 或者另一个分析器？
您是否在第一次加载时进行了大量的密集查找和缓存数据？ 这些可以推迟吗？
Basically the following rules dictate when an application is recycled or unloaded:
Using a keep-alive to ping the service would solve 2, and then you'd just have to deal with 1.
Depending on your version of IIS, there are slightly different ways to configure this.
The idle time out I think would normally default to "infinte", but can be configured through the processModel element (idleTimeout attribute) of your configuration files.
As to first run performance - without looking at your app it's hard to say, have you run something like DotTrace or another profiler over it?
Are you doing a lot of intensive lookups and caching data in that first load? Can these be deferred?
性能问题可能是由您没有首先排除的任何原因引起的。 既然你没有排除任何可能性，那么它可能是由任何事情引起的。
Performance problems can be caused by anything you haven't ruled out first. Since you haven't ruled anything out, it could be cauased by anything at all.
也许是一个愚蠢的想法：您可以安排一个控制台应用程序在早上 5:30 启动您的服务，这样该请求将需要很长时间才能运行，而在此之后进入的常规用户不会遇到这个问题？
当然 - 它没有解决根本原因，但就目前而言，它可能是一个有用的解决方法 - 不是吗？
马克
Maybe a silly idea : could you schedule a console app to hit your service at e.g. 5:30am in the morning, so that this request would take a long time to run, and your regular users coming in after that won't have that problem?
Sure - it's not dealing with the root cause, but for the time being, it might be a useful workaround - no?
Marc