MVC UnitOfWork EntityFramework架构,网站速度慢的原因总结!
最近参考使用了郭明峰的一套架构来做新的项目架构,这套架构看起来还是不错的,先向小郭同学的分享精神致敬!
(郭同学的项目文档:http://www.cnblogs.com/guomingfeng/archive/2013/05/19/mvc-overall-design.html)
项目开发上线后,傻眼了,貌似没有几个人访问的新项目,速度一直慢的跟牛一样,真心没法交差啊。上面发下话了,解决不了就可以走人了。压力可想而知。
接下来就是苦逼的找原因了。
症状:1、内存占用高,8g的内存很快就能吃完
2、网站相应速度慢,firebug检测每次都是在等待
根据这些症状,感觉是内存泄露了,于是memory profiler。。。什么性能分析工具都用上了,怎奈水平有限,不会使用这些高级玩意,一番折腾下来,就剩下无奈。
但总不能放弃,对比之前做的mvc项目,就是多了entityframework、MEF这两样,看样子也就这两块的原因了,EF的嫌疑最大,而且首次使用,并不了解。于是,接下来又是一段苦逼的研究;功夫不负有心人,根据目前研究的结果及上线的效果来看,基本上找到了问题的所在。总结下,与诸位分享,高手忽略。
问题原因:1、很多数据查询一次性读入到内存中,导致内存增加。
2、上下文对读入到内存中的数据对象会进行跟踪,导致内存不断攀升,疑似内存泄露
解决办法:1、深入学习EF,监控每一步生成的sql语句,防止无用数据的调取
2、网站大部分的数据在读取的时候是不需要进行上下文跟踪的,一定要禁止跟踪,否则内存就会爆了!代码如下:
/// <summary> /// 获取当前实体的查询数据集(通过读上下文进行读取,只读专用,返回的实体数据不会被上下文跟踪) /// </summary> public virtual IQueryable<TEntity> ReadEntities { get { return WriteContext.Set<TEntity>().AsNoTracking(); } } /// <summary> /// 获取当前实体的查询数据集(通过写上下文进行读取,修改专用,返回的实体数据会被上下文进行跟踪) /// </summary> public virtual IQueryable<TEntity> WriteEntities { get { return WriteContext.Set<TEntity>(); } }
说明:我在仓储模式中,对读取实体集合进行了修改,ReadEntities表示不需要进行跟踪的,加上AsNoTracking方法;WriteEntities表示是需要跟踪的,用于修改实体信息使用。这样以来,所有的症状全部消失了。
当然,也许有更好的优化方法,至少目前本人发现了这些问题所在,而且微软的白皮书中确实也讲的了EF的性能注意事项,怎奈仓促开发,对EF毫不了解,罪过罪过!大家引以为鉴!
另外,还遇到一个问题,不知道是否是DBcontext线程冲突问题,大家帮分析下,谢谢:
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。