标签：上传 cpu 应该 解析 重定向 回车 模型 url 复杂
用户角度：
1、打开浏览器
2、输入URL
3、按下回车
4、浏览器呈现画面
当用户输入页面地址后，浏览器获得用户希望访问的地址，便向该站点服务器发起一系列的请求，这些请求不光包括对页面的请求，还包括对页面中许许多多组件的请求，比如图片（img）、叠层样式表(css)、脚本(javascript)、内嵌页面(iframe)、音频媒体文件等。接下来一段时间，浏览器等待服务器的响应以及返回的数据。待浏览器获得所有返回的数据后，经过浏览器本地的计算和渲染，最终呈现一幅完整的页面在用户眼前。
这个过程中，主要经历以下三部分时间：
1、数据在网络上传输的时间；
2、站点服务器接受处理请求，并且生成回应数据的时间
3、浏览器本地计算和渲染的时间；
数据在网络上传输的时间包括两个部分：
1、浏览器发出请求数据到服务器，经过网络所需要消耗的时间；
2、服务器回应数据到浏览器,经过网络所需要消耗的时间；
这两部分消耗的总时间，我们称之为响应时间。它的决定因素包括发送数据的量和网络带宽；
站点服务器接受处理请求，并且生成回应数据的时间主要消耗在服务器端，这其中包括非常多的环节。
比如说服务器的并发策略、I/O模型、I/O性能、CPU核数等，当然也包括应用程序本身的逻辑复杂度和数据库操作等。
浏览器本地计算和渲染的时间自然消耗在浏览器端，它依赖的因素包括浏览器本身采用的并发策略、css样式渲染方式、javascript脚本解释器的性能、页面的大小、页面组件的数量、页面组件的缓存状况、页面组件的域名分布以及域名DNS解析等。并且其中的因素会随着各个厂商浏览器的类型、版本不同而不同。比如说某IE，它最多只能支持并发4个下载。而某火狐可以8个甚至更多。
方案一：减少页面中的HTTP请求
任何一个页面都包含多个组件（img/css/js/iframe等），每个组件都需要下载、计算或渲染，毫无疑问这些行为都会消耗时间。那么如果我们可以让页面减少这些行为，应该就可以加快网页的展示速度。这是毫无疑问的。
1、设计更加简洁的页面，使其包含较少的图片和脚本，甚至css。但这样会牺牲美观和用户交互。
2、将多个图片合并为一个文件，利用css背景图片偏移的技术将其呈现在网页中，避免多个图片下载。（雪碧图）
3、合并和压缩javascript脚本和css样式表。
4、充分利用HTTP中的浏览器端Cache策略，减少重复下载。
方案二：加快服务器端脚本的计算速度
比如说升级PHP的版本，据悉7.x的版本比5.x的版本性能优化快了近20倍。对于一些商业支持度较强的脚本语言比如.net和jsp，都有内置的优化方案。比如说解释器对某个脚本程序第一次解释的时候缓存起来，以供下次使用
方案三：使用动态缓存技术
将动态内容的HTML输出结果缓存起来，在随后一段时间内当有用户访问时便跳过重复的动态内容计算而直接输出。
但并不是所有的动态内容懂适合页面缓存。实际情况实际分析。缓存的难点在于一系列非常现实的问题，比如说成千上万的缓存文件该如何存储，缓存的命中率如何？缓存的过期策略如何设计？
方案四：数据缓存
某些动态内容的计算时间，其实主要消耗在一些烦人的特殊数据上，这些数据或者更新过于频繁，或者消耗大量的I/O等待时间，比如说数据库某字段频繁的更新和读取，这时候我们可以考虑将数据缓存起来。
方案五：负载均衡
当我们最大幅度的发挥了单台WEB服务器的处理能力，却还是超出了它承压的极限时，就需要更多的服务器来分担工作了。我们需要想办法将流量合理的转移到其他服务器上去。我们可以通过不同的方法实现web负载均衡，比如简单的HTTP重定向、dns轮询解析，反向代理。LVS组件服务器集群。
方案六：优化数据库
往往一些性能问题都发生在表现不佳的数据访问层面。比如说不合理的SQL语句、不合理的应用程序访问设计、不合理的数据库表结构设计。缺乏对数据库内部构造的了解，毫不夸张的说，以上优化全部白干！
标签：上传 cpu 应该 解析 重定向 回车 模型 url 复杂
原文地址：http://www.cnblogs.com/CyLee/p/6380411.html
