用户总是反应网站访问速度慢，那么如何发现慢在哪里，为什么慢，如何改进呢？
根据我们的架构，慢的原因可能有
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

顶起出售 位