最近在领导的要求下做了一下项目的优化，总结如下：
1. 使用存储过程， （如果在程序里用exec 存储过程 参数，这样执行似乎并没有快多少）
在数据库里是预编译的，也不需要在字符串传输上花费大量时间。 防sql注入攻击。
2. 尽量优化数据库语句，使逻辑尽量简单。
@ 还有就是在使用函数时 charindex >like > padindex 效率依次递减。
@查询字段是否包含在以，分隔的字段串时，最好不要用in 速度非常慢。 还有好多，可以总结的，这里就不再描述了。
3. EnableViewState(页面的视图状态)。如果无特殊要求设置为false。
使用ViewState ，每个对象都必须先序列化到 ViewState 中，然后再通过回传进行反序列化，因此使用 ViewState是没有代价的。尽量减少使用对象，
如果可能，尽量减少放入 ViewState 中的对象的数目。下面情况基本上可以禁用viewstate：
（1）页面控件 （.ascx）
（2）页面不回传给自身。
（3）无需对控件的事件处理。
（4）控件没有动态的或数据绑定的属性值（或对于每个postpack都在代码中处理）
单个页面或每个页面都禁用 ViewState，如下所示：
单个页面：<%@ Page EnableViewState="False" %>
每个页面：在 web.config 中 <Pages EnableViewState="false" />
EnableSessionState保持默认值即可（如果页面用到sessionstate它才会占用资源）。
EnableViewStateMac如果无安全上的特殊要求，保持默认值。
4. Pagelayout.页面布局模型。建议使用Flowlayout(元素不带绝对定位属性添加).Gridlayout(绝对定位属性)由于采用绝对定位，将会比Flowlayout生产更多的 代码，主要是控件的定位信息。 radiobuttonlist 和 checkboxlist等
5. 项目发布的时候切记解除页面的Debug状态
6. 尽量选择html控件。能在客户端实现的功能就在客户端实现(熟练掌握javascript)，减少服务器的压力。
数据控件选择顺序：Repeater、DataList、 DataGrid
7. 在建立数据库连接后只有在真正需要操作时才打开连接，使用完毕后马上关闭，从而尽量减少数据库连接打开的时间，避免出现超出连接限制的情况
8. 字符串操作性能优化
使用值类型的ToString方法
在连接字符串时，经常使用"+"号直接将数字添加到字符串中。这种方法虽然简单，也可以得到正确结果，但是由于涉及到不同的数据类型，数字需要通过装箱 操 。作转化为引用类型才可以添加到字符串中。但是装箱操作对性能影响较大，因为在进行这类处理时，将在托管堆中分配一个新的对象，原有的值复制
到新创建的对象中。使用值类型的ToString方法可以避免装箱操作，从而提高应用程序性能。
运用StringBuilder类
String类对象是不可改变的，对于String对象的重新赋值在本质上是重新创建了一个String对象并将新值赋予该对象，其方法ToString对性能的提高并非
很显著。在处理字符串时，最好使用StringBuilder类，其.NET 命名空间是System.Text。该类并非创建新的对象，而是通过Append，Remove，Insert
等方法直接对字符串进行操作，通过 ToString方法返回操作结果。
9. 只要可能就缓存数据或页输出
ASP.NET 提供了一些简单的机制，它们会在不需要为每个页请求动态计算页输出或数据时缓存这些页输出或数据。另外，通过设计要进行缓存的页和数据请
求 (特别是在站点中预期将有较大通讯量的区域)，可以优化这些页的性能。与 .NET Framework 的任何 Web 窗体功能相比，适当地使用缓存可以更好的
提高站点的性能，有时这种提高是超数量级的。使用 ASP.NET 缓存机制有两点需要注意。首先，不要缓存太多项。缓存每个项均有开销，特别是在内存使
用方面。不要缓存容易重新计算和很少使用的项。其次，给缓存的项分配的有效期不要太短。很快到期的项会导致缓存中不必要的周转，并且经常导致更多的
代码清除和垃圾回收工作。若关心此问题，请监视与 ASP.NET Applications 性能对象关联的 Cache Total Turnover Rate 性能计数器。高周转率可能说
明存在问题，特别是当项在到期前被移除时。这也称作内存压力。
10. 使用 HttpServerUtility.Transfer 方法在同一应用程序的页面间重定向
采用 Server.Transfer 语法，在页面中使用该方法可避免不必要的客户端重定向。但要根据情况区分response.redirect .response.execute的使用方
法。区别对待。
11. 适当地使用公共语言运行库的垃圾回收器和自动内存管理
小心不要给每个请求分配过多内存，因为这样垃圾回收器将必须更频繁地进行更多的工作。另外，不要让不必要的指针指向对象，因为它们将使对象保持活动状 态，并且应尽量避免含 Finalize 方法的对象，因为它们在后面会导致更多的工作。特别是在 Finalize 调用中永远不要释放资源，因为资源在被垃圾回收器回收
之前可能一直消耗着内存。最后这个问题经常会对 Web 服务器环境的性能造成毁灭性的打击，因为在等待 Finalize 运行时，很容易耗尽某个特定的资源。
12. 不要依赖代码中的异常
因为异常大大地降低性能，所以您不应该将它们用作控制正常程序流程的方式。如果有可能检测到代码中可能导致异常的状态，请执行这种操作。不要在处理该 状态之前捕获异常本身。常见的方案包括：检查 null，分配给将分析为数字值的 String 一个值，或在应用数学运算前检查特定值。下面的示例演示可能
导致异常的代码以及测试是否存在某种状态的代码。
13.使用 HttpResponse.Write 方法进行字符串串联
该方法提供非常有效的缓冲和连接服务。但是，如果您正在执行广泛的连接，请使用多个 Response.Write 调用。
下面示例中显示的技术比用对 Response.Write 方法的单个调用连接字符串更快。
Response.Write("atest");
Response.Write(strString);
Response.Write("boxbig");
14.除非有特殊的原因要关闭缓冲，否则使其保持打开
禁用 Web 窗体页的缓冲会导致大量的性能开销。
15.避免到服务器的不必要的往返过程
使用 Page.IsPostBack 避免对往返过程执行不必要的处理
虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。通常，
只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。
16.ASP.NET应用程序性能测试
在对ASP.NET应用程序进行性能测试之前，应确保应用程序没有错误，而且功能正确。具体的性能测试可以采用以下工具进行：Web Application
Strees Tool (WAS)是Microsoft发布的一个免费测试工具。它可以模拟成百上千个用户同时对web应用程序进行访问请求，在服务器上形成流量负载，
从而达到测试的目的，可以生成平均TTFB、平均TTLB等性能汇总报告。 Application Center Test (ACT) 是一个测试工具，附带于Visual Studio.NET的
企业版中，是Microsoft正式支持的web应用程序测试工具。它能够直观地生成图表结果，功能比WAS多，但不具备多个客户机同时测试的能力。服务器操作
系统"管理工具"中的"性能"计数器，可以对服务器进行监测以了解应用程序性能。微软还是出了IIS日志查看工具 LogParserLizardSetup.msi ,
LogParser.msi 两者配合使用。可查看每一个页 面加载调用执行的时间。
17. 压缩js，js在页面中调用的大小写要保持一致，免得缓存了不同的文件，页面的js可以的话，写成单位的文件进行调用 。图片少用jpeg，使用gzip 对网页进行 压缩. 加快页面展示速度。
18. 把调用js，尽量写在页面底部， 还有viewstate 状态也可以重写到页面低部， 也可以把viewstate进行压缩。
条件是viewstate必要要用的情况之下。
适当使用一些优化技巧，有助于程序运行速度，软硬件合适配置，对于一个开发者来说也是一项深远的工程。