Home > php教程 > php手册 > 网站性能分析得与失,网站性能分析

网站性能分析得与失,网站性能分析

WBOY
Release: 2016-06-13 08:43:12
Original
1206 people have browsed it

网站性能分析得与失,网站性能分析

###################################

方法与观念的改变

###################################

错误导向:

我在网上会看到人们怎么优化网站,就是用yslow这样的工具来看,工具会告诉你要怎么做,哪方面有问题,比如我写在文档里面的像这样的:

 

 

 

这里会告诉你要开启压缩。

 

 

这里大致反映出时间。

 

这些做法做都是正确的。只是这种都是花俏的工夫。把这些当成是优化的方向,方向不对。着力点错了。结果发现网站速度没明显改善。因为方法错误了。基本是这种想法:先按照上面说的,把该做的做了吧。肯定有提高的。始终没尝试找网站速度慢的瓶颈在哪里?

同学总结得很恰到:这些工夫无非是合并多个js,css文件。该压缩的压缩。能少占用带宽资源。但是都非关键点。去优化关键点,留到后面优化。

 

 


什么是瓶颈?
 
我以前没想到比较通俗的方式解释。通俗点,就是瓶口的大小。瓶子的口子大小就那么多,已经决定了一次只能进那么多量。假如发现一个方面就是限制最大的因素。把这个主要矛盾解决就ok了。假如数据库是瓶颈就解决这个问题,假如磁盘速度是瓶颈着力点就解决这个。
 
一个形象的比方:一个木桶,有一块最短的木板,就算把其他板块加的再高,整体装水不会多。木桶的瓶颈就是最短的这一块。
 
技术上的例子:cpu用得再好,把二核的改为四核,php脚本速度提得再高(装代码加速器,去掉一些模块),apache性能再好,内存提到到8g。数据库优化到再牛逼。网络口子就那么多大,距离这么远,传递的数据量有限。就算你apache在0.01秒就能丢给数据给浏览器。但是网络影响,要请求图片,css文件速度怎么都快不了的。网络是我们目前的瓶颈。cpu速度,内存等等目前都不是木桶的短板。优化在快也改善不了本质问题啊。
 
 一根水管的管道就那么点大,即使你在怎么提高优化其他方面的,虽然有好处。但是仍然没有明显改善。
 

 

性能与优化的分析方法:主次矛盾。技术上就是说找到瓶颈所在。把瓶颈突破,其他问题都不会成为障碍了,整体就能达到预期目标。

 

我亲身经历的一个例子:技术经理是79年的。其实我们的网站访问速度还不错。而老板看到同行的网站网站怎么快些。(人家才多少个技术,我们这么多。应该要达到)。

技术经理把一些方法都尝试了:研究同行的no-cache头,唉,他们的怎么有,而我们的没有。好,我们也要像他们那样做。我们还把代码片段给缓存起来,花了不少时间。可惜,结果速度没有明显提高。有,也只是根据感觉:“哦,我刚才加了缓存控制后,发现服务器的负载低了点。但是怎么又变高了呢。”。“我已经开启了压缩,怎么没明显改善呢?”,其实,加服务器缓存控制,代码判断缓存。肯定是有效果的。但能提高多少?或者说目前这个不算瓶颈。就算你把其他的优化得再好。也没提高整体。没找到瓶颈所在,结果各自方法都试过了。还是没用。白忙活。如果一开始能够分析出瓶颈。着力点完全不同。

 因为不是专业的运维人员,所以,我们不知道怎么去分析性能瓶颈。只是根据感觉,这样做可以提高点性能。先这样做吧。

discuz的人说,“(技术经验)价值连城”。我现在确实有这种感觉,经验就是财富。别人与你非亲非故,干嘛要把经验告诉你呢?我们能看到的仅仅是网上的资料,书籍。这些我发现要形成自己的经验才是关键。比如,大部分建议要apache开启压缩,合并js,css文件。基本上是参照国外人的这本书,我看过:《高性能网站建设指南》。

这上面说的这些都是正确的做法。

由于没人传递一个分析方法。所以,一遇到网站性能问题,往往是先参照网上的,书籍的建议,把基本点做了。然后在考虑对策。比如我经理,仍然是凭着感觉去尝试各种方法。如果一开始就能够分析出瓶颈所在。就不会无效果了。他不是专业的运维,确实也没这方面的分析经验。只能是瞎耗费时间了。试10个方法都不会有突破。

我现在发现,这些都是一些小技巧。谈不上解决瓶颈问题。书的标题就写明了,针对前端工程师的。如果你按照上面的各种方法:压缩js,压缩css。控制缓存。发现自己网站的速度却没明显改善。可能此时你网站的瓶颈在于数据库或者说是带宽,这方面瓶颈没找到,或者不解决,一直感觉不到整体提高。

 

有些人会告诉我:先把基本点,也就是能做得做了吧。然后在考虑其他提高。这其实是道理。

我发现以前我真是这样的。压根就是没有分析瓶颈的一种导向。比如,网站速度很慢,你说,我先把基本点做好:cpu,数据库优化,内存。可惜这些都不是瓶颈。做了确实比不做好。但对问题没效果。

后来发现:做有些事情,确实是要先把基本点做了。然后再去考虑。而有些事情,基本点做了根本影响不大。因为不是瓶颈。找到主要矛盾解决,其他的都不算问题,在慢慢优化

谁都知道做了那些基本点有好处(看书,网上资料),但是有经验的人才会告诉你真实的答案。我经理79年,做了至少8年技术。对于分析瓶颈方面并没有经验,只能是各种方式试一下.不见效果。

 

曾看过阿里巴巴的简朝阳的《myql性能调优与架构设计》,里面分析优化sql,一个思想让我印象深刻:分析一条sql,先分析出瓶颈所在。这样能确定一个预期优化目标。如果没分析清楚,感觉这样能够提高点。就把各种方式都尝试了。结果还是没优化。

我以前还真是这样的:拿到一条sql要优化,我就凭着感觉,这样做会好点,哪怕是能够改善0.001s的速度都行。先这样尝试吧。然后没明显改善,又去用其他方式尝试。如果这样改写下去,几十次都没达到速度提高。尝试得头晕都不会有改善。或者改善了也是碰对了。

比如说:拿到group by,反正根据网上group by如何优化,试一下。其实如果搞清楚group by的原理,对比一下查询的数据量。发现它根本不是sql的瓶颈所在。尝试了等于是浪费时间。

 

我注意到,合并js,压缩是对的,但网易并没这么多,它的js文件内容我打开看,还是原始状态的:

 

 

网易服务器虽然n多,性能非常好,带宽虽然多。合并,压缩js和css都是正确的做法,能提高速度,而他干嘛不做?如果一个事情是一个关键点,他们必须会做的。结论是,他们明白这个根本不是网站的瓶颈所在。纠结这些还不如去纠结关键点。

有些大网站,确实也对js,css压缩合并了。合并js,css确实能够提高。有好处。但我还从没见过靠这种方式把网站速度达到一个质的提高。他们是:先把瓶颈突破,其他基本点后面在做,到时候可以做可不做。影响不明显。

 

 



常常碰到这种的方向错误:

 
比如,数据库去优化,修改字段之类的。虽然能够提到速度,但是在数据量这么小的情况下,竟然速度访问慢。数据库肯定不是瓶颈,这方面的改善无法都无法解决根本问题.结果速度还是慢。
 
 
比如,网上一直流传php的代码性能差异之比
例子1:
echo $a.$b.c;
 
有人认为这样写性能更高(确实是,省去了符号.进行逐次解析):
echo $a,$b,$c;
例子2:
 
echo "this is {$tile}"
优化成:'this is'.$title;//把变量放在""符号之外,是可以省去解析时间
 
无法说上面的优化是错误的,而且确实要承认那样去优化性能会更高。但是真的要问,到底性能高多少呢?高0.0001s,这种优化有改善,但意义多大?
 


这种优化压根就谈不上瓶颈。假如:php把10万条数据一次读入到内存,发现卡死了。这就是php代码处理的瓶颈(实质上是内存问题),此时优化代码逻辑就可以解决根本问题。少操作些数据ok。想把内存提高不靠谱。


 纠结,细扣一些花俏,影响不关键的方面。总不会有多大改善的。网上经常提到那种,php代码优化的10个方法。人人奉为圭臬。扣得太细了。当瓶颈不在这里的时候,优化不了多少。


php代码的这种优化,我以前也是去纠结过。但是后来发现,没有找到瓶颈所在,所做的工夫都是白费的。
别人其实也犯这种错误。
我遇到这样一个例子:我以前上面分配一个优化后台某项统计数据的查询。但是因为不懂得抓瓶颈问题。没有明确的方向,我大体方向只是在优化sql查询上做改善。其实方向是对的。瓶颈确实是在数据库方面。但数据结构设计,再好硬件,sql优化再好,统计查询都快不起来。
折腾了很久,同排一同事想帮助我,他的方向完全不同,他的着手点也是改善php代码:他把php处理的循环方式改善一下,比如原来是怎么循环的,改成另外一种循环方式。其他代码也进行改善代码。
其实通过这个事情,我发现没有理解瓶颈所在,就在那个时候我明白了:同学告诉我,php的处理速度已经非常快了。整体看执行时间慢,它是一直在等待数据库给予数据。所以脚本就很慢了。所以那么大的数据查询统计,也许像上面例子那样去改善,纠结一些次要的东西。无论怎么优化代码,都解决不了统计查询速度慢的问题。着力点要搞清楚为好。
 

 
服务器的php程序执行速度非常快,执行完后就发送数据了。服务器在美国,假如在中国访问,距离这么远,再快也快不到哪里去的。

也许就有疑惑了。这个网站也是在美国:http://digg.com/

怎么访问速度那么快?

这个网站他肯定在中国部署了服务器的。比如阿里巴巴想保证全国各地的用户都能访问他网站。他如果把服务器全部放在杭州,或者全部放在北京。南方的人访问,光是距离也要那么远。根本不会有现在这个速度。所以,距离如果远:服务器本身性能再高,速度也快不到哪里去。所以先把脚本的执行时间统计出来,这样便于确定服务器消耗。
 
ps:有那些cdn加速服务需求,单双线机房之分。就是通过解决距离远,时间延迟上的问题。
 
我在英国,访问美国服务器。能快起来吗?
看这个博客:blog.strabbit.com,服务器是美国的一个vps。看在中国访问速度如何?
 
网站的访问速度是一个多方面导致的因素。
 
我首先会去判断程序执行的性能方面。做一个严格的执行时间统计。这么做的作用是:确定瓶颈在数据库响应数据,还是在程序执行性能, 还是在网络带宽因素?
我放一个统计脚本也是想统计出程序每次执行的准确时间。

统计的机制是这样:

在程序执行开始执行时记录一个时间,结束的时候定一个时间。结束时间减去开始时间。就是php脚本所执行的时间了。在并发访问不多的情况下,脚本的执行时间会在稳定范围内。

 

 


这样做也是根据一次请求执行的原理来的:
1、浏览器进行http请求
 
2、apache处理:
if(请求的为php脚本)
{
 
apache丢给php引擎处理
php执行生成html给apache,nginx等服务器》》
 
}
else
{
图片,静态html页面,js等静态内容.
直接从磁盘读取文件结果给浏览器
}
 
 
3、apache将html结果通过网络发给浏览器。浏览器解析html,渲染出结果给用户看。


 
 把这个过程搞清楚了。定位问题就不会错误去估计:统计出php脚本时间。就明白apache多久才从php拿到html结果。

 


php程序的总时间大体反映出了:php向mysql获取时间,和本身执行所花费的时间。 
我注意过一点:php连接mysql请求数据。如果mysql负载高,响应不过来。那么php程序就会处于一直等待mysql返回数据状况(这就是时间耗费,常常导致在浏览器请求页面的时候速度很慢)。
 
所以,为什么首先要统计出php的执行总时间了。假如:我请求index.php页面,统计出php的脚本执行时间才0.05s(秒)。但是偏偏在浏览器访问的时候,发现速度慢的不行,一直看不到结果啊。根据上面的http请求过程和apache,php之间的关系。php脚本生成html结果早就给apache了(这个时候已经完全脱离php处理,php处理引擎任务完成,我只负责查询数据库最后生成html而已。执行到这里的时候如果速度快.已经脱开数据库性能,php脚本性能了)。


而index.php返回的html内容中可能包含其他http请求。像这样的元素:


,
 
 
 
 
浏览器渲染apahce返回的html结果后,如果遇到像上面的标签,浏览器就会继续像服务器请求文件。 
 
html结果早就能得到了。而我们看不到结果,因为数据没有传送完毕,服务器已经完成他该处理的事情了(处理完正在发送数据了)。网络状况的话,与服务器性能有什么关系?所以经常发现这样的情况:

图一

 


 图二

 


浏览器请求的时候,左下角一直显示“正在传送数据“。其实此时php解析早就完成了(此时稍微注意,偶尔查看浏览器源码。往往发现能够看到html结果了,前提是html通过网络已经完全传到浏览器端了)。或许网络原因,一直停留在服务器与客户端发送数据过程耗费时间。

 

如果显示"正在等待响应....",那说明服务器还没有给数据给浏览器。可以做个试验:

用个php文件,代码里面循环10万次。看浏览器怎么反应

for($i=0;$i

for($j=0;$j
}

}

 

搞清楚http请求的过程,定位就容易点。

第二张图片:一直没看到结果。页面一片空白。能说是服务器性能不够好吗?能说瓶颈是要优化php脚本吗?其实这个时候也已经生成好html了。服务器正在给客户端发送数据,网络原因,延迟。

 
浏览器左下角:有时候显示的是正在连接网站,可以分析出的意思不同。我常常遇到数据库大数据量的时候,一条sql查询了很久,响应出现问题,所以php就一直在等待数据。那么apache,nginx根本没得到php的处理结果(也就是说php脚本耗费时间太多,根本没执行完)。此时在浏览器看到是”正在服务器等待响应"。 
 
脚本的执行时间大体上是固定的变化不会太多。所以能够通过在php的开始的和结束的定时间参考php脚本的执行性能。 
但并发访问越多,脚本的处理速度就越会受到影响: 
php脚本的执行时间统计往往能够定位脚本处理,数据库性能方面问题。比如,并发访问大的情况下,假如1000个并发(如同时在0.001秒刻进行访问,网站用户多的时候,这种情况经常碰到,测试时是通过压力测试工具才模拟得出来)。 
运维常常设定一个类似于这样的预期目标:模拟在10000并发的情况下,看看服务器负载情况,脚本响应时间要控制1s之内。而在浏览器要保证2s以内看到整个页面(页面的附带请求忽略掉) 
 

 

 

 

 


 
 
  ##########################################
 分析结果
 ##########################################
 
 
 
 
对浏览器http请求,apache处理,php,mysql之间的关系越了解就越能确定原因所在。
 
注意到没有:hairextensionsclipon.com,ebesthair.com这两个网站都是加了php代码加速器的.平均每次页面的执行的时间是0.2-0.8s之间。但是如果发现,在
 
浏览器是等待了4-5秒才完整显示出结果的话。
就把这5秒减去0.8s。就能知道时间花费在哪里了!能够大致预估的。
 
 
可以做一个试验:把首页保存成一个静态html文件。放到服务器上。然后在中国直接访问这个静态html。
这样做的依据:静态html是完全不需要php解析,数据库消耗,这就可以把解析时间排除掉(我做php统计执行速度也是想做参考)。apache拿到静态内容直接发给了浏览器。所以可以完全测试出网络传输速度如何!
 
要逼真的模拟,可以这样做:打开首页》》查看浏览器源码。把源码保存起来成一个html文件。
这样做的好处是,这个静态页面,其中也就包括一些js,css,图片的加载。完全逼真模拟。
 
 
我们常常看到:访问一个网站。浏览器已经显示出html效果了。但是布局却是乱的(没有css效果的那种,实际上就是css文件没加载完)。或者图片位置是空的。
 往往需要等上一段时间页面布局正常。什么原因?
 
这里能够确定:html页面结构(一个完整的html代码,并不包括src属性要载入图片和js文件内容,style标签要载入的css文件等)已经通过网络完全发送到达浏览器。浏览器已经正常的解析了!只是style标签要载入的css文件还没达到而已。网络速度延迟了。php要做的事情就是上面这一步:它给apache的结果就是html,apache会发给浏览器解析,浏览器解析才看到了最终的效果(所以js文件,css文件只要已经网络传输到浏览器端,执行都是耗费客户端内存,cpu资源了)。
 
根据浏览器的解析原理:比如访问首页,浏览器拿到apache发给它完整的html代码。才会进行解析,渲染出页面的基本结构。是先渲染出整体结构,然后才会去加载页面中需要的css文件,图片,js文件。


 
      所以这里就里问题就出来了:即使你网站的处理速度快到0.1s。但是带宽不行,或者我这边网络速度慢,仍然会出现,浏览器一直显示“正在在传送数据”。这个时候说明,php早就已经生成html结果给浏览器了。通过观看浏览器的表象就能大致确定哪一段才是瓶颈所在了。比如,我曾经遇到下面情况就不是网络原因:
 在浏览器访问一个自己写的php脚本,该脚本要对一个数据库的数据进行更新。数据量太大了,php执行时间很长。浏览器会一直显示,正在等待响应,这个时候,连数据都没传递到浏览器。就是因为:php一直没处理完,没有给apache结果,apache也就一直等待中了。
 
 
 
 
我的建议是,apache缓存控制,js,css压缩都是可以做的,这些确实可以占有网络资源.但是这个放在后期去做。因为就像木桶一样,你再怎么做其他方面,忽视短板是无法提高的。结果速度还是慢。不信可以尝试.现在你再怎么提高,都突破不了网络的限制。带宽只有那么多。如果在中国访问,这么远,怎么都快不了。
 
我观察和分析了几天,瓶颈就是:网络原因(包括了带宽,距离远访问)。网络的速度最终影响了数据达到客户端的耗时。
硬件:包括cpu,内存方面不是瓶颈。即便弄台独立服务器也是一样的.
数据库:几百万条数据,如果是查询单条商品都是0.00x秒级别的(因为是索引关联速度很快)。我们才几百条商品数据,数据量小的可怜.查询慢不到哪里。分析认为不是瓶颈。
 
程序:magento往往给人一种运行速度慢得像乌龟的印象。所以会错误认为这是瓶颈。把模块优化一下。magento在本地电脑确实慢,统计的时候执行了5s-6s。但是pc机子与服务器硬件配置上是不同的:
其实,cpu的处理速度很快,内存的速度已经非常快了。一般性能最大瓶颈就是i/0能力(磁盘,这也就是为什么需要memcached之类的东西)。磁盘的读取数据快慢起到决定作用,延迟.尤其是大访问,并发访问的时候影响就更明显了。服务器的硬盘转度比pc快很多。一般为10000转/分钟-15000/分钟。pc机一般5400/分。转速越快,i/0能力就越好,给用户反应就是拿数据越快.
所以,统计发现,magento放到服务器上,往往执行时间很短了.虽然服务器的cput,内存比pc机都要配置高。但并不是因为cpu,内存的缘故而速度快.
注意到没有,加了代码加速器脚本执行时间很短了.包括查询数据库到最后给html给apache。总时间不超过1s(有时为0.2s)。如果再优化确实有空间。但为后期做的事情。不是解决速度的瓶颈。
 
 
 
方案:
 
一,主机距离部署近点访问客户所在国家。针对英国客户为主的,购买主机就一定要部署在该国。部署在美国怎么访问都快不了。浪费财力。
 
我们访问digg.com,其虽然在美国,但是速度快。那肯定是在中国附近部署的服务器(cdn加速服务)。很多国外网站是在新加坡部署。
 
 
二,提高带宽资源。向空间服务商加钱就可以加带宽。
关于这点,如果主机部署较远,即使你带宽再多,恐怕不会快到哪里去:
国与国之间的网络肯定要比本国内各个省份之间的网络繁忙得多。毕竟是一国所有向外数据的通道。比如中国与美国网络通信,是通过东部海底光缆联系的。意味着整个中国通向美国的数据访问都是经过同一道线路的。
 
 
三、服务器在美国,美国人也访问慢的话。与这种情况类似:假如在南方城市长沙,访问服务器在北京的网站。速度慢往往是距离远的导致传输数据时间变长导
 
致的。因为在并发量不大的情况下(我们网站的并发访问量小之又小),php脚本执行的的时间是稳定的范围.所以,与服务器性能关系不大.
如果考虑购买cdn(内容分发)加速。在临近用户访问地部署节点,图片,css,js进行。虽然有效。但经过综合权衡,问过一个有经验朋友,这样做还不如把钱投入到带
 
宽增加上。这样花钱也花在刀刃上为好。
 
 
 
 
附:总结的测试网络带宽速度的技巧
 
 
一、看ping值。快的一般是几十毫秒。
 
二、丢一个文件,静态文件,放到服务器上。打开浏览器访问,看下载时间。
 
比如,放一个100m的文件放到vps上,直接下载,看每秒多少k的速度。
 
一般一个网页预算200k。按照每秒多少k计算,就能确定一个网页网络达到客户端需要多长时间。实际中是要加上服务器脚本的执行时间。
 
 
三,因为我在中国,访问美国的vps肯定受到网络距离的影响较大。假如客户是美国人,如果想测试美国人访问自己的vps速度如何。通过一些工具网站的测试工具往往不靠谱.一要保证该网站与vps在同一国.不能工具网站在加拿大,而访问美国的vps.跨国了,这种方式无法得到真实可靠的数据.
可以准确测试的方式:登录到所在某国所在电脑的远程桌面,然后在远程桌面上访问vps上的网站,看用了多长时间.
 
或者:一台服务器在a国,取一台a国所在的另外一台vps,在vps上写一个php脚本去vps上下载数据,统计时间长短.也可以使用shell命令,wgets,会告诉你网页传输总时间。

Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Recommendations
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template