ASP.NET中常用的26个优化性能方法(16
16. 适当地使用公共语言运行库的垃圾回收器和自动内存管理
小心不要给每个请求分配过多内存，因为这样垃圾回收器将必须更频繁地进行更多的工作。另外，不要让不必要的指针指向对象，因为它们将使对象保持活动状态，并且应尽量避免含 Finalize 方法的对象，因为它们在后面会导致更多的工作。特别是在 Finalize 调用中永远不要释放资源，因为资源在被垃圾回收器回收之前可能一直消耗着内存。最后这个问题经常会对 Web 服务器环境的性能造成毁灭性的打击，因为在等待 Finalize 运行时，很容易耗尽某个特定的资源。
17. 如果有大型 Web 应用程序，可考虑执行预批编译
每当发生对目录的第一次请求时都会执行批编译。如果目录中的页面没有被分析并编译，此功能会成批分析并编译目录中的所有页面，以便更好地利用磁盘和内存。如果这需要很长时间，则将快速分析并编译单个页面，以便请求能被处理。此功能带给 ASP.NET 性能上的好处，因为它将许多页面编译为单个程序集。从已加载的程序集访问一页比每页加载新的程序集要快。
批编译的缺点在于：如果服务器接收到许多对尚未编译的页面的请求，那么当 Web 服务器分析并编译它们时，性能可能较差。为解决这个问题，可以执行预批编译。为此，只需在应用程序激活之前向它请求一个页面，无论哪页均可。然后，当用户首次访问您的站点时，页面及其程序集将已被编译。
没有简单的机制可以知道批编译何时发生。需一直等到 CPU 空闲或者没有更多的编译器进程(例如 csc.exe(C# 编译器)或 vbc.exe(Visual Basic 编译器))启动。
还应尽量避免更改应用程序的 \bin 目录中的程序集。更改页面会导致重新分析和编译该页，而替换 \bin 目录中的程序集则会导致完全重新批编译该目录。
在包含许多页面的大规模站点上，更好的办法可能是根据计划替换页面或程序集的频繁程度来设计不同的目录结构。不常更改的页面可以存储在同一目录中并在特定的时间进行预批编译。经常更改的页面应在它们自己的目录中(每个目录最多几百页)以便快速编译。
Web 应用程序可以包含许多子目录。批编译发生在目录级，而不是应用程序级。
18. 不要依赖代码中的异常
因为异常大大地降低性能，所以您不应该将它们用作控制正常程序流程的方式。如果有可能检测到代码中可能导致异常的状态，请执行这种操作。不要在处理该状态之前捕获异常本身。常见的方案包括：检查 null，分配给将分析为数字值的
相关文档：
asp.net自定义错误处理页面方法一
1、添加Web.config， < system.web>< /system.web>中添加< customErrors mode="On"
defaultRedirect="ApplicationErroy.aspx" >< /customErrors>节点，
2、添加错误处理页面：ApplicationErroy.aspx调用下面的方法：
private void DealErroy() & ......
因为安全性问题，IE7禁用了image控件引用本地图片，为了这个问题郁闷了好几天，终于找到了解决方案，好东西要与大家分享，代码如下：
此段代码放于<head> ....</head>之间
<style type="text/css">#newPreview {
FILTER: progid:DXImageTransform.Microsoft.AlphaImageLoader(sizingMethod=scale)
} ......
public class t3 : System.Web.UI.Page
{
private string str;//字符
&n ......
ASP.NET中提供了两种缓存更新策略：
1.被动更新。缓存过期以后手动进行更新
2.主动更新。缓存过期以后在回调方法中更新
如果我们现在要缓存一个数据集：DataSet ds=getData();//getdata()是一个自定义方法，从数据库获取数据
A.插入永不过期的缓存：Cache.Insert("d ......
[ASP.NET]Log4Net全攻略
转自:http://blog.5d.cn/vip/icecream/200511/185284.html
很多开发者都想要一个非常强大的程序日志管理库，能够了解用户对应用程序的使用情况。当程序出现问题时，可以通过分析日志来了解问题之所在。
过去我们总是用一种很简单的方式来处理日志，即：使用一个日志文件，当程序有问题时� ......
