网站速度定位

总体思想：

1、找瓶颈法。瓶子的颈部(口子)大小决定了出入量，从而决定了速度。不去改善瓶颈，使劲费力气把瓶子容量扩大，

速度也不会提高。不是什么都去改善就是好的。比如改善带宽，加缓存之类的。但是这些不是目前系统的瓶颈，改善

了也不会发生质的飞跃。所以找到瓶颈所在。

与哲学思想中的：找主要矛盾，解决主要矛盾，问题才会解决的思想类似。放到技术中叫做系统瓶颈。突破系统瓶颈。

 

找到当前的主要矛盾是重要的。去研究代码，获取几毫秒的性能，不如去看看数据库，干掉一条执行超过1000毫秒的语句。

 

遇到速度慢的问题，就想到“多多益善”的思维。把该加的先加了：把数据生成文件缓存啊,数据库加索引，硬件方面内存加，带宽加。

这种加，确实有好处，会改善，但没定位到瓶颈。就不会解决主要矛盾的。

系统的某方面瓶颈没有突破，其他带宽，内存再怎么加，做了观察一段时间后，就发现心里很纳闷了：确实是快那么点点了，但怎么还是没感觉到明显的快哦。有时候反而跟以前一样的慢。很郁闷啊。

 

 

 

2、使用排除法查找问题。这样将范围逐步缩小。避免胡乱猜测。胡乱去测验。导致浪费精力。

大体思路：前端(排查是不是带宽问题,图片、js文件加载是否是瓶颈)》》侦测php执行速度(这一步把问题可以更加精准定位到数据库层面去)》》数据库是否为瓶颈

 

3、以数据或者理论作为支撑。如果靠猜测，以往经验式的判断方式去改善，只会导致做无用功。以统计数据作为支撑比较靠谱。

 

因为网站运行是动态的，时常速度很快，时常速度稍微慢。今天有人反应昨天慢，等到技术人员去实际操作一下子，发现"速度还挺不错啊"，无法还原当时的情况出来。

比如，sql执行时长，php脚本执行速度统计。收集大量在生成环境中统计到的数据。就能很快定位问题所在。

依靠理论作为支撑：比如了解http的请求原理，需要响应，浏览器没有得到服务器的响应(也就是php压根就没执行完毕，所以没到发送html给浏览器这一步)，这种情况在浏览器左下角有明显的特点，显示：正在等待响应。

这种一看，大体可以排除网络带宽的原因。这种判断表面看是基于经验式(经验不可靠，因为网站是动态变化的)，实际上是基于有理论基础支持的。

 

 

 

执行步骤如下：


第一步，编写脚本统计出php执行时长。通过这一步把每次执行时长记录在文本文件中的方式，分析数据发现，排除了

是带宽的原因。理由为：有些地址的php执行时长到3-4s。需要这个时长才能发html结果给浏览器。可想而知速度。于

是瓶颈不在带宽上。假设：php执行的时长是0.xs级别。那么在浏览器看到需要4秒才能看到页面，那可以排除是php执

行问题。将瓶颈定位在带宽或其他原因上。

第二步，进一步编写脚本，侦测是否为数据库速度问题。

具体步骤如下

1、开启mysql服务器的慢查询日志记录。


2、自己编写脚本，将每条执行的sql用了多长时间，记录到文本文件中去。