Temporary ASP.Net Files探究

了解.net平台的兄弟都知道,.net也是采用动态编译的
也就是说我们常说的build生成的dll只是中间代码
而在web第一次请求的时候才是真正意义上的编译生成二进制代码
这也就是为什么刚编译完第一次打开web页面的时候会比较慢的原因

好了,闲话少扯
今天一个兄弟问我,为什么他开发环境打开编译后的页面越来越慢
下面是我的解决方案:
1.关掉inetinfo.exe的进程
2.关掉aspnet_wp.exe
3.关掉打开的visual studio
4.清掉%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files文件夹下的所有文件。
%SystemRoot%指的是你的系统windows文件夹的路径,一般默认的是C:\WINDOWS\
整个清除过程可能会比较慢,具体时间和目录下文件夹大小有关。
清除完之后,第一次打开还会比较慢,但是以后编译后的打开会快一些。

下面是详细的解释
当我们第一次请求的时候,也就是正式编译的时候,dotnet会写一些临时文件在这个文件夹下。
这个本人验证过,在第一次请求的时候,去关注文件夹的变化。
对于部署在server已经上线的Web Application是不会存在这样的问题的。
而在我们的开发环境下,由于经常要build,经常第一次请求,所以时间久了,这个文件夹就会变得很大。
像我现在在做的项目,源文件和目标文件的大小有4G,那么,写到这个文件夹里的文件就有上百兆。
我们可以去关注下,在选择“附近到进程”操作之后加载的程序集,就是在这个路径下。

不知道有的兄弟,会不会想,要经常手动去清这些文件,岂不是很麻烦?
哈哈,想省事的兄弟,可以写个批处理程序来做这个操作。
这里,我想介绍另一种方法来提升速度。
我们都知道,在我们可以控制的存储单元中,内存的访问速度是最快的。
如果,我们可以把这些临时文件放到内存中,就会成倍地提高速度。

1.安装RamDisk
2.安装好后,设置Debug 输出的Temp 目录为内存盘的path, 不再使用原来预置的 Temporary ASP.NET Files,只需要通过修改 Web.Config 文件中的
  <compilcation debug=”true”> 一般情况是这样的
修改为   <compilcation debug=”true” tempDirectory=”R:\”>
保留原来属性,新加一个 tempDirectory 指定内存盘的path
实践检验,可以花费时间的差距可以到一个数量级。
扩展阅读:http://msdn.microsoft.com/en-us/library/ms366723.aspx

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值