X

曜彤.手记

随手写写,关于互联网技术、产品与创业

“大型网站技术架构”总结:二,网站的高性能架构


第二篇读书总结,主要围绕着如何从多个方面来进行“高性能网站架构”来展开,性能优化小到一行代码的重构,大到服务器集群的重新架构设计。怎样通过各项数据指标来监控网站的实时性能?只有找出网站的性能“弱点”,并以此作为目标来进行迭代式的优化,才能够逐渐将网站架构演进到一个高性能的水平。

一、网站性能测试:

网站的性能指标,既可以是开发人员客观的性能分析数据,测试指标。也可以是主观的终端用户体验感受。一般而言,我们用如下一些指标来衡定一个网站的性能水平:响应时间、并发数量、吞吐量、性能计数器。响应时间即从请求发出开始,到收到响应并解析成对应可视化结果所花费的时间;并发数指系统能够同时处理的请求数量。吞吐量是指单位时间内系统能够处理的请求数量,常用的单位为 TPS(每秒事务数)、HPS(每秒 HTTP 请求数)、QPS(每秒数据库查询数);性能计数器为直观的数据指标,比如当前系统负载、对象与线程数、CPU / 内存使用率、磁盘与网络 IO 等。理想的系统负载应该对应为系统的 CPU 数量,因为系统负载指当前正在排队被 CPU 处理的进程数量。

常见的测试方法分为:性能测试、负载测试、压力测试稳定性测试。性能测试用来验证在资源可接受范围内,系统在一定压力下能否达到预期的性能指标。负载测试用来测试当系统资源满载时,系统能够达到的最大吞吐量。压力测试则是在超过系统安全负载时继续施加压力,测试直到系统奔溃所用时间的长短。而稳定性测试则是让系统在一定压力下运行一段时间,检测系统在不同时间点是否有资源的使用异常,以此来推断系统的稳定性。

在性能测试和负载测试中,系统的 TPS 随着压力的增加,值会不断增高。而在压力测试下,由于此时系统资源早已耗尽,更多的压力只会拖垮 CPU 的性能,因此此时的系统 TPS 会随着压力的不断增加而逐渐降低。而系统的响应时间在所有测试中都是随着压力的增加而逐渐增加的,不过在压力测试中,每对系统施加单位的压力,系统的响应时间会成倍的疯狂增长。

对于系统性能的优化,需要从一个请求出发,记录下请求达到每个关键节点(比如代理服务器,负载均衡服务器,应用服务器)的时间,分析哪段时间不合理,再通过分析监控数据来检测问题所在。

二、WEB 前端优化:

合并资源分离静态资源到独立域名(防止 Cookie 污染)、浏览器本地缓存服务器 GZip 压缩CDN 加速(ISP端)、使用反向代理(相当于 Gateway 主机,可缓存资源,还可以保护内部网络)等方式。

三、应用服务器优化:

应用服务器主要用来处理系统业务,是整个网站架构中的核心,也是最复杂、变化最多的部分。常用的优化手段有:使用分布式缓存(网站优化第一定律:优先考虑使用缓存。缓存不适用于频繁修改的数据,不适用与没有热点访问的数据,并且容易产生“脏读”。系统的正常运行不应该依赖于缓存系统,初始的缓存系统可以先进行“缓存预热”,比如 Redis 在初始化时会从硬盘中读取数据放到内存。如果在日志中发现大量的无法命中缓存的请求,这可能是发生了“缓存穿透”,恶意用户持续高并发的访问系统不存在的资源,这些资源无法被缓存下来导致了穿透问题,一个简单的对策是将不存在的数据也缓存起来。常见的分布式缓存系统如 JBoss 和 Memcache;JBoss 的所有集群机器在数据改变时会在所有机器更新;而 Memcache 采用了 Leader 的方式,各个主机间不进行通信,因此其线性伸缩不会影响缓存系统的性能)。使用共享队列使用集群代码优化(采用多线程,线程数一般与 CPU 数量成正比,使用无状态对象或者加锁来防止一致性问题,数据连接、通信连接等资源复用)。

四、存储系统优化:

使用 SSD 硬盘、使用 NoSQL 数据库(由于 LSM 树的数据更新速度较 B+ 树更快)、根据需求使用 RAID 磁盘阵列和 HDFS(RAID 可以在一定程度上改善磁盘的访问延迟同时增强可用性。但对于大量数据的存储需求,基于 MapReduce 可以进行并发任务处理的 HDFS 可能更加合适)。



这是文章底线,下面是评论
  暂无评论,欢迎勾搭 :)