问题  响应延迟问题

Raysefo

知名会员
已加入
2019年2月22日
留言内容
194
编程经验
10+
你好,

我有一个asp.net Web API。第一次或在1-2小时休息后致电我的服务时,响应时间会更长。但是在初始响应或没有中断后,我的服务响应很快。我该如何解决? IIS或实体框架中是否有任何设置?

最好的祝福。
 

羊皮

退休程序员
工作人员
已加入
2018年9月5日
留言内容
1,933
地点
英国
编程经验
10+
听起来好像有备份。这可能是很多事情。

这就是为什么我不喜欢EF,而只将云托管用于特定目的的原因。由于我之前建议您在各个线程中进行许多更改,因此您没有采纳任何建议,因此,为什么还要再次重申它……。

尝试调试,查看卡在哪里,并根据卡在哪里,在事件发生时开始阅读日志以查找错误以及相关问题,例如Web请求失败等。我们不太可能为imo提供帮助。
 

跳伞

工作人员
已加入
2019年4月6日
留言内容
2,536
地点
弗吉尼亚州切萨皮克
编程经验
10+
检查您的IIS设置。

IIS的默认设置是,如果某个应用程序空闲20分钟,则该应用程序池将关闭。因此,随之而来的下一个Web请求必须重新启动应用程序。大多数人会更改设置,以关闭空闲时间应用程序池关闭。

然后是长期运行的应用程序池的另一方面。还有一个默认的上限 29小时 重新启动之前。您需要将其更改为永久运行。或者,如果您的应用存在内存泄漏,则每隔几个小时重新启动一次。对于每隔几个小时重新启动的情况,您需要在服务器前安装一个负载平衡器,然后错开它们的重新启动时间,以使并非所有计算机都在同一时间重新启动。
 

羊皮

退休程序员
工作人员
已加入
2018年9月5日
留言内容
1,933
地点
英国
编程经验
10+
大多数人会更改设置,以关闭空闲时间应用程序池关闭。
我不建议您这样做,尽管它是一种选择,但它也是有目的的。但是加号+表示设置指针。

如果您的站点损坏了,那么您需要修复错误的代码,仅此而已。如果它崩溃了,请检查您的池的状态,如果它已停止,则需要开始挖掘其停止的原因。看到这个 知识库-Host-it Internet解决方案

还有一个默认的上限 29小时 重新启动之前。您需要将其更改为永久运行。

另外,尽管它是一个功能,但也不应该篡改它以使其运行 永远 。当您四处搜索并查看有关29小时限制的帖子时,您会发现这样做主要是出于以下几个原因之一,也是主要原因。永远不要相信应用程序能够在如此长的时间内可靠地运行而不会出现错误,因此添加了此功能是一种重置应用程序并释放该应用程序可能承受或引起接收者泄漏的方式。

我建议微风吹拂文档: 应用程序池回收的定期重启设置<periodicRestart> 在进行更改之前,先了解您的操作。还请注意这篇关于EF内存泄漏的帖子,以及我非常讨厌的网站中的建议: 使用实体框架时发生内存泄漏 许多人报告说EF占用大量内存,这是不允许您的应用运行的另一个原因 永远 without restarting.

这只是我可以在此映射器上派出的众多内存泄漏帖子之一 内存泄漏·问题#13048·aspnet / EntityFrameworkCore -但是像往常一样,您将无视我的帖子,继续进行下一个问题。而且,如果您关心您的应用程序,那么您的用户将做正确的事情,并使用一些不太复杂但更可靠的方法。那就是我的两分钱。
 
Last edited:

Raysefo

知名会员
已加入
2019年2月22日
留言内容
194
编程经验
10+
另一个论坛中的某人说:"据我所知,如果您使用的是EF 6.2,则可以使用模型缓存,该缓存在首次使用代码时会加载一个预先构建的edmx。相反,EF会在启动时生成它。这将使第一个查询更快。"

C#:
public class MyDbConfiguration : DbConfiguration
{
    public MyDbConfiguration() : base()
    {
        var path = Path.GetDirectoryName(this.GetType().Assembly.Location);
        SetModelStore(new DefaultDbModelStore(path));
    }
}
 

羊皮

退休程序员
工作人员
已加入
2018年9月5日
留言内容
1,933
地点
英国
编程经验
10+
您是我多年来使用各种这些代码论坛所经历过的最不可思议的人。您几乎是一个巨魔,但实际上却不是一个。除非我不特别在乎您的项目进行方式,否则这简直令人沮丧,因此我以后再也不会浪费时间,因为您以某种方式设法无视我自己和跳伞运动员向您提供的每条建议次。

每当您寻求帮助并收到可能导致问题的根源时,您都会回来向我们抛出无关的代码,并尝试转移到其他不太可能的原因,成为造成问题的实际原因。就像您没有阅读我帖子的哪一部分?如果有人建议我计划将其分发给成千上万个用户的应用程序中发生内存泄漏,那么我会立即跳船并使用另一个dapper / other等ORM。实际上,您已经忽略了我曾经告诉过您的有关EF引起的问题的所有内容,并且回顾您的主题,很明显,您除了EF之外什么都没有,而且从外观上看,也没有很多解决方案。我想如果您不在乎,我们为什么要这么做?

另一个论坛中的某人说:"据我所知,如果您使用的是EF 6.2,则可以使用模型缓存,该缓存在首次使用代码时会加载一个预先构建的edmx。相反,EF会在启动时生成它。这将使第一个查询更快。"
没看过的哈哈
 
最佳 底部