顺便说一下，我曾经帮助对一个传统的 ASP 应用程序进行故障排除，该应用程序由于内存占用不受限制而定期重新启动。一个没有经验的开发人员将目标 SELECT 语句转换成了 SELECT *，而没有考虑要查询的表包含图像，这些图像很大而且数目很多。问题由于未检测到内存泄漏而恶化。（我的托管代码领域！）多年来运行正常的应用程序开始突然停止工作，因为以前返回一两千字节数据的 SELECT 语句现在却返回了几兆字节。如果再加上不充分的版本控制，开发团队的生活将不得不“亢奋起来”— 这里所谓的“亢奋”，就如同当您在晚上要睡觉时，还不得不看着您的孩子玩令人厌烦的足球游戏一样。
理论上，传统的内存泄漏不会发生在完全由托管代码组成的 ASP.NET 应用程序中。但是内存使用量不足会通过强制垃圾收集更频繁地发生而影响性能。即使是在 ASP.NET 应用程序中，也要警惕 SELECT *!
返回页首
不要完全信赖它 — 请设置数据库的配置文件！
作为一名顾问，我经常被询问为何应用程序没有按预期执行。最近，有人询问我的团队为何 ASP.NET 应用程序只完成请求文档所需吞吐量（每秒的请求数）的大约 1/100。我们以前所发现的问题是我们在不能正常运行的 Web 应用程序中发现的问题特有的 — 和我们所有人应该认真对待的教训。
我们运行 SQL Server Profiler 并监视此应用程序和后端的数据库之间的交互情况。在一个更极端的案例中，仅仅只是一个按钮单击，就导致数据库发生了 1,500 多个错误。您不能那样构建高性能的应用程序。良好的体系结构总是从良好的数据库设计开始。不管您的代码的效率有多高，如果它被编写不佳的数据库所拖累，就会不起作用。
糟糕的数据访问体系结构通常源于下面的一个或多个方面：
• 拙劣的数据库设计（通常由开发人员设计，而不是数据库管理员）。
• DataSets 和 DataAdapters 的使用 — 尤其是 DataAdapter.Update，它适用于 Windows 窗体应用程序和其他胖客户端，但是对于 Web 应用程序来说通常不理想。
• 具有拙劣编制计算程序、以及执行相对简单的操作需消耗很多 CPU 周期的设计糟糕的数据访问层 (DAL)。
必须先确定问题才能对其进行处理。确定数据访问问题的方式是运行 SQL Server Profiler 或等效的工具以查看后台正在执行的操作。检查应用程序和数据库之间的通信之后，性能调整才完成。尝试一下 — 您可能会对您的发现大吃一惊。
返回页首
结论
现在您已经了解在生成 ASP.NET 生产应用程序过程中可能遇到的一些问题及其解决方案了。下一步是仔细查看您自己的代码并尝试避免我在此概述的一些问题。ASP.NET 可能降低了 Web 开发人员的门槛，但是您的应用程序完全有理由灵活、稳定和高效。请认真考虑，避免出现新手易犯的错误。
图 8 提供了一个简短检查列表，您可以使用它来避免本文中描述的缺陷。您可以创建一个类似的安全缺陷检查列表。例如：
• 您是否已经对包含敏感数据的配置节进行加密？
• 您是否正在检查并验证在数据库操作中使用的输入，是否使用了 HTML编码输入作为输出？
• 您的虚拟目录中是否包含具有不受保护的扩展名的文件？
如果您重视网站、承载网站的服务器以及它们所依赖的后端资源的完整性，则这些问题非常重要。
Jeff Prosise 是对 MSDN Magazine 贡献很大的编辑以及多本书籍的作者，这些书籍中包括 Programming Microsoft .NET (Microsoft Press, 2002)。他也是软件咨询和教育公司 Wintellect 的共同创始人。
摘自 MSDN Magazine 的 2006 年 7 月刊。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
