- 综合排序
- 最热优先
- 最新优先
- 来自专栏前端Q
手淘店铺全链路性能优化
过程中我们打通了从容器侧到前端全链路的性能埋点采集链路，站在全局的链路看整个阶段耗时，有针对性的对链路进行深度优化，并通过可视化、多维度直观呈现性能数据。 性能采集 为了能直观的分析性能数据，我们将用户点击到首屏可见看成一个全链路，将大致分为客户端阶段和业务逻辑阶段，如下： 性能采集1 传统意义上的性能埋点更多的是局限于前端，但由于我们的程序是运行小程序容器之上 ，容器在启动，资源加载，环境创建之后才开始执行业务逻辑代码，容器阶段也是整个链路上非常重要的一环，所以我们的阶段分析应该是全链路的。 为了得到全链路的性能埋点，我们联合数据平台定义了性能埋点上报字段，能将客户端埋点和业务自定义埋点打在一条日志信息中。 总结 我们从细化了全链路阶段耗时分析，到打通全链路性能埋点采集，有针对性对链路各个阶段进行耗时分析和优化，上线，然后不断验证，完全可以做为一个性能优化的通用思路，去复用到其他业务场景的性能优化。
84420发布于 2021-08-24 - 来自专栏FE32 Code
Web页面全链路性能优化指南
在项目开发以及用户使用的过程中，能够让任何一个链路快一点，都可以被叫做性能优化。 本文会对web页面的全链路进行完整的讲解并针对每一步找到能做的性能优化点，本文的目标是极致的性能优化。 HTTP/1.1默认开启了 keep-alive ，它能够让一个TCP连接中传输多个HTTP请求，也叫链路复用。 在打开一个站点的首屏页的完整链路中，使用SSR服务端渲染时的速度要远大于CSR客户端渲染，并且SSR对SEO友好。所以对于首屏加载速度比较敏感或者需要优化SEO的站点来说，使用SSR是更好的选择。 CDN 静态资源全上CDN，CDN能非常有效的加快网站静态资源的访问速度。 压缩 gzip压缩、html压缩、js压缩、css压缩、图片压缩。 css外链，能走缓存。 添加媒体字段，只加载有效的css文件。 <link rel="stylesheet" href=".
1.5K11编辑于 2023-08-01 - 来自专栏FE32 Code
Web页面全链路性能优化指南
在项目开发以及用户使用的过程中，能够让任何一个链路快一点，都可以被叫做性能优化。 本文会对web页面的全链路进行完整的讲解并针对每一步找到能做的性能优化点，本文的目标是极致的性能优化。 HTTP/1.1默认开启了 keep-alive ，它能够让一个TCP连接中传输多个HTTP请求，也叫链路复用。 在打开一个站点的首屏页的完整链路中，使用SSR服务端渲染时的速度要远大于CSR客户端渲染，并且SSR对SEO友好。所以对于首屏加载速度比较敏感或者需要优化SEO的站点来说，使用SSR是更好的选择。 CDN 静态资源全上CDN，CDN能非常有效的加快网站静态资源的访问速度。 压缩 gzip压缩、html压缩、js压缩、css压缩、图片压缩。 css外链，能走缓存。 添加媒体字段，只加载有效的css文件。 <link rel="stylesheet" href=".
2.4K10编辑于 2022-10-27 - 来自专栏前端桃园
如何全链路进行前端性能优化
概述 通常来讲前端性能优化是指从用户开始访问我们的网站到整个页面完整的展现出来的过程中，通过各种优化策略和优化方法让页面加载的更快，让用户的操作响应更及时，给用户更好的使用体验。 本文并非细节的讲述如何实现性能优化，而是从各个方面介绍性能优化的方式方法，并且不仅限于H5，因为当今的前端也不仅仅只有H5。 2. 图片资源优化 1. *=，|=，^=，$=，使用外链的css，可以单独形成文件放在cdn，使用缓存形式加载。避免使用@import因为他的加载会阻塞进程，需要加载完毕才会向下执行。 JavaScript优化 首先我们是当需要的时候才去优化，不是为了优化而优化，一般的优化是在某一个时间点进行的，而且优化也需要考虑可维护性这是要结合团队的研发水平和代码的规范。 1. CDN可以灰度发布，也就是在部分地区部分运营商优先发布静态资源，验证通过后再进行全量发布。具体实施可以从域名方面下手，设置特殊VIP解析到要灰度的城市或者运行商。
1.6K30发布于 2021-12-01 - 来自专栏老张的求知思考世界
全链路压测(1)：认识全链路压测
前言 之前断断续续写过一些全链路压测相关的技术文章，很多同学评价还不错。朋友建议我写个系列，基于自己的落地实践经验，对全链路压测做个系统性的梳理总结。 定义：如何理解全链路压测 PS：这里的定义是我基于自己对生产全链路压测的了解和实践总结得来的，仅代表个人观点。 1、什么是全链路压测？ 单机单接口、单机单链路、单机混合链路 包含覆盖范围内的所有核心链路及场景 压测过程 可观测性较低，延时较高 实时可视化观测 测试结果 数据维度小，无法提供太多数据便于分析 提供多维度细粒度的数据，便于快速定位问题优化 ，数据流转性无法保证，数据多样性也存在部分问题； ---- 那么，要解决差异带来的不稳定因素，最终的选择就是生产全链路压测： 挑战：如何落地生产全链路压测 虽然全链路压测解决了传统压测过程中的种种痛点 流程：生产全链路压测落地实践 生产全链路压测的整个流程，大致可分为三个环节，每个环节的主要事项如下： 能力建设：生产压测能力演变历程 生产全链路压测的本质是能力建设的技术工程，不是一蹴而就。
3.6K30发布于 2021-10-14 《Webpack热更新瓶颈突破：全链路优化指南》
此时，对其原理的深度解构与性能的精准优化，便成了开发者必须攻克的课题。 此时，HotModuleReplacementPlugin插件迅速介入，它并非触发全量重建，而是基于模块依赖图谱，精准锁定变更模块及其直接关联的依赖，启动增量编译。 HMR在定位变更范围时，不得不遍历庞大的依赖链，增量编译的优势被稀释，甚至可能接近全量编译的耗时。 三、优化策略：从配置到架构的全链路升级优化HMR性能并非简单的参数调优，而是需要从项目架构、配置设计到代码习惯的全链路改造，每一个环节的优化都能带来肉眼可见的响应提升。配置层面的优化是最直接的切入点。 构建工具的协同优化能进一步释放性能。
26200编辑于 2025-07-22- 来自专栏老张的求知思考世界
全链路压测(14)：生产全链路压测SOP
——来自百度百科 本篇文章要说的全链路压测SOP，实际上就是我在实践全链路压测的过程中，对实践经验和教训的一个总结。 全链路压测(1)：认识全链路压测 全链路压测(2)：方案调研和项目立项 全链路压测(3)：技术改造和测试验证 全链路压测(4)：全链路压测的价值是什么？ 全链路压测(5)：生产全链路压测实施全流程 全链路压测(6)：确认范围和识别风险 全链路压测(7)：核心链路四问 全链路压测(8)：构建三大模型 全链路压测(9)：容量评估和容量规划 全链路压测(10) ：测试要做的准备工作 全链路压测(11)：聊聊稳定性预案 全链路压测(12)：生产压测必不可少的环节 全链路压测(13)：高可用和性能优化 再加上本篇的生产全链路压测SOP思维导图，就是整个系列的内容。 最后，重申一下我对全链路压测的部分认知： 全链路压测是一个技术工程，而非单纯的测试手段； 全链路压测只适用于部分企业和业务类型，而非一个银弹； 全链路压测的落地并非一蹴而就，需要较好的技术基础设施建设做保障
1K10编辑于 2022-09-02 - 来自专栏老张的求知思考世界
全链路压测(5)：生产全链路压测实施全流程
前言 前面的几篇文章从生产全链路压测的定义，内部立项和技术调研，聊到了测试验证以及全链路压测的对企业业务和技术团队的价值，算是整体上的构建一个认知的概念。 从这篇文章开始，会进入具体的落地实践环节。 这篇文章中，我会介绍生产全链路压测的落地实施全流程，即每个环节要做什么事情。 四大阶段 如果将生产全链路压测作为一个阶段性的技术项目来看，全链路压测从开始到项目结束，需要经过四个阶段。 整体的实施流程图如下所示： 接下来我来为大家解密，生产全链路压测落地实施，在不同的阶段都会做哪些事情。 筹备阶段 确定业务范围 一般来说线上实施线上全链路压测之前，要明确本次压测需要验证的业务范围。 核心业务定义 出问题会影响其他业务链路； 流量较高且出现问题会影响整体业务目标的达成； 核心项目定义 前面提到了生产全链路压测是个复杂的技术项目，那么如何定义这种技术项目呢？
2K40编辑于 2022-04-01 - 来自专栏OSChina
全链路跟踪zipkin
--全链路跟踪 sleuth zipkin --> <dependency> <groupId>org.springframework.cloud</groupId
79120发布于 2020-04-24 - 来自专栏D·技术专栏
EagleEye全链路追踪
RpcID RPCId用链路调用顺序来递增。 阿里云相似产品：Tracing Analysis 效果图： ? image.png
4K10发布于 2020-02-13 - 来自专栏Java学习录
Zipkin全链路监控
Zipkin是SpringCloud官方推荐的一款分布式链路监控的组件，使用它我们可以得知每一个请求所经过的节点以及耗时等信息，并且它对代码无任何侵入，我们先来看一下Zipkin给我们提供的UI界面都是提供了哪些信息 zipkin首页为我们提供了对于调用链路的搜索查询及展示的功能 ? 第二个选项卡里提供了历史数据的导入功能 ? 第三个选项卡里展示了各个微服务之间的关系 ? 我们再次回到首页，我们点开一个调用链路之后就会看到此次链路调用的详情 ? 现在我们点开详情中的一个service，可以看到此次调用在这个微服务中的详细信息。 ?
3.7K00发布于 2019-04-18 全链路压测硬核实战：从方案落地、瓶颈根因定位到全链路性能优化
核心原因在于，传统的单接口、单系统压测，无法模拟真实线上的全链路流量场景，无法捕捉到跨服务调用、资源竞争、链路依赖带来的隐藏性能瓶颈。 全链路压测，正是解决这一问题的核心方案，它通过模拟真实的线上用户行为与全链路流量模型，在预发环境甚至生产环境完成对整个分布式系统的性能验证，提前暴露瓶颈风险，保障系统的稳定性。 ），是全链路压测的核心吞吐量指标。 四、全链路瓶颈定位的标准化方法论 瓶颈定位的核心原则是自上而下，从链路到节点，从指标到根因，先通过全链路追踪锁定瓶颈链路，再深入节点定位瓶颈资源，最终分析根因。 五、全链路性能优化的可落地实战方案 本章节的优化方案均对应上一章节的瓶颈场景，所有代码、参数配置均经过验证，可直接落地使用。
13810编辑于 2026-04-22- 来自专栏vivo互联网技术
Node.js 应用全链路追踪技术——全链路信息存储
作者：vivo 互联网前端团队- Yang Kun本文是上篇文章《Node.js 应用全链路追踪技术——全链路信息获取》的后续。阅读完，再来看本文，效果会更佳哦。 本文主要介绍在Node.js应用中， 如何用全链路信息存储技术把全链路追踪数据存储起来，并进行相应的展示，最终实现基于业界通用 OpenTracing 标准的 Zipkin 的 Node.js 方案。 2.2 zipkin 架构官方文档上的架构如下图所示：为了更好的理解，我这边对架构图进行了简化，简化架构图如下所示：从上图可以看到，分为三个部分：第一部分：全链路信息获取，我们不使用 zipkin 自带的全链路信息获取 ，我们使用 zone-context 去获取全链路信息第二部分：传输层， 使用 zipkin 提供的传输 api ，将全链路信息传递给 zipkin第三部分： zipkin 核心功能，各个模块介绍如下： 三、Node.js 接入 zipkin3.1 搞定全链路信息获取这个我在 《Node.js 应用全链路追踪技术——全链路信息获取》 文章中，已经详细阐述了，如何去获取全链路信息。
1.2K50编辑于 2023-02-06 - 来自专栏WeTest质量开放平台团队的专栏
走进腾讯| 手游全链路优化沙龙报名开启！
稳定畅快的游戏体验背后是腾讯研发团队在游戏品质、游戏性能、安全及兼容性等方面的持续提升及优化。 4月27日，安卓绿色联盟邀您一起走进创始企业腾讯，并邀请到来自腾讯互娱、腾讯云、华为终端的技术大咖，为开发者带来手游的全链路优化深度解析，助力提升手游品质。 3 TGPA性能优化方案介绍和体验优化实践 议题介绍：简单介绍TGPA终端性能优化的一些思路和实现方式，重点分享TGPA在终端体验上的优化，包括防误触、屏幕统一适配、资源预下载，以及震动等游戏与厂商深度技术合作的内容
1.6K20发布于 2019-05-16 - 来自专栏老张的求知思考世界
全链路压测(13)：高可用和性能优化
大家好，这是全链路压测系列的第十三篇文章，也是倒数第二篇文章。 前面用了很多篇幅介绍了包括全链路压测的调研验证、落地实践前的准备工作细节、以及线上压测的一些注意事项。 到了这里基本上技术实践的东西就讲完了，这篇文章，我想和大家聊聊，关于性能优化和高可用，我的一些理解。 开始聊之前，我想回到写这个系列文章的开头，先聊聊全链路压测出现的原因和本质。 理解全链路压测 什么是全链路压测 基于实际的生产业务场景和系统环境，模拟海量的用户请求和数据，对整个业务链路进行各种场景的测试验证，持续发现并进行瓶颈调优，保障系统稳定性的一个技术工程。 降低技术实践和管理成本支出； 关于全链路压测的理解误区 全链路压测是一个技术工程，而非单纯的测试手段； 全链路压测只适用于部分企业和业务类型，而非一个银弹； 全链路压测的落地并非一蹴而就，需要较好的技术基础设施建设做保障 ； 落地全链路压测最大的挑战不是技术能力，而是企业的组织协调和沟通效率； 全链路压测的本质是尽量用较低的成本确保系统稳定可用，以保障系统在峰值流量下支撑业务目标达成； 高可用和性能优化 聊完了上面关于全链路压测的本质和目的
91530编辑于 2022-09-02 - 来自专栏WeTest质量开放平台团队的专栏
走进腾讯| 手游全链路优化沙龙报名开启！
稳定畅快的游戏体验背后是腾讯研发团队在游戏品质、游戏性能、安全及兼容性等方面的持续提升及优化。 4月27日，安卓绿色联盟邀您一起走进创始企业腾讯，并邀请到来自腾讯互娱、腾讯云、华为终端的技术大咖，为开发者带来手游的全链路优化深度解析，助力提升手游品质。 3 TGPA性能优化方案介绍和体验优化实践 议题介绍：简单介绍TGPA终端性能优化的一些思路和实现方式，重点分享TGPA在终端体验上的优化，包括防误触、屏幕统一适配、资源预下载，以及震动等游戏与厂商深度技术合作的内容
1.5K30发布于 2019-05-16 - 来自专栏devops
【架构实战】全链路压测实战与架构优化
为什么需要压测性能测试是验证系统能力的重要手段，但很多时候我们发现：上线前测试通过，上线后扛不住单接口压测没问题，混合场景就崩了压测时好好的，大促时各种异常根本原因：测试环境与生产环境差异大单接口压测无法模拟真实业务场景缺乏全链路压测 ，无法发现系统短板全链路压测的目标：验证系统在高并发下的稳定性发现性能瓶颈和隐患确定系统容量边界为扩容和优化提供数据支撑二、压测类型与目标1.压测类型分类类型说明目的基准测试单接口压测获取单个接口性能基线负载测试逐步加压找到最大处理能力压力测试持续高压测试系统极限容量测试持续运行验证长时间稳定性全链路测试端到端压测模拟真实业务场景 .工具选型建议场景推荐工具理由快速单接口压测wrk轻量快速复杂业务流程JMeter/Gatling支持脚本编程大规模分布式压测JMeter成熟的分布式方案CI/CD集成Gatling代码化，易集成四、全链路压测实施 最小空闲连接：20连接超时：3秒SQL优化：添加适当索引避免全表扫描使用分页查询2.缓存优化多级缓存架构：L1：本地缓存（Caffeine）L2：Redis分布式缓存L3：数据库缓存穿透防护：布隆过滤器判断是否存在缓存空值防止穿透 0.02%达标容量规划公式所需服务器数=目标QPS/单机QPSx(1+冗余比例)八、总结全链路压测是保障系统稳定性的重要手段：真实场景：模拟生产真实流量数据隔离：压测数据不影响生产瓶颈定位：找到系统短板容量规划
19100编辑于 2026-04-01 - 来自专栏老张的求知思考世界
全链路压测(7)：核心链路四问
前言 前面的文章介绍了全链路压测的落地实施全流程，其中有个环节我特别提到了它的重要性，同时这也是本篇文章的主题：核心链路梳理。那什么是核心链路？为什么要确定核心链路？如何进行核心链路梳理？ 梳理核心链路的目的又是什么？这篇文章，我会给你答案。 什么是核心链路？ 之前在一些线下沙龙分享或者线上直播时候，很多同学都会问我一个问题：什么是核心链路？好像这个词有种魔法，很难让人去理解。 这么说比较拗口，再直白一些就是：哪些接口会影响用户下单支付，哪些就是核心链路。 下面附一个常见的电商企业核心链路流程图，供大家参考。 为什么要确定核心链路？ 流量模型 我在前面的文章《生产全链路压测实施全流程》中有提高转化技术指标的一个案例，这里再次回顾下： 客单价为500，单日GMV为10亿，那么支付订单量为10亿/500=200W； 假设日常支付订单量为 文末回顾 这篇文章主要聊了全链路压测在备战阶段最重要的一件事，核心链路梳理。其中提到了流量模型相关的内容，下篇文章，我会以全链路压测过程中需要梳理的三大模型为主题，为大家介绍它们。
1.9K21编辑于 2022-04-01 - 来自专栏老张的求知思考世界
全链路压测(4)：全链路压测的价值是什么？
在开始真正的介绍落地实践过程以及相关案例之前，我想和大家聊聊，我对全链路压测的一些认知，即：全链路压测在技术团队中的定位，以及它的价值是什么。 业务和技术是什么关系？ 技术能力 要保障线上服务稳定性，除了容量评估/故障演练/全链路压测外，还需要其他技术手段如： 弹性扩缩容能力； 监控告警追踪能力； 限流降级熔断能力； 故障识别响应和技术优化； 大促效率 我们以电商的大促举例子 全链路压测对稳定性保障的价值 聊了这么多，回到文章顶部，我所要表达的内容，全链路压测的价值是什么？ 在我看来，全链路压测不仅仅是一种很好的性能测试和优化手段，而是在整个稳定性保障中，起到了串联全过程的能力。 ，通过前面的几篇文章，从认识全链路压测到项目立项以及技术调研和测试验证，我试图从另一个视角来为大家揭秘全链路压测的另一面。
1.6K20编辑于 2022-01-25 - 来自专栏肉眼品世界
轻松玩转全链路监控
什么是全链路监控？ ，为全链路监控提供了理论指导。 我们只需要知道，优秀的全链路监控组件会尽可能的遵循 OpenTracing 标准，以获得更好的通用性以及扩展性。 可选方案 ---- 全链路监控组件如何获得链路相关的信息呢？ 无法支撑大规模场景：当接入的应用数量达到上千个之后，开源全链路监控方案会暴露出各种性能问题，需要开发者修改源代码进行针对性的优化。 鹰眼系统同时将基础设施层、分布式应用层、业务逻辑层与客户端层进行了全链路跟踪，每天对万亿级别的分布式调用进行分析，对底层的流计算、多维时序指标与事件存储体系等进行了大量优化，同时引入了时序检测、根因分析
2K11发布于 2020-12-07
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号