网站的高性能架构

简介: <div class="markdown_views"><h2 id="性能测试">性能测试</h2><h3 id="角度">角度</h3><ul><li>用户视角的网站性能 <br>用户点击到看到屏幕响应的感受。 <br>受到网络带宽, 浏览器解析HTML速度。以及服务器处理的影响 <br>可以通过优化HTML,利用多域名提高并发,调整浏览器缓存策略,使

性能测试

角度

  • 用户视角的网站性能
    用户点击到看到屏幕响应的感受。
    受到网络带宽, 浏览器解析HTML速度。以及服务器处理的影响
    可以通过优化HTML,利用多域名提高并发,调整浏览器缓存策略,使用CDN,反省代理
  • 开发人员视角
    主要关注响应延迟,系统吞吐量,并发处理能力等技术指标。
    常用优化手段:使用缓存,使用集群提高吞吐能力, 使用异步消息加快响应和削峰,程序优化
  • 运维视角
    更关注资源利用,硬件信息。可以用更好的服务器,虚拟化技术等

测试指标

  • 响应时间。 用测试程序记录这个时间,可以使用重复多次求平均的方式来算出响应时间很快的接口
    响应时间从大到小: 打开网站(秒)/查询一条索引记录(10ms)/机械磁盘一次寻址/机械磁盘顺序读1M/远程分布式缓存度一条数据0.5ms/SSD顺序读1M0.3ms/本地内存读取1M(10微妙)/Java本地方法调用(几微妙)/网络传输2KB(1微妙)
  • 并发数 同时处理的请求数
  • 吞吐量 用request/m来横朗,或者TPS每秒事务数等
    想下告诉, 并发是在跑的车, 吞吐量是过收费站的车,响应时间是车速。 堵车就是瓶颈了。
  • 性能计数器
    System Load top命令。 对象与线程数,内存使用,CPU使用,磁盘与网络I/O等指标

测试方法

  • 性能测试 测试预先设定的性能指标是否能达到
  • 负载测试 到临界值,查看负载能力
  • 压力测试 持续加压,到崩溃为止,看能承受多大
  • 稳定性测试 加压比较长的时间来查看是否稳定,成波浪形,
    这里写图片描述
    这里写图片描述

报告

这里写图片描述

性能优化策略

检查请求处理各个环节的日志, 分析哪儿环节慢了。检查监控数据,分析影响性能的主要因素, 软件,网络,硬件,架构
优化分为WEB前端,应用服务器, 数据存储。

WEB前端优化

  • 减少http请求, 无状态协议,三次握手,每个请求服务器都要独立的线程处理。手段是合并CSS,合并JavaScript,合并图片。
  • 使用浏览器缓存, 使用HTTP头总的cache-control和expires属性设置缓存。当需要刷新这个缓存的时候可以改变文件的名称。
    缓存文件更新时不要一次全部更新,以免带来骤增。
  • 启用压缩。 启用gzip压缩。会给cpu带来一定的压力
  • css放在页面最上面,JS放在最下面。 因为浏览器的渲染是在加载完全部的css后开始的。 JS会在下载之后就执行,这个时候有可能阻塞页面显示。
  • 减少cookie传输 仔细考量放入cookie的内容,使用独立的域名来下载静态资源设定这些静态资源不需要传入cookie

CDN

内容分发网络。    网络第一跳。 缓存静态资源。  动态资源才连接网站服务器

反向代理

在网站机房前端,  代理网站接受http请求,有安全,负载均衡和缓存的作用,一些静态资源甚至动态资源都可以缓存在这里

应用服务器性能优化

分布式缓存

**优先考虑使用缓存优化性能。**            保存访问频繁很少改变的数据,或者比较大的计算结果。
一些使用缓存的注意点:

- 频繁修改的数据不用缓存
- 没有热点的访问不用缓存
- 数据不一致与脏读 失效会查数据库,但是会有时间差,应用要允许时间差
- 缓存可用性 应用可能会越来越依赖缓存,如果宕机会给数据库带来瞬间压力。一般的的方式是集群,把数据分片存储。
- 预热 预先加载数据
- 缓存穿透 可能是一种攻击数据库的手段。可以把不存在的数据也缓存为null等手段,具体问题具体分析。

Memcached

高性能的互不通信的服务器集群,可伸缩的架构。
这里写图片描述
使用一致性Hash等路由协议来选择服务器,服务期间不进行通讯。
- 协议。 通信协议使用TCP, 数据序列化方式使用基于文本的自定义协议。非常简单mingling<操作数>这样的结构。其他的还有JSON,XML,二进制等等
- 客户端 很丰富
- 高性能网络通信 基于Libevent,长连接表现稳定,支持事件
- 高效的内存管理 使用固定内存分配。内存分为多个slab,每个slab有固定大小的chunk.含有相同大小的chunk可以构建为slab_class.分配内存是找最接近要存数据的chunk. 可能会有空间浪费,但是内存处理起来很方便。 基于LRU算法释放最久未被访问的数据
- 互不通信的服务器,使用一致性hash等路由算法

异步操作

高并发时响应延迟,数据库压力大。 通过消息队列的异步处理实现削峰。
因为是异步,有可能失败。要注意失败后的业务处理
任何能晚点做的事情都晚点做

使用集群

需要负载均衡服务器

代码优化

多线程

两个目的使用:IO阻塞与多CPU。 IO会有很长的时间,可以单一线程监控,多路处理的方式。 另外就是多线程可以更好的利用多CPU。
启动线程数 = [任务执行时间/(任务执行时间-IO等待时间)] * CPU内核数
注意线程安全:
- 将对象设置为无状态对象。 就是无成员变量。或者成员变量也无状态
- 局部对象
- 并访问资源加锁

资源复用

数据库连接池。 对象池,线程池,单例。

hash, 因为现在的一些hash算法随机性不够,所以可能用到需要先MD5该字符串,在hash计算

垃圾回收 分代收集,应该尽量减少full gc.

存储性能优化

磁盘和SSD

显然SSD要快很多

B+树vs LSM树

都利用了磁盘是安页读取的特点。
对于现在的数据库等应用使用B+树一般最多三层,这样就需要两次随机I/O才能确定数据索引。
很多nosql数据库使用LSM树。是一个合并树。写删除修改等都会创建新的节点而不是删除或修改节点。 在内存中操作。如果超过内存的阈值会跟磁盘数的下一层数进行合并。 因为查找是首先使用内存的,因此速度比较快。更主要的是优化了写性能。

相关文章
|
10天前
|
消息中间件 缓存 架构师
关于 Kafka 高性能架构,这篇说得最全面,建议收藏!
Kafka 是一个高吞吐量、高性能的消息中间件,关于 Kafka 高性能背后的实现,是大厂面试高频问题。本篇全面详解 Kafka 高性能背后的实现。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
关于 Kafka 高性能架构,这篇说得最全面,建议收藏!
|
21天前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
1月前
|
机器学习/深度学习 存储 人工智能
用60%成本干80%的事,DeepSeek分享沉淀多年的高性能深度学习架构
【10月更文挑战第2天】近年来,深度学习(DL)与大型语言模型(LLMs)的发展推动了AI的进步,但也带来了计算资源的极大需求。为此,DeepSeek团队提出了Fire-Flyer AI-HPC架构,通过创新的软硬件协同设计,利用10,000个PCIe A100 GPU,实现了高性能且低成本的深度学习训练。相比NVIDIA的DGX-A100,其成本减半,能耗降低40%,并在网络设计、通信优化、并行计算和文件系统等方面进行了全面优化,确保系统的高效与稳定。[论文地址](https://arxiv.org/pdf/2408.14158)
55 4
|
2月前
|
机器学习/深度学习 测试技术 数据处理
KAN专家混合模型在高性能时间序列预测中的应用:RMoK模型架构探析与Python代码实验
Kolmogorov-Arnold网络(KAN)作为一种多层感知器(MLP)的替代方案,为深度学习领域带来新可能。尽管初期测试显示KAN在时间序列预测中的表现不佳,近期提出的可逆KAN混合模型(RMoK)显著提升了其性能。RMoK结合了Wav-KAN、JacobiKAN和TaylorKAN等多种专家层,通过门控网络动态选择最适合的专家层,从而灵活应对各种时间序列模式。实验结果显示,RMoK在多个数据集上表现出色,尤其是在长期预测任务中。未来研究将进一步探索RMoK在不同领域的应用潜力及其与其他先进技术的结合。
98 4
|
3月前
|
机器学习/深度学习 架构师 数据库
20年老架构师,劝我多看看这几个网站
20年老架构师,劝我多看看这几个网站
|
3月前
|
消息中间件 缓存 Kafka
图解Kafka:架构设计、消息可靠、数据持久、高性能背后的底层原理
【8月更文挑战第15天】在构建高吞吐量和高可靠性的消息系统时,Apache Kafka 成为了众多开发者和企业的首选。其独特的架构设计、消息可靠传输机制、数据持久化策略以及高性能实现方式,使得 Kafka 能够在分布式系统中大放异彩。本文将通过图解的方式,深入解析 Kafka 的这些核心特性,帮助读者更好地理解和应用这一强大的消息中间件。
156 0
|
4月前
|
负载均衡 安全 Cloud Native
云上负载均衡:构建高可用、高性能的网络应用架构
与云原生技术深度融合:随着云原生技术的普及和发展未来的云上负载均衡将更加紧密地与云原生技术相结合。例如与Kubernetes等容器编排平台集成实现自动化的服务发现和路由管理;与Serverless架构结合提供无缝的流量接入和请求处理能力。 安全性能提升:面对日益严峻的网络安全威胁云上负载均衡将更加注重安全性能的提升。通过引入加密传输、访问控制、DDoS防护等安全措施确保网络流量的安全性和隐私性;同时还将建立完善的安全监控和应急响应机制以应对各种安全事件和突发事件。 支持多协议和多场景:未来的云上负载均衡将支持更多种类的网络协议和应用场景以满足不同用户和业务的需求。例如支持HTTP/2、
244 0
|
13天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
11天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
11天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
28 1
服务架构的演进:从单体到微服务的探索之旅
下一篇
无影云桌面