如何发现系统的问题
用户总是反应网站访问速度慢,那么如何发现慢在哪里,为什么慢,如何改进呢?根据我们的架构,慢的原因可能有
1:web 前端服务器和用户之间的带宽小。拥堵,丢包。
目前采用了电信网通的双线服务器,智能DNS解析,保证了大部分用户能够就近访问。
当然如果有CDN加速那么更好。如果对此有疑问,可以从前端web server的log中来分析,找出访问慢的用户的比例。研究访问时间长的出现情况
2:页面加载反映慢,比如js加载过多,浏览器之间的不兼容。页面图片过大等等
这部分需要前端优化,需要综合UI和速度来平衡。
3:后端web应用server以及应用服务器的响应和处理速度慢
后端我们采用nginx+webpy来构造我们的webmail。那么通过分析nginx的日志,可以发现一些服务器响应慢的痕迹
比如,分析各种不同状态码的比例,200,404,400,413,502等状态出现的频率,设法消除400,413,502的数量。
根据每个请求的平均消耗时间来分析服务器的性能状况。
根据监控软件监测到的带宽消耗状态来评价服务器的带宽是够够用
根据系统的负载状态来评价服务器是否出现CPU处理速度不足,I/O瓶颈等
4:根据错误日志的分析来发现一些异常情况,比如无法登录邮箱,部分页面打不开。部分功能异常等等。
5:用户行为分析,通过对日志的统计,分析,对大部分用户的行为进行研判,分析用户的行为,找出异常行为的用户,比如机器人注册。机器人灌水,机器人发帖,机器人发信,对这些异常行为进行手工处理,并设法在程序上进行改进,阻止这些少量用户对系统资源的过度占用。
6.数据库的优化,对动态内容来说,数据库的负载是相当重的,对应用程序的合理优化,能够有效的减少对系统资源的需求。
从易用性的角度来看,我们编写程序总是希望越简单越好,我们的理想是硬件的性能是无限的,我们只需要让计算机去做我们想要的事情即可。可是现实是残酷的,当用户数量到达一定程度,就出现了性能瓶颈。原来的那种简单的对数据的处理方式开始出现了问题。因此我们需要进行优化。设法找到在性能和程序复杂度之间的平衡。
比如sql语句,最早在写出很多被我们某些高手嘲笑的语句之前,是没有想到会出现问题的。每个新手都会写出这样的东西来。当我们在实际情况中发现这样行不通的时候,我们会想到去改进,
我们的问题在于,如何去定位问题出在哪里,假设我们认为是数据库的问题,我们该如何去定位,究竟是哪个sql语句导致了系统负载巨高呢,对于mysql来说,我们可以打开慢查询,通过慢查询的log来看到,是哪个sql语句占用了过长的时间。
当我们在单台服务器上再也无法突破性能瓶颈的时候,我们想到了集群,那就是集合多台计算机的力量,于是有了负载均衡,于是有了分布式运算系统。
有了好的想法,依然需要解决很多问题。如何让数据按照正确的路径在不同的服务器之间流动,而不是无序的在服务器之间乱窜。否则的话,用户访问的时候将会出现莫名其妙的问题。
采用负载均衡以后,如何保证一个合理的调度机制,让每个服务器都能为集体出力,做到尽自己的能力,而不是一部分服务器累死,一部分服务器闲死。
还需要考虑的问题就是,数据的同步性和一致性问题。如果一些用户看到的是今天的内容,另一些用户看到的却是昨天的内容。这是无法忍受的。一致性问题比同步性问题更重要,如果两个用户同时修改同一个数据,会导致数据不一致。那么两个用户看到最后结果就完全相反了。
以上我说了这么多,可能会有用户说,你说了那么多,具体怎么做,你一句也没有呀。是的,我之所以没有去说具体的问题,是因为世界是复杂的,每个具体的细节问题的具体情况都不同,需要我们的分析和判断。但是从大的原则上是一样的。如果我们只是局限在枝节上,虽然我们解决了一个又一个问题,却永远是在就事论事,一旦大环境出现了变化,那么可能之前的经验和结论就毫无用处了。
从大的方向去定位问题,从小的方面去分析问题,最后找到解决问题的办法。
以前总在想,架构师是怎么做上去的,其实,你把刚才我提出的问题,从实践的细节到全局的理论,一旦形成了一个体系,你离架构师的距离,就不远了,路是一步一步走出来的,没有一本书可以直接让你速成,所以《如何成为架构师》这样的书估计是没有的,如果有,希望我这篇文章的思路能够给你一点提示。 very good 顶起出售 位
页:
[1]