网站性能优化杂谈(一)

作者:掠影
最后编辑时间:2019-05-31 16:42:06
浏览次数:494



网站性能优化杂谈(一)

  1. 起因
    一直以来网站性能的优化都是相当困扰的话题,无数站长,开发者,都为提升网站的体验付出了诸多的努力,而收效甚微;更有甚者,做着做着就成了反向优化(笑)。基于此情况,更加上本人一直对性能优化抱有极大的兴趣,故而在工作期间积累了一些相关经验,分享出来与大家讨论,希望大家不吝赐教。

  2. 性能瓶颈分析
    对于性能优化,大致可以从以下几个层面来进行,分别是网络,前,后,以及数据层;其中又会细分为几项领域;故而本文将会分为几个部分,依次阐述相关的瓶颈和优化方式,今次先列出目录,在接下来的一段时间里依次更新(如果没忘了这回事的话)。

    • 2.0 网络层
      • 2.0.1 DNS解析
      • 2.0.2 请求分发
      • 2.0.3 CDN资源
      • 2.0.4 请求协议
    • 2.1 页面前端
      • 2.1.1 静态资源
      • 2.1.2 JS执行
      • 2.1.3 CSS解析
      • 2.1.4 HTML结构
      • 2.1.5 图片懒加载
    • 2.2 网站后端
      • 2.2.1 请求获取
      • 2.2.2 请求分发
      • 2.2.3 业务执行
      • 2.2.4 数据查询
      • 2.2.5 响应返回
    • 2.3 服务器层
      • 2.3.1 服务器选择
      • 2.3.2 服务器配置
      • 2.3.3 服务器资源策略
    • 2.4 缓存
      • 2.4.1 页面缓存
      • 2.4.2 状态缓存【数据缓存】
      • 2.4.3 查询缓存
    • 2.5 数据库
      • 2.5.1 查询优化
      • 2.5.2 表设计优化
      • 2.5.3 索引优化
      • 2.5.4 读写分离
      • 2.5.5 分表分库
  3. 网络层
    本文作为首篇,主要来说一些非代码向的优化操作,里面首先就是网络层的相关内容。

    • 3.1 DNS解析
      • 说到DNS解析,对于一般用户来说无非是在外网买个域名然后设置解析方案到VPS罢了。而实际上一般业务请求里这一点确实没错,我们只需要在域名托管商处设好A类型或者CNAME类型[1]的解析方式,然后等到TTL到达,生效即可;
      • 但是这种方案的提升空间是相对有限的,故而除了花钱在域名提供商那里提高解析方案的性能外,我们可以做的事情相当有限,但是事实真的如此么?
    • 3.2 请求分发
      • 答案当然是否定的,在外网DNS解析的基础上(即让我们的服务器暴露到外网),我们还可以通过局域网的特性,定义诸多请求转发,从而将DNS的解析相对灵活地使用起来;举例而言:
      • 当我们有一个域名为test.com的地址时,将其解析到A1这台服务器上,并将其设置为网关代理;接下来在A1上我们就可以利用A1 的反向代理功能自定义请求转发策略,例如业界常常提到的负载均衡[2]策略,将DNS解析而来的请求轮询发配给内网【内部局域网】的几台服务器如A2, A3, A4等,这样分摊下来每个服务器所轮到的请求数量就会相对合理地均摊;当然这里还有其他的负载均衡策略,就不再赘述了;
      • 请求分发【反向代理】的方式,可以说是分布式架构的一个基础组成;而这点本人也知之甚少,孤儿也就不再班门弄斧,遗笑大方了;只是一些基础的概念如果可以明晰,那么排查起复杂的问题也就能够事半功倍了。
    • 3.3 CDN资源
      • 对于服务器上的一些静态资源,例如图片,JS,CSS等,根据浏览器特性的限制,对单个地址的并发请求会限制在5-10个;而在实际开发过程中,基本上都会存在多个图片并行加载的情况,这时候就需要我们将这些资源分散部署在CDN上,通过CDN自定地将请求分摊并分发到离用户位置最近的服务器上,这样不旦可以加速请求,同时也能通过返回最近的地址以减少等待时间;
      • 值得注意的是,CDN也是有可能存在问题的,例如CDN请求失效【资源过期】,或者说出现不合理的资源等待时间【一般为遭遇DDoS攻击等】;这种时候就需要手动设置一个fallback策略,即CDN资源失效时,由该地址返回内容;最坏的情况会导致服务器带宽回退到最恶劣的情况,即所有请求都交由本地处理;所以在设计这方面的架构时一定要留好带宽余裕,在压力测试时就要做好这方面的准备,以防不测;
    • 3.4 请求协议
      • 对于一般开发者而言,Web开发等价于HTTP协议上的开发;虽然说HTTP协议从1.0, 1.1一直到2.0都在进步,但是针对一些响应周期短,请求频率大的网络请求,HTTP无疑是较为臃肿的;更何况加上了TLS加密后的HTTPS,在响应上又会有所延迟;
      • 针对某些特殊场景【如轮询结果,聊天室等】时延要求较高的情况,WebSocket协议[3]是一种不错的选择。一方面它定义了新的链接方式【全双工】,服务端和客户端都可以发送消息,另一方面由于省去了每次的鉴权行为,使得Websocket建立在会话的基础上,故而不需要反复地建立连接-断开连接,从而进一步的提升了效率;
  4. 小结
    本章主要简介了Web开发过程中可能需要优化的几个部分,并简要介绍了网络层的解决方案;在下期将会主要针对页面前端的优化策略进行一系列分享;敬请期待,同时希望读者斧正,不吝赐教;

取消

感谢您的支持,我会继续努力的!关闭

扫码支持
大家有钱的捧个钱场,没钱的捧个人场233333

打开支付宝扫一扫,即可进行扫码打赏哦

分享到: QQ空间 更多



评论区