
	转至繁体中文版	\| 网站首页 \| 图文教程 \| 资源下载 \| 站长博客 \| 图片素材 \| 武汉seo \| 武汉网站优化 \|

也谈ASP.NET应用程序性能优化

作者：闵涛文章来源：闵涛的学习笔记点击数：4165 更新时间：2009/4/23 10:40:41

oft SQL Server程序集中启动SQL Enterprise Manager；
　(2)从Server Manager窗口中选择“Server”菜单选项；
　(3)在“Server”菜单中选择“Configurations”选项；
　(4)在“Server Configuration”对话框中选择”Configuration”标签，
　(5)选中“Memory”项目，在“Current”栏填入新值；
　(6)停止并重新启动SQLServer服务，使设置生效。
　

合理扩充虚拟内存、增大SQL Server可用内存
　当SQL Server系统确实需要扩大可用内存时，应在磁盘空间充足的情况下扩充供虚拟
内存，并相应增大 SQL Server可用内存。具体做法是，系统管理员首先扩充服务器的虚拟内存，然后再参考上表增大SQL Server可用内存，关键是要根据系统的负载情况综合决定是否扩充。

使用tempinRAM
　SQL Server使用tempdb临时数据库作为一些查询连接操作时排序或创建临时表的工作
空间。将tempdb创建在RAM中可以使系统操作性能有较大提高，而且因为tempdb在每次重启动服务器时都重建，这样即使有非正常的关闭也是较为安全的，例如停电故障。要将tempdb创建在RAM中，可以使用sp_configure进行设置，具体用法请参阅有关资料。
　由于tempdbinRAM使用的内存是由系统从内存体单独分配的，与SQL Server的内存选
项设置的可用内存池是分开的，使用tempdbin RAM将减少整个系统的可用内存，应根据SQL Server和服务器运行情况进行配置，否则就可能适得其反，影响系统性能。另外，适当增加tempdb数据库空间，即使不使用tempdbin RAM，也可以提高数据库的运行速度。
　注意事项：在生产环境中SQL Server不要设置小于32MB内存，而且数据库服务器上尽量扩充供虚拟内存、增大SQL Server可用内存，应考虑物理内存使用状况和磁盘空间；在可能的情况下，要为系统留有部分额外的内存，这样在服务器上打开一个服务或添加一个进程且不改变SQL Server内存配置时，不致于使NT服务器的运行速度受到影响(变得很慢)，一般认为最小为2MB最大为20MB。

4.2.3硬件提升

4.2.3.1 CPU/内存

如果测试确定存在处理器问题，您的第一个选择当然就是将处理器升级或切换到多处理器计算机。如果确定要升级处理器，应确保它有最大的 L2 缓存，IIS 将因此而受益，因为它的许多指令路径都包括多个组件，它们在高速缓存中运行时速度会大大加快。

计算机名\内存\可用内存 - 该计数器跟踪系统中的可用内存总量。操作系统尝试将该值保持在 4 MB 以上。为了达到最佳性能，该值最好为内存总量的 5%。

4.2.3.2 硬盘

不要将日志文件与 Web 页存储在同一个硬盘上。这将阻止硬盘日志记录线程干预检索 Web 页的线程。

优化 Web 页存储。站点上的所有相关 Web 页应该存储在同一个逻辑分区，这样可以提高文件系统缓存的性能。同时，Web 页文件不应有任何碎片，这样可以极大地加快读取单个文件的速度。

如果使用Ultra2的SCSI硬盘，可以显著提高IIS的性能。网络接口卡，内存的升级自然不用多言。

5 Session管理篇

HTTP 协议之所以能够获得如此大的成功，其设计实现的简洁性和无状态连接的高效率是很重要的原因。而为了在无状态的 HTTP 请求和有状态的客户端操作之间达到平衡，产生了服务器端会话 (Session) 的概念。Session的引入极大地方便了Web编程，但与之对应的Session管理变得异常重要。目前ASP.NET可以通过“进程内”、“进程外专用状态管理服务”和“SQL Server状态服务管理”三种方式来进行状态管理。对于默认的“进程内”管理方式只实现了一个进程内的基于内存的状态管理，故而存在很多问题：

1.所有的 Session 数据都保存在 Web 服务的进程中，会造成服务器支持会话数量受到服务器内存资源的限制问题，同时也因为大量非活动会话导致内存被无效占用。

2.服务器进程崩溃会导致所有的会话数据丢失。

回到我们的实际系统，目前我们使用Session变量大致有四种用途：

图5-1 Session变量使用范围

显然，前三种方式都是小数据量的，我们这里主要关注第四种方式——Session数据集变量。

把整个数据集存放在Session中，主要是为了用于后续处理或二次加工或用户翻页时重新绑定，一般情况下我们在编码时会忽略数据集的大小给Web-Server和交互时间带来的影响。实际上，一个超大数据集(记录数在10万条以上)所占用的空间是相当可观的，如果有数个并发，Web-Server的内存会急剧紧张。下表是实际测试的关于SQL执行时间的统计。

记录数（万）

执行时间（秒）

上一页 [1] [2] [3] [4] [5] [6] [7] 下一页