ASP.NET企业级应用性能优化-内存分析

简介:





为什么要写篇文章

 
谈到 ASP.NET 应用的开发,使我不禁想起之前有朋友对我说过的一句话:做网站没有任何的技术含量。后来他告诉我,做网站,在 .NET 平台上面很简单,不就是拖几个控件,搞点布局,写点 js ,然后敲上几个数据的增删查改就完了,系统大了,就多敲几个。当时,朋友之所以说这样的话,是与他的公司与项目背景相关的。
 
在很多的外包公司里面,常常用 ASP.NET 来快速的搭建一个 Web 应用,例如 OA 系统,企业门户,管理系统,而这些系统往往都注重在业务流程上面,不会在其他方面关注过多,例如,性能,使用这些系统的用户也不多,顶多几千个,所以对于很多真正触及到 Web 应用的要考虑的问题,例如,高并发,高性能,稳定,安全等,没有接触到。后来,我去了其他的公司,接触到那种承受百万,千万级访问量的应用的时候,越发觉得自己有很多的知识需要学习。
 
在与朋友共事的一些项目中,很多项目的性能都很差,我们大家都想解决这个问题,但是都没有办法,仅仅只是知道一些基本的措施,很多都是从网络上面“道听途说”,例如用 stringbuilder 来拼接字符串,尽量用 for 而不是 foreach 。其实说到底,还是我们对 .NET 不够深入,虽然说,我们在 .NET 平台上面做了很多的项目,其实很多的应用只是在 .NET 平台的表层开发。(由此可见,“题海战术”不一定能够练就解题高手,也不一定能够练就解决问题的思维。)
 
其实性能优化问题,不仅仅只是 Web 应用独有的,而是说,在 Web 应用中,可能关注的多一点。本篇文章谈的是 ASP.NET 应用的性能优化,其实,从本质上面,还是谈的 .NET 应用的优化。对于其他平台的朋友,也是非常有参考价值的。
 
          在本篇文章中,不会谈及很多的调优的方法理论(其实这些方法论是很有作用的),我会从谈及一些实际,可操作性的知识,让朋友们学而即用,同时也让朋友对开始对 .NET 加深认识。
 
          本篇的内容从以下几个方面进行展开: 内存瓶颈分析, CPU 瓶颈分析,缓存分析,资源等待分析,数据库瓶颈分析, HTTP 优化
 
首先来看看内存瓶颈分析。虽然,我在之前的一篇稿子《 .NET 企业级开发》中谈   这个问题,但是,为了本篇文章的完整性,我还是提一下,同时也将这个问题讲更全面一些。
 
 
内存瓶颈分析
 
内存性能问题可以分为两个部分:内部内存压力,外部内存压力。其中内部内存压力主要是站点本身在运行的过程中消耗过多的内存,基本是可以从托管资源,非托管资源两方面分析;而外部内存压力指代站点所在的服务器上面的其他应用于站点本身之间进行资源的争夺,从而使得站点可以使用的内存太少。那么在 ASP.NET 企业级应用中,我们技术人员关注点可以放在内部内存压力。
 
首先看看托管资源的问题。
 
为什么要讨论托管资源?因为托管资源(就是分配中在托管堆上面的对象),分配在托管堆上,而托管堆在内存中,所有托管资源的合理的分配和回收,会对内存产生影响。
 
       ASP.NET 应用的功能就是由很多的对象组合完成的,所以讨论托管资源很有必要。
        .NET 中,托管堆分为两类:大对象托管堆,小对象托管堆。一般而言,如果对象所占的空间小于 85K ,就分配在小堆上面,反之,分配在大堆上面。如图的小堆图:
 
 
    在对上面,对象被划分为三代: 0,1,2 代。“代”数越大,被回收的可能性就越小。基于这个理论,就要避免原本只要是低代的对象变为高代的对象,例如某个对象用完之后就销毁的,原本是 0 代的,现在存活到了 2 代,那么它所占的内存就浪费了。虽然,垃圾回收机制没有在一定程度上回收,但是如果我们总是“霸占”着对象,垃圾回收也没有办法。
 
        下面,举个例子,形象的说明一下。对于一个大型的 ASP.NET 应用而言,里面会包含很多的对象,假设 10000 个,其中每次请求都要产生的 100 个临时对象。如果这些临时对象,被不合理的分配,成为了大代的对象,我们来算一算。
 
如果这个 100 个对象每个占 1k 的空间,那么 100 个,我们约等于 0.1M ,如果站点访问量是 10w ,那么如果这些 0.1 乘以 10w ,如果访问量是 100w 1000w ,结果如何?大家已经清楚了。很多,需要将问题放大来看,结果就很清晰了。
 
        对于对象的使用,有一点要记住:尽可能迟的分配,尽可能早的释放。
        下面,我们可以谈谈,如何找出内存问题。
 
        可以采用工具加分析的方式。可以采用 System Counter CLR Profiler ANTS Memory Profiler(Red Gate) 等。其中 System Counter CLR Profiler 分析的比较的粗糙, ANTS Memory Profiler(Red Gate) 可以指出是哪段代码有问题,方便解决问题。如图
 
 
   本篇由于篇幅的限制,先到这里,下一篇,我们可以看看一些常见的性能问题,例如字符串相关问题,Session,缓存,对象池。
 




















本文转自yanyangtian51CTO博客,原文链接:http://blog.51cto.com/yanyangtian/755160  ,如需转载请自行联系原作者

相关文章
|
1月前
|
Web App开发 监控 JavaScript
监控和分析 JavaScript 内存使用情况
【10月更文挑战第30天】通过使用上述的浏览器开发者工具、性能分析工具和内存泄漏检测工具,可以有效地监控和分析JavaScript内存使用情况,及时发现和解决内存泄漏、过度内存消耗等问题,从而提高JavaScript应用程序的性能和稳定性。在实际开发中,可以根据具体的需求和场景选择合适的工具和方法来进行内存监控和分析。
|
19天前
|
存储 算法 Java
Java内存管理深度剖析与优化策略####
本文深入探讨了Java虚拟机(JVM)的内存管理机制,重点分析了堆内存的分配策略、垃圾回收算法以及如何通过调优提升应用性能。通过案例驱动的方式,揭示了常见内存泄漏的根源与解决策略,旨在为开发者提供实用的内存管理技巧,确保应用程序既高效又稳定地运行。 ####
|
19天前
|
存储 缓存 JavaScript
如何优化Node.js应用的内存使用以提高性能?
通过以上多种方法的综合运用,可以有效地优化 Node.js 应用的内存使用,提高性能,提升用户体验。同时,不断关注内存管理的最新技术和最佳实践,持续改进应用的性能表现。
110 62
|
15天前
|
存储 缓存 监控
如何使用内存监控工具来优化 Node.js 应用的性能
需要注意的是,不同的内存监控工具可能具有不同的功能和特点,在使用时需要根据具体工具的要求和操作指南进行正确使用和分析。
61 31
|
13天前
|
存储 缓存 监控
Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
本文介绍了Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
43 7
|
13天前
|
存储 算法 Java
Java 内存管理与优化:掌控堆与栈,雕琢高效代码
Java内存管理与优化是提升程序性能的关键。掌握堆与栈的运作机制,学习如何有效管理内存资源,雕琢出更加高效的代码,是每个Java开发者必备的技能。
42 5
|
13天前
|
并行计算 算法 测试技术
C语言因高效灵活被广泛应用于软件开发。本文探讨了优化C语言程序性能的策略,涵盖算法优化、代码结构优化、内存管理优化、编译器优化、数据结构优化、并行计算优化及性能测试与分析七个方面
C语言因高效灵活被广泛应用于软件开发。本文探讨了优化C语言程序性能的策略,涵盖算法优化、代码结构优化、内存管理优化、编译器优化、数据结构优化、并行计算优化及性能测试与分析七个方面,旨在通过综合策略提升程序性能,满足实际需求。
37 1
|
15天前
|
JavaScript
如何使用内存快照分析工具来分析Node.js应用的内存问题?
需要注意的是,不同的内存快照分析工具可能具有不同的功能和操作方式,在使用时需要根据具体工具的说明和特点进行灵活运用。
36 3
|
1月前
|
缓存 算法 Java
本文聚焦于Java内存管理与调优,介绍Java内存模型、内存泄漏检测与预防、高效字符串拼接、数据结构优化及垃圾回收机制
在现代软件开发中,性能优化至关重要。本文聚焦于Java内存管理与调优,介绍Java内存模型、内存泄漏检测与预防、高效字符串拼接、数据结构优化及垃圾回收机制。通过调整垃圾回收器参数、优化堆大小与布局、使用对象池和缓存技术,开发者可显著提升应用性能和稳定性。
46 6
|
29天前
|
开发框架 监控 .NET
【Azure App Service】部署在App Service上的.NET应用内存消耗不能超过2GB的情况分析
x64 dotnet runtime is not installed on the app service by default. Since we had the app service running in x64, it was proxying the request to a 32 bit dotnet process which was throwing an OutOfMemoryException with requests >100MB. It worked on the IaaS servers because we had the x64 runtime install