当前位置:首页 » 网页前端 » web响应时间
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

web响应时间

发布时间: 2022-10-04 12:35:54

❶ Web响应时间很长

错别字太多
Web响应时间很长无非几个方面的问题:
1.主机硬件低配而装了高配操作系统,比如win7,小马拉大车喽
一般属这种情况的话,运行大多软件都会慢,如果运行别的软件不慢,仅是web慢,skip这一条,看第三条.(新买的东芝笔记本电脑,估计配置应该还不错吧,可以看下一条了)
2.主机内软件安装的不合适,比如中病毒了、或者是安了几套杀毒软件(同时安装)等等原因,系统CPU被这些软件过度占用,如果这样,杀毒、卸载不必要的软件。
比如360,就建议停用一下,看看是否响应速度会变快。
3.如果前两条都不符合,则问题集中在web方面,
3.1所访问的具体某个网站慢,判断很容易,看看访问别的web速度快不快,如果有快有慢,那问题可以结题了。如果都慢,请看下一条。
3.2检查下DNS设置的是否合适,建议选用与你上网线路较近的DNS

❷ 如何用soapui测webservice的响应时间

如何测试写好的Webservice?你当然可以写代码来测试,但还是太麻烦,你得花时间去学习各语言的关于Webservice调用的相关API。这里推荐一个Webservice开发的必备工具-SoapUI,无须了解底层细节,就能快速测试你的Webservice开发的是否正确。

SoapUI是一个开源测试工具,通过Soap/HTTP来检查、调用、实现Web Service的功能,而且还能对Webservice做性能方面的测试。


SoapUI下载地址:http://sourceforge.net/projects/soapui/files/

(SoapUI也有收费的Pro版本,对于一般的开发人员来说,如果只是调试下,开源的免费版就足够用了)


Demo

首先新建一个SoapUI Project,在Initial WSDL/WADL中输入wsdl的地址


只是对SoapUI 做了简单的介绍,主要用其来查看web service提供的接口,以及返回的结果,SoapUI的功能远不止这些,其可以对web service进行功能上和性能上的测试。

SoapUI的参数说明:http://www.soapui.org/Working-with-soapUI/preferences.html

进一步了解可以阅读:http://www.51testing.com/ddimg/uploadsoft/20100204/SoapUI.pdf


另外分享几个公开的Webservice站点,你可以随便招几个服务来测试

http://www.webservicex.net/WS/wscatlist.aspx

http://www.service-repository.com/

http://www.webxml.com.cn/zh_cn/index.aspx

❸ 用loadrunner测试web页面,响应时间看不懂,求助

loadrunner中的响应时间一般只是指客户端和服务器端交互的时间,不包括客户端展现的时间。

❹ redis 关闭 bgsave 后整个 web 响应时间提升 5 倍,这是个坑么

那个是把内存数据保存到磁盘的持久化设置。你关闭了,redis不去做这个工作当然会提高响应时间(同时说明你redis保存的数据有点多)。只是你要做好数据的安全工作,万一服务崩溃了你没有rdb文件备份,无法恢复数据了。

❺ javaweb系统设计计算浏览器响应时间

写一个filter过滤器计算就行,request来的时候记录一个时间,response的时候记录一个时间,然后就能计算出浏览器相应时间了

❻ 怎么用PHP获取PHP执行服务器访问外部WEB的时间(响应时间) - 技术问答

你说的访问外部WEB是什么意思?不是很理解,可以看看简单的执行时间计算$start = microtime(true);file_get_contents(\' http://www.qq.com\');$end = microtime(true);$timePass = $end - $start;深空 发表于 2009-7-28 19:40[i][/url][/b]就是测试站点到被访问的WEB服务器的响应时间!

❼ Web服务器性能和站点访问性能该如何优化

今天小编要跟大家分享的文章是关于Web服务器性能和站点访问性能该如何优化?正在从web前端工作的小伙伴们来和小编一起看一看吧!

一、优化思路浅析


要优化Web服务器的性能,我们先来看看Web服务器在web页面处理上的步骤:


1、Web浏览器向一个特定的服务器发出Web页面请求;


2、Web服务器接收到web页面请求后,寻找所请求的web页面,并将所请求的Web页面传送给Web浏览器;


3、Web浏览器接收到所请求的web页面内容,并将它显示出来。


上面三个步骤都关系Web服务器,但实际Web服务器性能相关最大的是在第2步,这里Web服务器需要寻找来自浏览器所请求的Web
页面内容。


我们知道,Web页面内容有静态的,也有动态的,静态的内容,web
服务器可以直接将结果发回给浏览器,对于动态内容,则通常需要交给应用服务器先处理,由应用服务器返回结果。


当然,也有Web服务器本身可以处理动态内容的,例如IIS就可以自已解释处理ASP,ASP.NET这两种微软的动态网页脚本语言。


从上面简要的分析里,我们大致可以得到这样的结论,影响Web页面访问的影响因素会有这几个:


1、Web服务器从磁盘中读取静态页面内容的速度,也即时间;


2、Web服务器判定请求内容是静态还是动态内容的时间;


3、Web服务器转发请求给应用服务器的时间;


4、应用服务器处理(解释)动态内容所需的时间;


5、Web服务器返回Web内容给浏览器的响应时间;


6、Web服务器接收来自浏览器请求的处理性能;


7、Web访问请求数据在网络上传输的时间:包括从浏览器到服务器,和从服务器到浏览器两部分;


8、浏览器本地计算和渲染Web内容的时间,即接收内容后展现内容的时间。


上面8项很容易理解,也很直接,其实还有以下几项也是关乎Web
页面访问速度体验的因素,你可以思考下是否如此?或者说是否会影响到页面访问性能。


§Web服务器执行安全策略检查的时间,或者说性能;


§Web服务器读取日志文件、写日志内容、关闭对日志文件访问的时间,先读后写再关闭,这三步中的读与写又涉及到磁盘访问性能因素;


§同时与Web服务器连接会话的客户端数量大小,即并发访问量多大。


我们可以将上面的影响因素抽像出来,那么就是:


1、Web服务器磁盘性能;


2、Web服务器与应用服务器交互的性能;


3、应用服务器处理动态内容的性能,或者说动态内容应用处理性能;


4、客户端与Web服务器的连接速度,即网络传输性能;


5、Web浏览器解释和渲染Web内容的性能;


6、Web访问并发性能。


反映到我们进行性能优化,可以入手的角度就有:


1、增加带宽,包括服务器和客户端两边的Internet连接带宽;


2、加快动态内容的处理性能;


3、尽可能多地使用静态内容,这样Web服务器就可以无需请求应用服务器,直接将Web内容发给浏览器端,这里可以入手的方案又有:


动态内容缓存


动态内容静态化


多台服务器负载均衡同时处理大量的并发访问;


提升服务器磁盘访问性能,也即通常所说的I/O性能;


减少网页中的HTTP请求数;


更换更好性能的Web服务器;


合理部署服务器,在离客户端更近的地方部署服务器,已经证明可以明显地提升访问性能。


二、性能优化实践


经过前面小节的简要分析,相信你对优化Web服务器有一定的思路了,你可以从硬件层面、软件层面、Web代码三个层面去优化。


下面我们结合一个具体的实例来实践一回,本文所举例是一个小型的Web
站点,部分数据系假设,如有类同,纯属巧合,仅起抛砖引玉之用。在实际工作中,如果碰到大站点,你可以参考此处的分析,修改优化方案。


1.站点简介


一个社区论坛站点,采用Discuz!论坛程序构建,该程序采用主流的PHP+MySQL组成。


网站目前有近5万注册用户,绝大多数是国内的用户,活跃用户数在一半左右,每天平均PV在15~20万,独立访问IP数在8000
左右。


2.Web服务器性能优化需求


网站现部署在国外的服务器,租用虚拟主机来运营,因为访问量比较大,所以经常会收到虚拟主机服务商的流量很大的通知,要求控制下访问量。


另外,虚拟主机的服务器在美国,没有在国内租用虚拟主机的原因是国内网站在备案方面非常繁琐,在网站一开始运营时数据量和访问量都比较小,所以对性能要求不高,数据量小,所以服务器在查询处理数据时速度比较快,也让人感觉访问速度不慢,现在随着数据量和访问量的不断上升,访问速度已明显下降,到了需要改善访问性能的时候了。


基于目前该社区网站的情况,提出的优化需求是,国内访问速度需要提升一倍,目前首页加载时间需要40秒左右,希望优化后能在20
秒以内将首页加载完成。


另外提出网站数据能够每天自动备份一次,备份数据保留一个月的,以便随时恢复。


上述两点需求,其中第一条才是性能优化需求,第二条是额外的需求了。


3.性能优化方案


根据其网站的现状和优化需求,结合自己的经验,加上谷歌的搜索,同时与网站主不断确认沟通,最终得到以下性能优化方案:


由虚拟主机部署改为独立服务器部署


虚拟主机受限比较多,无法自己自定义配置Web服务器,无法配置PHP
动态缓存,而且独立服务器可以独享内存、处理器资源,不再受虚拟主机商对每个虚拟主机用户的内存和处理器资源占用限制。处理器资源和内存资源,对接受更多并发访问有直接性能提升效果。


独立服务器,我们选用Linode2048型号,2G内存,4核处理器(Linode所有VPS都是四核处理器),80G硬盘空间,800G
网络流量。


由Windows操作系统改为Linux操作系统


网站使用的是PHP+MySQL程序,PHP在Windows下的性能,受限于IIS需要通过ISAPI形式调用PHP,所以性能不如
Linux下Apache直接通过PHP模块解释PHP,更不如Nginx与PHP-FPM
的性能,既然使用了独立服务器,操作系统也可以自己确定,Linux系统我们选用了熟悉的UbuntuLinuxServer10.04(一年前还没有
12.04),^-^。


Web服务器采用Nginx,而不使用Apache


选用Nginx而不用Apache的原因非常直接和干脆,因为站点里有很多静态的附件文件,在处理静态内容上,Nginx性能是Apache
的差不多10倍。


在PHP解释和伪静态规则方面,Apache要比Nginx强,但这不影响我们放弃它,为缓解这一点,我们在后面对PHP
进行了动态缓存。


对PHP查询进行动态缓存,使用eAccelerator这个加速器


PHP加速器是一个为了提高PHP执行效率,从而缓存起PHP的操作码,这样PHP后面执行就不用解析转换了,可以直接调用PHP
操作码,这样速度上就提高了不少。


eAccelerator是一个开源PHP加速器,优化和动态内容缓存,提高了PHP脚本的缓存性能,使得PHP
脚本在编译的状态下,对服务器的开销几乎完全消除。它还有对脚本起优化作用,以加快其执行效率。使得的PHP程序代码执效率能提高1-10
倍,这个加速还是非常明显的。


具体地,我们计划对eAccelerator进行以下设置优化:


§缓存使用物理内存来进行,不使用磁盘来缓存。我们知道内存的读写性能是硬盘的N倍,所以在内存资源可以安排情况下,强烈建议使用内存来保存
eAccelerator的缓存内容。


§缓存大小设置为32MB,这个值是操作系统默认支持最大的缓存容量。虽然可以通过修改配置文件来加大这个值,但我们觉得没有必要,所以就放弃了。


Nginx性能优化


选用了Nginx,虽然它的性能很好,但我们仍然需要对它进行性能优化,在这个案例中,我们做了以下优化:


§使用8个进程,每个进程大约需要20M内存消耗,这里一共使用了150M左右的内存。


§充分使用主服务器的CPU内核:四核,使用CPU粘性配置选项(worker_cpu_affinity),每核处理器分配两个进程。


§开启gzip压缩功能:gzip压缩对JS,CSS,XML压缩效果非常好,能压缩一半,即减少一倍的传输时间;对图片文件,JPG
已经压缩过的,它的压缩性能要少一些。


§图片本地缓存1天:网站上的图片很多,通常一张图片上传后,不会频繁的修改,只会频繁的访问,所以将图片放在Nginx
缓存里,可以减少服务器访问加载次数,提升访问速度。


§JS、CSS文件本地缓存7
天:这两种网页文件,平时都不会去修改它,将它缓存起来,可以减少加载次数,提升访问速度。为什么这两种文件不和图片一起设置缓存有效期,是考虑了不同文件的修改频率不一样。


§Nginx日志每天切割一次:这个优化项能大大减小Nginx日志文件的大小,经过一周的查看,每天的日志文件是50M
左右,如果不是每天切割,用月切割,那一个月的日志文件就是几个G,要Web
服务器在内存里加载这么大的文件,系统本身内存不够用,就自然会用到磁盘来缓存,这就影响性能。每天50M左右,在内存上完全可以顺利加载,这样Nginx
在处理访问时,可以快速的保存访问日志。


经过上述几个优化项目,Nginx这边一共需要占用200M左右内存资源。


对PHPCGI进程性能进行优化


Nginx没有PHP模块,所以它对PHP的支持是通过PHP-FPM来实现的,PHP-FPM
是跑进程来处理并发请求,在这个案例中,我们配置了20个进程,每个进程差不多占用20M左右内存资源,一共是400M左右。


同时,PHP-FPM与Nginx交互机制,选用LinuxSocket模式而不是TCP协议端口,Socks是系统级处理模式,socks
也就是一个文件连接,而TCP协议端口,需要经过网络协议处理,性能不如前者,所以我们选择了前者。


MySQL数据库性能优化


因为网站主程序是选用他人开发的开源程序,所以对数据库查询的程序优化我们无法处理,只能从MySQL本身寻找突破口。


我们可以想象一下,对于论坛网站,通常看贴、查贴的访问量要远大于创建贴子、回复贴子的访问量,体现在MySQL
数据库上,就是读表与查询表数据的连接处理更多。


因此我们要选择对读表、查询性能更好的存储引擎,结合以前了解的知识,MySQL缺省的MyISAM
引擎就是被设计为适合处理读频率远大于写频率的环境,查询效率相当可观,而且内存占用很少,这也与我们租用低内存配置的VPS相符。


具体到MySQL配置参数的优化上,受限于服务器上内存资源本身有限,就直接采用缺省的中型环境配置文件。


内容分发网络应用


站点每天十多万的访问,上万独立IP
访问,查看先前的访问统计,访问来自国内各个地区,使用多种网络连接访问进来,为保证来自各网络的用户访问速度,同时也减少对网站服务器的请求,我们采用了CDN
来分发静态内容,这样各地的用户可以就近访问到已缓存在CDN上的文件,CDN
服务商会在静态内容第一次访问时缓存到他们全国各地的服务器上,当第二次访问时,用户实际是没有连接到网站服务器上获取文件的,而是直接从CDN
服务器上获取,可以明显的提升网站性能。


以上就是小编今天为大家分享的关于Web服务器性能和站点访问性能该如何优化的文章,希望本篇文章能够对正在从事web前端工作的小伙伴们有所帮助。想要了解更多web前端相关知识记得关注北大青鸟web培训官网。最后祝愿小伙伴们工作顺利!


❽ 如何定位Web应用响应慢原因

运用听云Server解决Web应用过程响应慢,并且定位到具体代码,我们首先登陆听云Server控制台,点击需要查看的应用,进入Web应用过程模块。(听云Server中Web应用过程指:应用程序中处理一次独立的Web访问请求的过程,完整的web应用过程是从应用程序收到请求到响应的整个过程)

Web应用过程功能模块是将当前应用以Web应用过程的维度来展示详细的应用性能数据,包括以下几个功能:
“Web应用过程一览”列出当前应用所有的Web应用过程,并且可以按照耗时百分比、响应时间、吞吐率、Apdex、错误率进行排序。

“TOP5最耗时Web应用过程堆叠图”展示了耗时百分比最大的前5个Web应用过程其墙钟时间比在选定时间内的变化趋势。(墙钟时间比指的是Web应用过程在图表横坐标粒时间度下的总耗时时间/图表横坐标粒度时间)

“Web应用过程响应时间与吞吐率图”展示了应用的平均响应时间和每分钟请求次数在选定时间内的变化趋势。当请求的响应时间大于设定的阈值时会被显示在慢应用追踪列表中。(可在设置中对Web过程跟踪阈值进行设定,例如设置为500毫秒,那么所有响应时间大于500毫秒的请求都会被显示在慢应用过程追踪列表中,具体值根据自己的需求设置即可)

对于Web应用过程响应慢,我们选择按照“响应时间”进行排序,响应时间由长到短排列,选择时间较长的优先进行解决。
点击该Web应用过程进行数据钻取,查看其详细的性能分解。可以看到Web应用过程性能分解堆叠图,显示了这个Web应用过程中各个组件在选定时间内的平均响应时间的变化趋势。

“性能分解表格”展示了其中各个组件的详细性能信息,包括的信息有代码段、性能分类、耗时百分比、调用次数、平均响应时间,排列顺序是按照平均响应时间由长到短进行排序的。

“响应时间和吞吐率图”展示了该Web应用过程在选定时间内平均响应时间和每分钟请求次数的变化趋势。
“慢应用追踪列表”显示了该应用下响应时间大于设定阈值的请求,同样还是按照响应时间由长到短进行排序。

点击其中响应时间较长的请求进行慢应用追踪,跳转至应用过程慢追踪页面。
摘要中可以看到各个组件的响应耗时百分比图,下面还列出了各个最慢组件详细的调用次数、持续时间、响应耗时占比数据。

接下来重点查看追踪详情,可以看到各个代码段的持续时间、时间占比和时间偏移量,其中持续时间长时间占比高的就是响应时间长的代码段,则需要对该代码段进行重点的优化和修改,从而解决Web应用过程响应慢的问题。

后面的相关SQL展示了其中的SQL操作以及其调用次数和总耗时。
拓补图展示了相关的调用关系方便更加全面的分析问题,特别说明的是只有发生跨应用调用的应用过程慢追踪才会展示拓补图。

❾ web服务器的性能指标有哪些

web服务器常用性能指标如下:
【吞吐量】
固定时间间隔内的处理完毕事务个数。通常是1秒内处理完毕的请求个数,单位:事务/秒(tps)。
【响应时间】一次事务的处理时间。通常指从一个请求发出,到服务器进行处理后返回,再到接收完毕应答数据的时间间隔,单位:毫秒。
【CPU占用率】1-CPU空闲率,表示CPU被使用情况,反映了系统资源利用情况。

❿ 如何:在 Web 测试中设置页面响应时间目标

这称为“响应时间”。 创建 Web 性能测试时,可以为 Web 性能测试中的每个网页请求设置“响应时间目标”。 仅当可以在该目标所指定的时间内检索到该页以及该页中的所有从属请求时,才认为满足请求的响应时间目标。