高性能ASP.NET站点构建之性能调优综述

本文涉及的产品
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
简介:

前言:这段时间,把系列文章又重新整理了一下,之前关于性能优化的介绍一些不是很清晰。可以说从本篇开始,才算是一个完整的系列的开始。 

本章的议题如下:

性能调优的一般过程

利用分析工具分析页面加载信息

利用分析工具分析性能瓶颈

性能调优的一般过程

在解决性能问题之前首先要确认问题的所在,首先就来看看确保高性能的一般过程:

1.持续监控

2.设定性能目标

3.持续改进

1.持续监控

网站的性能总体来说受两个方面的影响:

一,我们可以控制的,例如代码;

二,我们不能控制的,例如访问用户的数量,或者服务器本身

特别是随着站点的访问量增大的时候,原来没有出现的问题,现在可能出来了,不同的阶段要解决的问题也是不一样的。所以很有必要对网站进行持续的监控, 趁早发现网站变慢的原因。本篇的后面部门会介绍一些我们可以使用的监控服务,来帮助我们做这些事情。

2. 设定性能目标

网站的性能如何,一个最直观的感受就是:打开这个站点之后,页面加载的时间,这也是说是访问者最直接的体验。很多的优化工作(不管是前台的优化还是后台的优化)都是为了让用户更快的看到所想看的页面和信息。我们后面的讨论很多时候都是以这个为目标的。

首先必须要明白“快”的含义:一个网站的响应速度多快才算是“快”?因为优化网站需要花费很大的时间和精力,如果网站本身已经很快了,例如网页呈现到用户眼前的时间是毫秒级别的,我们确实可以再花时间让它更快,但是这样做起来成本会更高!

3.持续改进

在进行性能优化的时候,要涉及到很多的东西,所以在进行优化的时候必须确认:进行的优化措施确实的提高了站点的性能。为了达到这个目的,有几个规则可以遵循:

1. 每次优化只改动一处。如果改动了很多处,那么这些改动之间可能相互的影响,最后产生一些奇奇怪怪的现象,有时候这些"优化措施"反而使得网站性能降低。而且如果一次改动多次,也不利于衡量那些"优化措施"真真正正提升了网站的性能。

2. 不断的测试。每次进行了所谓的"优化"之后,一定要测试一下,这个"优化"是否真的提升了性能,如果没有提升,那么就回滚这个操作。

一般进行优化的步骤如下:

1. 记录现在网站的性能指数和一些相关的数据(后面会告诉大家如何获取这些性能指数数据)

2. 诊断站点的性能故障点.可能有几个地方都影响了站点的性能,但是,此时我们只是选择影响最大的那个因数进行优化。

3. 解决找出的性能故障点。

4. 测试。收集数据,和优化前进行比较,看看是否提升了性能。

5. 重复1到4步骤。

上面虽然提出了一些规则,但是我们可以灵活处理某些情况:在我们查找影响性能的问题的时候,我们发现多个问题,而且这些问题根据我们的经验判断会影响性能,那么我们可以同时修改此处。

我们用一个流程图来总结上面的优化步骤。如下:  

下面讲述用一些简单的工具来分析一些与站点性能有关的数据,在上一篇文章中,我们讨论了一下性能调优的一般过程,本篇就开始介绍一些方法和工具,让大家快速的入门。 

的议题如下:

性能调优的一般过程

利用分析工具分析页面加载信息

利用分析工具分析性能瓶颈

利用分析工具分析加载页面信息 

站点的优化说到底还是站点每一个页面的优化,即使得站点的页面更快的呈现在用户的眼前。所以在此之前,我们首先来看看一个web页面的组成部分:

1. Html文件:在ASP.NET中,Html文件通常是通过解析.aspx页面而产生的。而这个解析过程在服务端进行,同时这个过程也消耗了服务端的大部分资源。

2. 图片和flash文件:一个站点往往包含很多这样的的文件。

3. Js和css文件:这些文件可以阻止页面的呈现。

清楚了页面的组成部分之后,我们可以把使得页面加载变慢的因素分为如下几类:

1. 服务端的花费大量时间解析.aspx,也就是说服务端产生html文本的时间过长(导致这个问题的原因很多,例如数据库查询很慢,影响了页面的生成)。

2. 在服务端和浏览器之间,传递html文本花费大量的时间(例如,页面中的Viewstate很大,网络很慢等)。

3. 图片和flash文件的加载花费大量的时间。

4. Js和css的加载花费大量的时间。

为了使得一个页面的加载变快,那么我们就得知道:是以上哪一个过程影响了速度(本系列的后续文章会详细讲述)。一旦知道了是那类问题导致了性能问题,那么我们就可以对症下药。

下面我们就通过一些工具来简单的查看和分析站点的性能,目的让大家快速的了解如何进行简单的性能分析。

我们用瀑布图来分析页面的每个组成部分加载所花的时间,例如下面就是博客园首页加载的分析图(部分的截图)。

我们可以通过图中的“时间线“长短来知道每个文件加载的时间。时间线长越长,那么加载该文件的时间越长,反之。

看完了上面的图之后,大家应该很想知道:上面的图是如何生成的,那么下面就介绍一些生成页面加载瀑布图的工具。

我们首先来看看:Firefox+Firebug

Firefox下载地址:http://www.mozilla.com/en-US/firefox/

Firebug下载地址:http://getfirebug.com/

下面就开始演示如何生成页面加载的瀑布图(如果熟悉这个流程的朋友可以跳过此段)

1.  打开Firefox,然后按下F12,就看到如下的画面:

2.  在Firebug中,在选择“网络”下拉框中选择“启用”。

OK,下面我们就来详细的看看在瀑布图中一些数据和图示的意义。

1. 请求和响应的相关信息

在瀑布图中,点击每一行的”+”如下:

符号展开之后,我们可以看到所有的请求和响应头,如下:

 2. 时间线的相关信息

当我们把鼠标移到着色的时间线bar上面的时候,我们就可以看到请求该文件所花的时间的详细信息,如下

我们用一个表格来讲述每个时间段的含义:

域名解析

寻找请求的文件所在的服务器的IP地址所花的时间

建立连接

打开客户端到服务端的TCP链接所花的时间

发送请求

浏览器发送请求所花的时间。大家可能有点奇怪:为什么发送请求还要等待,难道不是打开连接就发送了请求吗?

其实浏览器会把要请求的文件的请求放在请求队列中,队列的长度一般都是有限制的,如果页面需要请求的文件很多,如果队列达到了最大的限制数量,那么后续的文件请求会等待。

等待响应

客户端发送请求一直到接受服务端的第一个字节所花的时间

接受数据

接受整个请求文件或者数据所花的时间

‘DOMContentLoaded’事件

从该请求开始进行DNS寻址到整个页面的DOM被下载下来所花的时间。注意:此时只是页面的骨架被下载下来了,其中的一些资源(如果图片,js等)没有下载下来。当页面的DOM下载下来了之后,用户就可以看到了页面了,但是有些资源还在陆续的下载中。

‘load’ 事件

从该请求开始进行DNS寻址到整个页面全部(包括资源)下载下来所花的时间。

3. 页面级的请求信息

也就是整个页面的请求的一些汇总信息。

 

下面主要讲述如何根据一些简单的工具和简单的现象来粗布的定位站点的性能问题。

利用分析工具分析性能瓶颈

在上一节中,讲述了如何使用Firebug来生成页面加载信息的瀑布图,同时也讲述了使得页面加载变慢的四个大的问题

1. 服务端花费大量时间解析.aspx时间过长。

2. 在服务端和浏览器之间,传递html时间过长

3. 图片和flash文件的加载时间过长

4. Jscss的加载花费时间过长

那么我们下面就根据瀑布图来判断:页面加载变慢,到底是因为哪个因素导致的。

1.  如何判断:服务端花费大量时间解析.aspx时间过长。

在下面的图示中,大家可以看到第一条时间线特别的长:其中紫色的那段表明了在浏览器接受到该页面的第一个字节之前等待的时间。也就是说,在浏览器请求Default.aspx页面之后,浏览器一直处于等待状态。只有浏览器接受到了Default.aspxDOM之后,才开始下载页面中的其他的资源(css,图片等)。如果在接受Default.aspxDOM之前等待的时间过长,那么势必影响其他的资源的下载,最后导致整个页面的加载变慢。

如果我们在用firebug生成瀑布图的时候,发现了上面的类似的现象,页面加载变慢的原因很有可能就是服务端在解析Default.aspx页面,生成html文本的时间太长了。至于是什么原因导致了服务端解析Default.aspx时间过长,那么需要进一步的分析。可能是代码写的不好,例如循环问题;可能是数据库问题,例如查询数据太慢或者数据太多等(后续文章详细讲述)。  

注:颜色表示的意思:

2. 如何判断:在服务端和浏览器之间,传递html时间过长

在下面的图中,大家可以看到紫色的线段比较的短,也就是说,服务端解析Default.aspx页面的时间还是比较短的,但是灰色的线段比较的长,。灰色的部分表示接受数据时间很长,也就是说服务端把DOM发送到浏览器,这个过程耗时比较的长。正如之前的问题一样,这个问题也会推迟页面的其他的资源下载,导致整个页面加载过慢。导致这个问题的原因可能是带宽问题,可能是数据过多等。

3. 如何判断:图片和flash等文件的加载时间过长

如下图所示,页面的解析和传送到客户端的时间比较的短,但是页面中的图片加载花费了大量的时间。现在的浏览器一般都会同时打开多个链接,并行的请求多个图片资源,而不是一个个的挨个请求。但是浏览器打开链接的数量是有限制的(不同的浏览器不一样),而且打开新的TCP链接也是需要花时间的,不是链接越多越好。后面我们会讲述如何减少图片等资源的加载时间。

4. 如何判断:Jscss的加载花费时间过长,阻止页面的呈现

如下图所示,在Default.aspx页面载入之后,浏览器就开始解析DOM(从上到下解析,例如head -> body…,下载资源。当页面解析到需要加载cssjs时,此时浏览器就会去服务端请求这些文件,而用户在浏览器中看到的Default页面将会是一片空白,一直到cssjs载入完成之后,页面开始下载图片等,此时页面才会慢慢的呈现出来。

下图就反应了这个问题。

 

原文链接:http://www.cnblogs.com/yanyangtian/archive/2011/02/11/1951055.html





















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

相关文章
|
29天前
|
存储 Shell Linux
快速上手基于 BaGet 的脚本自动化构建 .net 应用打包
本文介绍了如何使用脚本自动化构建 `.net` 应用的 `nuget` 包并推送到指定服务仓库。首先概述了 `BaGet`——一个开源、轻量级且高性能的 `NuGet` 服务器,支持多种存储后端及配置选项。接着详细描述了 `BaGet` 的安装、配置及使用方法,并提供了 `PowerShell` 和 `Bash` 脚本实例,用于自动化推送 `.nupkg` 文件。最后总结了 `BaGet` 的优势及其在实际部署中的便捷性。
60 10
|
28天前
|
前端开发 关系型数据库 MySQL
ThingsGateway:一款基于.NET8开源的跨平台高性能边缘采集网关
ThingsGateway:一款基于.NET8开源的跨平台高性能边缘采集网关
|
2月前
|
设计模式 存储 前端开发
揭秘.NET架构设计模式:如何构建坚不可摧的系统?掌握这些,让你的项目无懈可击!
【8月更文挑战第28天】在软件开发中,设计模式是解决常见问题的经典方案,助力构建可维护、可扩展的系统。本文探讨了.NET中三种关键架构设计模式:MVC、依赖注入与仓储模式,并提供了示例代码。MVC通过模型、视图和控制器分离关注点;依赖注入则通过外部管理组件依赖提升复用性和可测性;仓储模式则统一数据访问接口,分离数据逻辑与业务逻辑。掌握这些模式有助于开发者优化系统架构,提升软件质量。
41 5
|
2月前
|
C# Windows 开发者
超越选择焦虑:深入解析WinForms、WPF与UWP——谁才是打造顶级.NET桌面应用的终极利器?从开发效率到视觉享受,全面解读三大框架优劣,助你精准匹配项目需求,构建完美桌面应用生态系统
【8月更文挑战第31天】.NET框架为开发者提供了多种桌面应用开发选项,包括WinForms、WPF和UWP。WinForms简单易用,适合快速开发基本应用;WPF提供强大的UI设计工具和丰富的视觉体验,支持XAML,易于实现复杂布局;UWP专为Windows 10设计,支持多设备,充分利用现代硬件特性。本文通过示例代码详细介绍这三种框架的特点,帮助读者根据项目需求做出明智选择。以下是各框架的简单示例代码,便于理解其基本用法。
73 0
|
2月前
|
Java Spring 自然语言处理
Spring 框架里竟藏着神秘魔法?国际化与本地化的奇妙之旅等你来揭开谜底!
【8月更文挑战第31天】在软件开发中,国际化(I18N)与本地化(L10N)对于满足不同地区用户需求至关重要。Spring框架提供了强大支持,利用资源文件和`MessageSource`实现多语言文本管理。通过配置日期格式和货币符号,进一步完善本地化功能。合理应用这些特性,可显著提升应用的多地区适应性和用户体验。
32 0
|
2月前
|
开发者 C# Android开发
Xamarin 与 .NET:解锁现代化移动应用开发的超级武器——深入探讨C#与.NET框架如何赋能跨平台应用,实现高效编码与卓越性能
【8月更文挑战第31天】Xamarin 与 .NET 的结合为开发者提供了强大的平台,用于构建现代化移动应用。通过 C# 和 .NET 框架,Xamarin 可以实现一次编写、多平台运行,覆盖 iOS、Android 和 Windows。这种方式不仅节省了开发时间和成本,还保证了应用的一致性和高质量。Xamarin 是一个开源框架,专为跨平台移动应用开发设计,允许使用 C# 语言和 .NET 核心库构建原生应用,并访问各平台特定功能。微软维护的 Xamarin 是 Visual Studio 生态系统的一部分,极大地提高了开发效率。
61 0
|
2月前
|
开发者 Apache 程序员
揭秘Apache Wicket:页面生命周期背后的神秘力量!
【8月更文挑战第31天】李工是一位热爱Web开发的程序员,近日在技术博客上分享了他对Apache Wicket框架的学习心得,特别是页面生命周期的理解。他认为掌握Wicket页面生命周期对于开发富交互式Web应用至关重要。他通过一个简单的计数器应用示例,详细解释了Wicket的组件化设计理念以及页面和组件在生命周期中的变化。
30 0
|
2月前
|
存储 测试技术 C#
Blazor WebAssembly 开启离线应用开发新时代!C# 与.NET 助力,打造高性能跨平台新体验!
【8月更文挑战第31天】在互联网快速发展的今天,用户对Web应用体验的要求日益提高,尤其在无网络环境下使用应用的需求愈发明显。Blazor WebAssembly 应运而生,它基于 WebAssembly 技术,允许开发者利用 C# 和 .NET 构建交互式 Web 应用,无需服务器支持即可在浏览器中运行,从而实现离线使用。Blazor WebAssembly 具有使用熟悉的技术栈、高性能、离线支持以及跨平台等优势。开发者可通过安装开发工具、创建项目、编写代码、调试测试及发布应用几个步骤来进行开发。这为离线应用开发开启了新篇章。
41 0
|
2月前
|
传感器 开发框架 物联网
揭开.NET在IoT领域的神秘面纱:如何构建智能设备,让未来生活触手可及?
【8月更文挑战第28天】随着物联网技术的发展,智能设备正深入我们的生活。.NET作为跨平台开源框架,在IoT领域应用广泛。本文介绍如何利用.NET构建智能设备,通过实例展示从环境搭建到项目创建、代码编写及运行的全过程,帮助开发者快速实现IoT解决方案,开启智能设备开发的新篇章。
33 0
下一篇
无影云桌面