网站性能优化测试,网站前端的性能优化与测试——内容过期

seo基础     2020-12-29    浏览:0

网站前端的性能优化与测试——内容过期

  最近在搞网站的界面UI改版,除了少数的几个页面外,全站基本统一了界面风格,在解决各种浏览器兼容问题的时候,不经意搜到一个FireFox的插件 YSlow for Firebug,他是开源的网站优化工具,用于测试网站的前端性能。在YSlow的评价性能等级上,有十三条规则:1. Make fewer HTTP requests,2. Use a CDN,3. Add an Expires header,4. Gzip components,5. Put CSS at the top,6. Put JS at the bottom,7. Avoid CSS expressions,8. Make JS and CSS external,9. Reduce DNS lookups,10. Minify JS,11. Avoid redirects,12. Remove duplicate scripts,13. Configure ETags。这是《Yahoo!网站性能最佳体验的34条黄金守则》中进一步精简的,现在先来讨论第3条,这是比较容易可以实现了的,只需配置一下iis 或者apache等web服务器,给http header 加上“内容过期”即可实现。考虑到网站正在改版,css、js还需要修改,这里分别给相关资源加上较合适的过期时间:1、image、flash 100天后过期;2、css、js 3天后过期。

  配置过程:在iis管理器中打开相关网站,找到需要设置的文件、文件夹,然后点击属性,在“http头”一项中即可设置。

  如果指定一个过期时间后,如 2008-12-26 14:26:00,则会在浏览器的http header received中会得到一个明确的过期时间:如Expires:Fir,26 Dec 2008 14:26:00 GMT,这是一个标准的GMT时间(格林尼治时间);如果指定100天后过期,header received则会收到Cache-Control:max-age=8640000(以秒来计算)。以上两个header received该指示浏览器缓存该请求的内容,并会在浏览器的临时缓存文件夹中保存该文件直至其到达过期时间(先不考虑浏览器因为缓存空间不足而自动清空缓存和用户清空缓存这些情况),Internet explorer 可以在 C:documents and SettingsAdministratorLocal SettingsTemporary Internet Files 文件夹找到这些缓存文件。在首次访问时,浏览器会根据Expires 和 Cache-Control是否缓存内容,第二次访问时,如果缓存的内容没有过期,则从缓存直接读取相关内容。还有一种情况,当用户点击刷新按钮时,不管是否缓存,浏览器都会从服务器新请求所有内容。

  使用 HttpWatch、yslow的测试过程:

  1、打开过期时间、第一次访问

网站前端的性能优化与测试——内容过期 三联

  (HttpWatch)

  (YSlow)

  2、打开过期时间、第二次访问

  (HttpWatch)

  (YSlow)

  3、打开过期时间,HttpWatch 两次访问结果比较

  4、没有打开过期时间、第一次访问

  5、没有打开过期时间、第二次访问

  6、没有打开过期时间,HttpWatch 两次访问结果比较

  测试的两次结果略有不同,但是我们可以看到,打开过期时间后第二次访问时,相关文件已经被缓存了,Sent、Received都没有产生通信流量,在 Result一项中显示的是Cache,很明显是从缓存中读取数据了。从第一次访问时的49个Request降低为 9个Request,请求时间与流量都明显减少。打开一个没有设置“内容过期”的网站,首次访问和第二次访问产生的http请求数没有任何改变,但 received也降低许多,这是由于第一次请求时,浏览器会在临将相关文件保存在临时文件夹,服务端会返回给客户端一个Last-Modified字段,以后每次需要这个文件的时候,客户端会把这个字段发送到服务端,服务端拿来和最新的文件做比较,如果没有被改变过,那么返回304 Not Modified,那么客户端就直接从缓存里面拿,所以产生的流量非常小,但是request并没有减少,如上面的第5点。

  经过这几次测试比较,可以看到缓存所起的重要作用。 另外在asp.net等程序中,也可以指定过期时间,如:Response.Expires = 3600,这样页面的text/html内容也一样会被缓存,如果数据库内容已经更改,在用户再次访问时,内容并不会更新,在过期时间之内,要获得最新内容可以手动刷新。如果程序中没用指定过期时间、Cache,数据库内容改变后,不管怎样访问网页(新开浏览器,后退),都会得到最新的内容。


优化网站性能架构提升用户体验

  什么叫高性能的网站?

  两个网站性能架构设计方案:A方案和B方案,A方案在小于100个并发用户访问时,每个请求的响应时间是1秒,当并发请求达到200的时候,请求的响应时间将骤增到10秒。B方案不管是100个并发用户访问还是200个并发用户访问,每个请求的响应时间都差不多是1.5秒。哪个方案的性能好?如果老板说“我们要改善网站的性能”,他指的是什么?

  同类型的两个网站,X网站服务器平均每个请求的处理时间是500毫秒,Y网站服务器平均每个请求的处理时间是1000毫秒,为什么用户却反映Y网站的速度快呢?

  网站性能是客观的指标,可以具体体现到响应时间、吞吐量等技术指标,同时也是主观的感受,而感受则是一种与具体参与者相关的微妙的东西,用户的感受和工程师的感受不同,不同的用户感受也不同。

  网站性能测试

  性能测试是性能优化的前提和基础,也是性能优化结果的检查和度量标准。不同视角下的网站性能有不同的标准,也有不同的优化手段。

  不同视角下的网站性能

  软件工程师说到网站性能的时候,通常和用户说的不一样。

  1.用户视角的网站性能

  从用户角度,网站性能就是用户在浏览器上直观感受到的网站响应速度快还是慢。用户感受到的时间,包括用户计算机和网站服务器通信的时间、网站服务器处理的时间、用户计算机浏览器构造请求解析响应数据的时间,如图1所示。

优化网站性能架构提升用户体验 三联

  图1 用户视角的网站性能

  不同计算机的性能差异,不同浏览器解析HTML速度的差异,不同网络运营商提供的互联网宽带服务的差异,这些差异最终导致用户感受到的响应延迟可能会远远大于网站服务器处理请求需要的时间。

  在实践中,使用一些前端架构优化手段,通过优化页面HTML式样、利用浏览器端的并发和异步特性、调整浏览器缓存策略、使用CDN服务、反向代理等手段,使浏览器尽快地显示用户感兴趣的内容、尽可能近地获取页面内容,即使不优化应用程序和架构,也可以很大程度地改善用户视角下的网站性能。

  2.开发人员视角的网站性能

  开发人员关注的主要是应用程序本身及其相关子系统的性能,包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等技术指标。主要的优化手段有使用缓存加速数据读取,使用集群提高吞吐能力,使用异步消息加快请求响应及实现削峰,使用代码优化手段改善程序性能。

  3.运维人员视角的网站性能

  运维人员更关注基础设施性能和资源利用率,如网络运营商的带宽能力、服务器硬件的配置、数据中心网络架构、服务器和网络带宽的资源利用率等。主要优化手段有建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用等。

  性能测试指标

  不同视角下有不同的性能标准,不同的标准有不同的性能测试指标,从开发和测试人员的视角,网站性能测试的主要指标有响应时间、并发数、吞吐量、性能计数器等。

  1.响应时间

  指应用执行一个操作需要的时间,包括从发出请求开始到收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标,直观地反映了系统的“快慢”。表4.1列出了一些常用的系统操作需要的响应时间。

  表1 常用系统操作响应时间表

  测试程序通过模拟应用程序,记录收到响应和发出请求之间的时间差来计算系统响应时间。但是记录及获取系统时间这个操作也需要花费一定的时间,如果测试目标操作本身需要花费的时间极少,比如几微秒,那么测试程序就无法测试得到系统的响应时间。实践中通常采用的办法是重复请求,比如一个请求操作重复执行一万次,测试一万次执行需要的总响应时间之和,然后除以一万,得到单次请求的响应时间。

  2.并发数

  指系统能够同时处理请求的数目,这个数字也反映了系统的负载特性。对于网站而言,并发数即网站并发用户数,指同时提交请求的用户数目。

  与网站并发用户数相对应的还有网站在线用户数(当前登录网站的用户总数)和网站系统用户数(可能访问系统的总用户数,对多数网站而言就是注册用户数)。其数量比较关系为:

  网站系统用户数>>网站在线用户数>>网站并发用户数

  在网站产品设计初期,产品经理和运营人员就需要规划不同发展阶段的网站系统用户数,并以此为基础,根据产品特性和运营手段,推算在线用户数和并发用户数。这些指标将成为系统非功能设计的重要依据。

  现实中,经常看到某些网站,特别是电商类网站,市场推广人员兴致勃勃地打广告打折促销,用户兴致勃勃地去抢购,结果活动刚一开始,就因为并发用户数超过网站最大负载而响应缓慢,急性子的用户不停刷新浏览器,导致系统并发数更高,最后以服务器系统崩溃,用户浏览器显示 “Service is too busy”而告终。出现这种情况,有可能是网站技术准备不充分导致,也有可能是运营人员错误地评估并发用户数导致。

  测试程序通过多线程模拟并发用户的办法来测试系统的并发处理能力,为了真实模拟用户行为,测试程序并不是启动多线程然后不停地发送请求,而是在两次请求之间加入一个随机等待时间,这个时间被称作思考时间。

  3.吞吐量

  指单位时间内系统处理的请求数量,体现系统的整体处理能力。对于网站,可以用“请求数/秒”或是“页面数/秒”来衡量,也可以用“访问人数/天”或是“处理的业务数/小时”等来衡量。TPS(每秒事务数)是吞吐量的一个常用量化指标,此外还有HPS(每秒HTTP请求数)、QPS(每秒查询数)等。

  在系统并发数由小逐渐增大的过程中(这个过程也伴随着服务器系统资源消耗逐渐增大),系统吞吐量先是逐渐增加,达到一个极限后,随着并发数的增加反而下降,达到系统崩溃点后,系统资源耗尽,吞吐量为零。

  而这个过程中,响应时间则是先保持小幅上升,到达吞吐量极限后,快速上升,到达系统崩溃点后,系统失去响应。系统吞吐量、系统并发数及响应时间之间的关系将在本章后面内容中介绍。

  系统吞吐量和系统并发数,以及响应时间的关系可以形象地理解为高速公路的通行状况:吞吐量是每天通过收费站的车辆数目(可以换算成收费站收取的高速费),并发数是高速公路上的正在行驶的车辆数目,响应时间是车速。车辆很少时,车速很快,但是收到的高速费也相应较少;随着高速公路上车辆数目的增多,车速略受影响,但是收到的高速费增加很快;随着车辆的继续增加,车速变得越来越慢,高速公路越来越堵,收费不增反降;如果车流量继续增加,超过某个极限后,任何偶然因素都会导致高速全部瘫痪,车走不动,费当然也收不着,而高速公路成了停车场(资源耗尽)。

  网站性能优化的目的,除了改善用户体验的响应时间,还要尽量提高系统吞吐量,最大限度利用服务器资源。

  4.性能计数器

  它是描述服务器或操作系统性能的一些数据指标。包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。这些指标也是系统监控的重要参数,对这些指标设置报警阈值,当监控系统发现性能计数器超过阈值时,就向运维和开发人员报警,及时发现处理系统异常。

  System Load即系统负载,指当前正在被CPU执行和等待被CPU执行的进程数目总和,是反映系统忙闲程度的重要指标。多核CPU的情况下,完美情况是所有CPU都在使用,没有进程在等待处理,所以Load的理想值是CPU的数目。当Load值低于CPU数目的时候,表示CPU有空闲,资源存在浪费;当Load值高于CPU数目的时候,表示进程在排队等待CPU调度,表示系统资源不足,影响应用程序的执行性能。在Linux系统中使用 top命令查看,该值是三个浮点数,表示最近1分钟,10分钟,15分钟的运行队列平均进程数。如图4.2所示。

  图2 在Linux命令行查看系统负载

  性能测试方法

  性能测试是一个总称,具体可细分为性能测试、负载测试、压力测试、稳定性测试。

  性能测试

  以系统设计初期规划的性能指标为预期目标,对系统不断施加压力,验证系统在资源可接受范围内,是否能达到性能预期。

  负载测试

  对系统不断地增加并发请求以增加系统压力,直到系统的某项或多项性能指标达到安全临界值,如某种资源已经呈饱和状态,这时继续对系统施加压力,系统的处理能力不但不能提高,反而会下降。

  压力测试

  超过安全负载的情况下,对系统继续施加压力,直到系统崩溃或不能再处理任何请求,以此获得系统最大压力承受能力。

  稳定性测试

  被测试系统在特定硬件、软件、网络环境条件下,给系统加载一定业务压力,使系统运行一段较长时间,以此检测系统是否稳定。在不同生产环境、不同时间点的请求压力是不均匀的,呈波浪特性,因此为了更好地模拟生产环境,稳定性测试也应不均匀地对系统施加压力。

  性能测试是一个不断对系统增加访问压力,以获得系统性能指标、最大负载能力、最大压力承受能力的过程。所谓的增加访问压力,在系统测试环境中,就是不断增加测试程序的并发请求数,一般说来,性能测试遵循如图4.3所示的抛物线规律。

  图4.3中的横坐标表示消耗的系统资源,纵坐标表示系统处理能力(吞吐量)。在开始阶段,随着并发请求数目的增加,系统使用较少的资源就达到较好的处理能力(a~b段),这一段是网站的日常运行区间,网站的绝大部分访问负载压力都集中在这一段区间,被称作性能测试,测试目标是评估系统性能是否符合需求及设计目标;随着压力的持续增加,系统处理能力增加变缓,直到达到一个最大值(c点),这是系统的最大负载点,这一段被称作负载测试。测试目标是评估当系统因为突发事件超出日常访问压力的情况下,保证系统正常运行情况下能够承受的最大访问负载压力;超过这个点后,再增加压力,系统的处理能力反而下降,而资源消耗却更多,直到资源消耗达到极限(d点),这个点可以看作是系统的崩溃点,超过这个点继续加大并发请求数目,系统不能再处理任何请求,这一段被称作压力测试,测试目标是评估可能导致系统崩溃的最大访问负载压力。

  图3 性能测试曲线

  性能测试反应的是系统在实际生产环境中使用时,随着用户并发访问数量的增加,系统的处理能力。与性能曲线相对应的是用户访问的等待时间(系统响应时间),如图4.4所示。

  图4 并发用户访问响应时间曲线

  在日常运行区间,可以获得最好的用户响应时间,随着并发用户数的增加,响应延迟越来越大,直到系统崩溃,用户失去响应。

  性能测试报告

  测试结果报告应能够反映上述性能测试曲线的规律,阅读者可以得到系统性能是否满足设计目标和业务要求、系统最大负载能力、系统最大压力承受能力等重要信息,表4.2是一个简单示例。

  表2 性能测试结果报告

  性能优化策略

  如果性能测试结果不能满足设计或业务需求,那么就需要寻找系统瓶颈,分而治之,逐步优化。

  1.性能分析

  大型网站结构复杂,用户从浏览器发出请求直到数据库完成操作事务,中间需要经过很多环节,如果测试或者用户报告网站响应缓慢,存在性能问题,必须对请求经历的各个环节进行分析,排查可能出现性能瓶颈的地方,定位问题。

  排查一个网站的性能瓶颈和排查一个程序的性能瓶颈的手法基本相同:检查请求处理的各个环节的日志,分析哪个环节响应时间不合理、超过预期;然后检查监控数据,分析影响性能的主要因素是内存、磁盘、网络、还是CPU,是代码问题还是架构设计不合理,或者系统资源确实不足。

  2.性能优化

  定位产生性能问题的具体原因后,就需要进行性能优化,根据网站分层架构,可分为Web前端性能优化、应用服务器性能优化、存储服务器性能优化3大类。

  关于作者:

  李智慧,曾在阿里巴巴担任技术专家,参与阿里巴巴基础技术平台开发和www.alibaba.com架构设计。目前就职英特尔亚太研发中心从事云计算与大数据方面的研发工作。本文节选自《大型网站技术架构:核心原理与案例分析》一书,李智慧著,由电子工业出版社出版。


怎么测试一个网站的性能啊?
网站性能工具Yslow的使用方法
Yslow是雅虎开发的基于网页性能分析浏览器插件,从年初我使用了YSlow后,改变了网站模板大量冗余代码,不仅提升了网页的打开速度,这款插件还帮助我分析了不少其他网站的代码,之前我还特意写了提高网站速度的秘籍,就是通过这款插件分析得出的。网络上已经有不少Yslow使用说明了,本文我想介绍下我使用Yslow的方法和一些别人没提到的小技巧。
Yslow的安装方法
现在Yslow已经有很多版本了,打开Yslow官网就能看到有四个版本可供选择:火狐(firefox)浏览器、谷歌(chrome)浏览器、欧朋(opera)浏览器和移动版。
安装Yslow要先安装 Firebug(本地址以火狐为例),两种方法启动Yslow:1、打开Firebug窗口,选择Yslow选项。2、直接点击火狐右下角的Yslow启动按钮。
JSLint是一个强大的工具,它可以检验HTML代码以及内联的Javascript代码,通过JSLint发现了google analytics上的一个js错误。
ALL JS:查看你这个网页上一共引用了多少JS。
All JS Beautified:把所有JS放在打开的页面中,利用站长统一检查(我感觉作用不大)。
All JS Minified:同上,但它显示的是压缩过的js代码,如果你要JS优化,它已经给你优化好了,来过来直接用。
All CSS:显示你网页所有CSS文件。
YUI CSS Compressor:显示网页压缩后的CSS文件,也是拿过来可以直接用的。
All Smush.it?:图片在线优化网站,点击它后会自动跳到smushit网站上给你自动优化CSS图片,该网站提供了优化前与优化后的对比,点击直接下载优化后的图片,在覆盖到自己网站上就可以了,强烈推荐。
Printable View:这个是打印用的,部门开会、前端设计师讨论、向老板汇报时估计用的上。
我目前在用,希望对你有帮组
网站建设:大型网站的前端性能优化和规范

  (文/scott )Web性能涉及的范围太广,但一般web开发者在程序上线以后很多都曾遇到过性能的问题。普遍表现为页面速度开始急剧变慢,正常访问时间变的很长,或则干脆给你抛出异常错误页面。这里会涉及到很多可能发生的情况,举例几个最主要发生的情况:

  * 数据库连接超过最大限制,一般表现为程序的连接池满,拒绝了与数据库的连接。

  * 数据库死锁

  * Web Server 超过最大连接数(一般在虚拟主机上才会限制)

  * 内存泄漏

  * Http连接数太多,即访问量超过了机器和软件设计正常所能提供的服务

  而今天分享的主要是比较偏向前端

  浏览器请求和响应的过程

网站建设:大型网站的前端性能优化和规范 三联

  第一步、浏览器预处理

  查询Cache:读取Cache 或者发送304请求

  第二步、查询DNS

  优化规则--减少DNS查找

  DNS缓存

  浏览器DNS缓存 计算机DNS缓存 服务器DNS缓存(TTL)

  使用Keep-Alive特性

  减少DNS查找

  当客户端的DNS缓存为空时,DNS查找的数量与Web页面中唯一主机名的数量相等。减少唯一主机名的数量就可以减少DNS查找的数量。

  较少的域名来减少DNS查找(2-4个主机)

  第三步、建立连接

  优化规则-- 使用内容分发网络

  美国十大Internet网站和CDN服务提供商

  页面静态化,取决于发布系统

  Ctrip使用的China-Cache和网宿

  优化规则--用域名划分页面内容

  按页面内容划分域名,在合适的资源服务器上存放文件

  第四步、发送请求

  优化规则-- 减少HTTP请求

  HTTP请求30-40,合并文件,图片地图,内联图像

  a)js文件(不超过7个)

  1.tuna_090501_base.js和tuna_090501_module.js(拆分tuna_090501.js)

  2.数据文件js(1-2个)

  3.频道公用js(1个)和页面私有js(1-2个)

  不含ga.js、uiscript.asp和外链其他网站的js

  b) css文件不超过4个,各频道首页和全站首页不超过3个。

  c) 目前无法解决的是allyes广告的请求数。

  ? 大量的广告和产品图片可能会造成,图片请求数很大,可能造成总请求数指标吃紧,

  这个只能从设计上搞定,需要权衡

  ? 目前老页面可能css和js文件请求数可能会超标

  优化规则- – 优化CSS Spirite

  图片地图 Ctrip首页例子

  优化规则– 避免404错误

  避免内部无效的链接

  规则优化 –不要使用frameset,少使用iframe

  搜索引擎不友好、 即时内容为空,加载也需要时间、会阻止页面加载

  禁止使用iframe引入外部资源,不包括allyes广告,不包括about:blank的空页面。

  第五步、等待响应

  优化规则 --避免重定向

  在重定向完毕并且HTML下载完毕之前,是没有任何东西显示给用户的

  涉及服务器负载、数据查询、服务器端缓存等

  第七步、接收数据

  优化规则 -- 压缩组件

  HTML文档、脚本和样式表、XML和JSON的文本响应 压缩如何工作

  压缩通常能将响应的数据量减少将近70%

  优化规则 -- 精简Javascript和Css

  从代码中移除不必要的字符以减少其大小,减少加载时间。

  规则规则– 尽量缩减页面大小

  页面必须小于150K(不含图片)

  a) 静态文件是否gzip

  b) 图片是否压缩优化过

  第八步、读取Cache

  优化规则-- 添加Expire或Cache-Control

  应用于不经常变化的组件,包括脚本、样式表、Flash组件、图片

  Expires和Cache-Control

  规则规则 -- 使用外部的Js和Css文件

  尽可能使用外部Js和Css,因为我们目前大部分Js和Css都做了Gzip和缓存技术,可以充分利用。

  第九步、处理元素

  不要对image和pdf等二进制文件进行gzip压缩

  第十步、渲染元素

  优化规则 -- 将样式表放在顶部

  界面原型页面必须将样式表置于页面顶部,开发人员如无特殊原因也必须将样式表置于顶部。

  以往多数是因为masterpage原因无法将所有样式表置顶,在改版修改masterpage时,尽可能按照此原则进行设计。

  优化规则 – 建议将脚本放在底部

  一般浏览器可以允许并行下载,取决于主机个数、带宽等

  (默认情况下,IE是2个而FF是8个)

  下载脚本时并行下载实际上是被禁用的。

  优化规则-- 移除重复脚本

  必须为0

  优化规则 -- 避免CSS表达式

  影响浏览器渲染时间

  优化规则 – 优化图像

  尽量使用GIF和PNG

  尽量使用png/gif格式的图片,png的图片优先,但是必须注意如要兼容IE6,则png使用一定要注意透明问题。

  图片在上次前一定要先用工具压缩优化(png、jpg)

  Javascript开发规范

  大型的项目在前端 JS 方面有几个需要达成的目标:

  代码逻辑分层

  避免全局变量

  便于多人协作开发

  各部分代码模块化,可以按需加载

  保持全局变量的清洁

  可进行单元测试

相关搜索

相似文章

网站优化测试,网站前端的性能优化与测试——内容过期 2020-12-29

网站优化免费测试,网站前端的性能优化与测试——内容过期 2020-12-29

优化网站前端页面性能,网站前端的性能优化与测试——内容过期 2020-12-29

前端网站的性能优化,网站前端的性能优化与测试——内容过期 2020-12-29

前端网站性能优化 面试,网站前端的性能优化与测试——内容过期 2020-12-29

前端网站性能优化 缓存,网站前端的性能优化与测试——内容过期 2020-12-29

测试网站优化是那个网站,网站前端的性能优化与测试——内容过期 2020-12-29

前端优化 网站内容,网站前端的性能优化与测试——内容过期 2020-12-29

前端网站的优化,网站前端的性能优化与测试——内容过期 2020-12-29

网站前端优化工具,网站前端的性能优化与测试——内容过期 2020-12-29