- 综合排序
- 最热优先
- 最新优先
HTTPDNS SDK解析时延优化方案
对使用HTTPDNS SDK的用户，当前SDK内部使用了LocalDNS和备份IP进行兜底，解析成功率将不受影响。 但SDK会周期性尝试探测服务可用性，导致每十分钟解析时延会间歇性增加一次，如果您需要对解析时延进行优化，可参考本文档。 对直接调用API的用户，建议根据实际的解析需求情况，可以将服务IP地址切换至备份线路IP地址119.28.28.98，或使用LocalDNS进行解析域名。 原因 使用SDK未设置解析超时时间的情况下，超时时间默认是2000ms。当HTTPDNS请求不可用时，会等待解析超时时间结束才会返回解析结果（此结果为LocalDNS解析结果）。 10分钟后会恢复原解析请求逻辑，导致每10分钟解析时延会间歇性增加。 解决方案 可以通过调整HTTPDNS SDK的解析超时时间，来优化解析时延。
1.3K70编辑于 2024-09-18鸿蒙5开发宝藏案例分享---Web加载时延优化解析
鸿蒙开发宝藏：Web加载完成时延优化实战（附代码解析） 大家好呀！今天在翻鸿蒙开发者文档时，发现了一个隐藏的**性能优化宝藏区**——官方竟然悄悄提供了超多实战案例！ 尤其是**Web加载完成时延分析**这块，简直是移动端开发的刚需。我立刻整理了核心要点和代码实现，分享给大家！ ⏱️ 什么是「加载完成时延」？ 优化核心：**减少白屏时间，提升首屏渲染速度**。 DevTools**（网页级深度分析） 连接设备后，用Chrome的DevTools分析： - **Network泳道**：查看资源加载时序 - **Main泳道**：监控JS/CSS解析阻塞 建议大家多去「最佳实践」板块挖宝，也欢迎在评论区交流你的优化心得~ **性能优化不是玄学，用对工具 + 理解原理 = 丝般流畅！**
30810编辑于 2025-06-27- 来自专栏存储公众号：王知鱼
Seagate：CDL 基于时延优化的IO调度算法
启发在实际应用中，如何利用CDL等技术优化大容量存储系统的性能。 性能优化 吞吐&时延-场景导入 一个十字路口的交通场景，并用不同的颜色代表了不同的数据处理类型： 蓝色代表高带宽写入的街道。 Note HDD 面临SSD在性能上的绝对优势，尽管在存量应用场景中容量市占率远远领先，但客户对吞吐量和时延的要求仍然是重要命题，如何从软件策略上优化数据读取，成为HDD厂商思考的重要课题。 图片解释了当存储驱动器无法满足主机提出的延迟要求时，它所能采取的应对措施。 这些措施通过“CDL策略值”来配置，主机可以为每个持续时间限制描述符（DLD）设置相应的策略。 上方的柱状图 展示了在混合延迟目标为4K随机读取的情况下，没有CDL时的IOPS表现。 在实际应用部署CDL技术时，需要考虑哪些因素？如何根据不同的应用场景和工作负载，配置最优的CDL策略？
37610编辑于 2025-04-10 - 来自专栏日知录
网络总时延算法
网络总时延=核心网传播时延+核心网转发时延+终端空口时延 传播时延：1000千米来回10ms 转发时延：每隔1个路由器增加1ms，可以根据TTL值算经过了多少路由器 空口时延：4G为10ms，5G 为1ms，有线为1ms 举个例子 例如500KM距离，经过8个路由器，4G和5G到中心云及用户间数据交互时延如下： 4G网络到云中心总延时为2.5ms+8ms+10ms=20.5ms； 5G网络到云中心总时延为 2个4G用户数据交互网络总延时为5ms+16ms+20ms=41ms； 2个5G用户数据交互网络总时延为5ms+16ms+2ms=23ms。 备注：4G/5G客户端误差还是很大的，实际情况很难达到空口状态，4G终端时延误差可能得几十毫秒，5G终端时延误差可能达到十几毫秒。
2.1K10发布于 2020-11-26 - 来自专栏GiantPandaCV
原理&图解vLLM Automatic Prefix Cache(RadixAttention)首Token时延优化
0x01 Prefix Caching: RadixAttention原理解析 0x02 vLLM Automatic Prefix Caching: Hash RadixAttention 0x03 算法中的Prefix Caching是包括Prefix和Generated KV Cache，并且如果Generated KV Cache如果也能被缓存，那么在多轮对话的场景中，显然具有更大的首Token时延优势 因此，如果模型服务具备prefix caching功能，将能极大地降低首Token的时延，提升用户体验。 （1）只有Prefix Caching的优化，多轮对话分析。如下图所示，只有Prefix Caching时，每个新的轮次对话中，总是会有2个片段的prompt需要在prefill阶段进行计算。 后续，已填坑，kernel部分解析，请阅读： DefTruth：[Prefill优化] 图解vLLM Prefix Prefill Triton Kernelhttps://zhuanlan.zhihu.com
14K31编辑于 2024-06-04 - 来自专栏虚拟化笔记
ovs vxlan 时延和吞吐
，水管壁粗糙弯曲不直，水流就慢，时延就大，水在水管里流得越快单位时间从水管口流出来的水就越多，时延影响吞吐。 最普通的环境，不做其它特殊优化，就看最通用的环境表现是怎样的。 两台物理机不同路径对打流量。 ? 红色的是physical流量测试路径，两个物理机直接流量测试。 netperf测试时延结果，时延单位是us。 ? 小报文pps大时配置ethtool -N eth4 rx-flow-hash udp4 sdfn后ping时延没有改善，相比于vxlan处理引入的时延，更应当关注kvm对中断处理以及vcpu调度引入的时延 ，目前现状应该优先优化kvm。
2.4K11发布于 2021-02-24 - 来自专栏AI系统
【AI系统】CPU 计算时延
CPU 计算时延是指从指令发出到完成整个指令操作所需的时间。理解 CPU 的计算时延对于优化计算性能和设计高效的计算系统至关重要。 优化内存配置可以显著降低时延，提高系统性能。 CPU 计算时延 下面将介绍 CPU 计算延时的组成和影响计算时延的相关因素。 优化计算时延方法 优化 CPU 计算时延是一个复杂的过程，需要综合考虑指令提取、解码、执行、存储器访问和写回等多个方面的因素。 通过提高时钟频率、优化流水线设计、增加缓存容量、采用高效的并行算法和提升内存子系统性能，可以显著降低 CPU 计算时延，提升计算机系统的整体性能。 int n = 2000; for (int i = 0; i < n; ++i) { y[i] = alpha * x[i] + y[i]; } } 例子解析
71110编辑于 2024-12-04 - 来自专栏SDNLAB
Ryu:网络时延探测应用
本文将介绍笔者开发的网络时延探测应用。该应用通过LLDP数据包的时延和Echo数据包的时延计算得出链路的时延数据，从而实现网络链路时延的感知。详细原理和实现步骤将在文章中详细介绍。 计算LLDP时延的处理逻辑如下代码所示。首先从Packet\_in中解析LLDP数据包，获得源DPID，源端口。 其测量方法是通过在控制器给交换机发送携带有时间戳的echo\_request报文，然后解析交换机返回的echo\_reply，并用当下时间减去data部分解析的发送时间，获得往返时间差。 时延探测应用运行结果截图如图2所示。 ? 图2.时延监控应用运行结果 总结 网络时延数据是网络重要数据，是许多网络决策的重要依据，所以网络时延数据测量非常重要。 此外，还需要注意两点：（1）此时延探测模块十分初级，并没有精确性方面的考虑，比如需要将其放在核心层实现，在发送的最后时刻才添加时间戳，收到数据包的第一时刻马上解析时间戳等等，所以精确性不足。
1.9K80发布于 2018-04-02 - 来自专栏蒙奇D索隆的学习笔记
【计算机网络】计算机网络的性能指标——时延、时延带宽积、往返时延、信道利用率
一、时延（Delay） 1.1 定义 时延是指数据（一个报文或分组）从网络（或链路）的一端传送到另一端所需的总时间，它由4部分构成；发送时延、传播时延、处理时延和排队时延。 可忽略 区分传输时延与传播时延 在数据的整个传播过程中，发送时延又可称为传输时延，别看传输与传播只有一字之差，它们二者的含义却截然不同： 传输时延：数据从节点传输到链路中所消耗的时间 传播时延：数据从链路传播到节点中所消耗的时间 t2是接收方处理数据的排队与处理时延 t3是接收方发送确认信息的发送时延 t4是确认信息在信道中的传播时延 RTT是整个过程的往返时延 由上图我们可以很清楚的看到，往返时延是不包含发送方的发送时延的， 在互联网中，往返时延还包括各中间节点的处理时延、排队时延及转发数据时的发送时延。 四、信道利用率 信道利用率是指某个信道百分之多少的时间是有数据通过的。 结语 在今天的内容中我们介绍了计算机网络的4种性能指标： 时延：是数据从网络的一端发送到另一端所需要的总时间，由发送时延、传播时延、排队时延、处理时延组成。
1.6K10编辑于 2025-03-07 《GraphQL状态图建模与低时延控制能力解析》
物联网设备态联拓扑的规模化落地进程中，设备状态图的高效查询与控制指令的低时延调度，已然成为构筑全域物联交互体系的核心命题，传统物联查询接口的刚性范式，始终难以适配异构设备的态数据柔性获取需求，固定字段与固定接口的设计逻辑 GraphQL实时订阅机制为物联网设备控制指令的交互提供了全新的技术实现路径，其依托持久化连接构建的态推送体系，彻底摒弃了传统轮询模式的资源浪费与时延损耗，成为适配设备控制指令低延迟需求的核心支撑能力， GraphQL实时订阅对设备控制指令低延迟需求的满足能力，存在明确的场景化适配边界，并非能够全场景覆盖物联控制的严苛时延要求，在高密度设备集群的集中控制场景中，大量并发订阅会话会挤占传输带宽与运算资源， ，进一步加剧时延问题。 不同协议物联网设备的指令转换环节，会产生额外的时延损耗，让高要求的低延迟需求难以落地，同时订阅机制的保活逻辑需要持续消耗链路资源与终端算力，在弱网、窄带环境中，保活机制的失效会直接中断指令推送，影响控制指令的实时传递与执行
12810编辑于 2026-02-11转载：【AI系统】CPU 计算时延
CPU 计算时延是指从指令发出到完成整个指令操作所需的时间。理解 CPU 的计算时延对于优化计算性能和设计高效的计算系统至关重要。 优化内存配置可以显著降低时延，提高系统性能。 CPU 计算时延 下面将介绍 CPU 计算延时的组成和影响计算时延的相关因素。 优化计算时延方法 优化 CPU 计算时延是一个复杂的过程，需要综合考虑指令提取、解码、执行、存储器访问和写回等多个方面的因素。 通过提高时钟频率、优化流水线设计、增加缓存容量、采用高效的并行算法和提升内存子系统性能，可以显著降低 CPU 计算时延，提升计算机系统的整体性能。 int n = 2000; for (int i = 0; i < n; ++i) { y[i] = alpha * x[i] + y[i]; } } 例子解析
49010编辑于 2024-12-11- 来自专栏大话存储
恢复带宽与时延的平衡
随着带宽时延产品的增长，越来越少的算法能够在请求足够数据的同时来满足时延要求。然而在无法支持的情况下，则会影响系统带宽和性能。从最简单的层面来说，这就是为什么拥有一个平衡的带宽/时延比很重要。 回顾图1，基于NAND的固态盘的引入在一段时间内提供了一个平衡的带宽/时延解决方案，它们的时延比硬盘低得多。 在这种形式下，空闲平均时延大约为10微秒，而NAND 固态盘则超过80微秒4 。图3显示了系统硬件和软件时延。 英特尔®傲腾™数据中心级固态盘的硬件时延与系统堆栈软件时延大致相同，为系统带来了另一种平衡。即使在高负载下，始终如一的低时延以及高耐用性使这些固态盘成为快速缓存或分层热数据的理想选择。 对于持久内存，空闲平均读取时延下降到100到340纳秒。5相较之前提到的带宽时延产品的低时延，由于时延较低，因此可以使用较小的单元尺寸、一条高速缓存线访问该内存，同时仍然提供其全部带宽。
1.4K10发布于 2019-09-24 - 来自专栏存储公众号：王知鱼
KIOXIA：低时延FLASH 卸载DRAM
KIOXIA：低时延FLASH 卸载DRAM-Fig-1 1. 需求和场景在不断增加，用户对更高效数据访问的诉求不断涌现。 2. Note：结合前几日整理的CXL访问时延数据，直连的CXL时延在400ns以内，以这个数据来估计的话，实现外部时延3us以内，不是太困难的问题，特定场景还需特定分析。 参考阅读：XConn：CXL内存应用的带宽和时延 FLASH 卸载DRAM，能卸载多大比例呢？ KIOXIA：低时延FLASH 卸载DRAM-Fig-9 应用场景与TCO 左侧是混合测试场景的DRAM卸载比例和性能数据。 低时延FLASH卸载DRAM比例-性能关系和TCO数据，基于此明确了FLASH的可参与空间（Fig8/9）。
54800编辑于 2025-02-11 - 来自专栏软件绿色联盟动态
【下篇】TWS蓝牙耳机游戏时延标准与游戏应用侧优化建议
上篇已详细解读了TWS蓝牙耳机游戏时延的测试方法，那么如何衡量游戏时延的好与坏？以及游戏时延该如何优化呢？本篇章将重点解读蓝牙耳机游戏时延的评测标准和绿盟各成员给出的一些优化建议。 TWS蓝牙耳机游戏时延体验标准 标注：实验数据来源于绿盟实验室数据，实验设备均采购于市场 《软件绿色联盟游戏体验标准3.0》通过大量的人因拟合实验、大数据分析和实验室精确的测试以及ITU相关标准参考， 得出结果：时延小于140ms时，游戏体验无感知，体验舒适；时延大于200ms，有明显的延迟感，难接受；介于140ms到200ms之间时，延迟感不明显，属于可接受范围，评级如下： 蓝牙游戏时延三方应用侧的优化建议 对准绿标3.0 定义的级别，我们对蓝牙耳机游戏时延指标做了一些分解，发现除了硬件设备的因素外，三方游戏APK对音频接口的开发和应用行为也起着重要的作用，主要因素如下： 1.OPENSLES库的使用 三方游戏应用侧如按照以上建议开发考虑，即可保证较小的音频数据消耗和音频数据流的健壮性，达到最优的音频播放效果，从而配合蓝牙耳机时可达到最佳的游戏时延体验。
1.6K30编辑于 2022-03-31 - 来自专栏架构精进之路
双十一聊聊低时延利器：QUIC
今天我们也围绕着“快”，来跟大家聊一下低时延利器：QUIC。 1. 这是因为 QUIC 协议已经包含了多路复用和连接管理，HTTP API 只需要完成 HTTP 协议的解析即可。 3.
1.8K30发布于 2020-11-17 - 来自专栏cwl_Java
速读原著-TCPIP(TCP经受时延的确认)
把从b s d i发送到s r v 4的7个A C K标记为经受时延的A C K。 绝大多数实现采用的时延为 200 ms，也就是说，T C P将以最大200 ms的时延等待是否有数据一起发送。 由于这个时间小于200 ms，因此我们在另一端从来没有观察到一个经受时延的A C K。 在经受时延的定时器溢出前总是有数据需要发送（如果有一个约为 16 ms等待时间越过了内核的 200 ms时钟滴答的边界，则仍可以看到一个经受时延的 A C K。在本例中我们一个也没有看到）。 Host Requirements RFC声明T C P需要实现一个经受时延的A C K，但时延必须小于500 ms。
93210发布于 2020-03-11 - 来自专栏存储公众号：王知鱼
XConn：CXL内存应用的带宽和时延
CXL 时延 前面讨论直连内存和CXL交换内存的带宽比较，两者在多线程场景带宽峰值相近；与100%读IO相比，读写混合业务场景CXL 内存带宽表现更好。 CXL 内存访问时延 与NUMA跨节点访存时延模型相似， • 直连内存的时延最低 • 其次是跨CPU的内存访问 • 其次的CXL直连内存单元 • CXL池化内存时延最高 更多 CXL 内存访问时延数据 左右是在两个平台上的CXL内存访问时延测试数据，平台2（右图）较平台1跨节点CXL访存时延要低，这可能是得益于CPU之间的通信优化。 直连CXL访存时延是直连内存的2倍； 2. 跨节点访问直连CXL内存是直连内存时延的3倍； 3. CXL池化内存的访问时延是直连内存的4倍； 4. 跨节点访问CXL池化内存是直连内存时延的6倍； 总结 • CXL交换机支持的内存池提供了解决“内存墙”问题的方案，适用于AI和高性能计算（HPC）。
1.6K10编辑于 2025-02-11 - 来自专栏韩曙亮的移动开发专栏
【计算机网络】计算机网络 标性能指标 ( 速率 | 带宽 | 吞吐量 | 时延 | 时延带宽积 | 往返时延 RTT | 利用率 )
文章目录 一、速率 二、带宽 三、吞吐量 四、时延 五、时延带宽积 六、往返时延 RTT 七、利用率 一、速率 ---- 1 . ; ④ 处理时延 : 主机 , 路由器上 , 处理接收到的分组信息 , 如提取分组的首部信息 , 检错 , 查找出口 等操作 ; 上述操作花费的时间成为处理时延 ; 五、时延带宽积 ---- “时延带宽积 ” 是 描述数据量的属性 , 表示在链路上的数据量 ; 计算公式 : 时延带宽积 (bit) = 传播时延 ( s ) \times 带宽 ( bit / s) 六、往返时延 RTT ---- 往返时延 RTT ( Round-Trip Time ) : 从 发送方 发送数据开始 , 到 发送方 接收到 接收方 的 确认数据 , 总共经历的时延 ; 往返时延 RTT 包含的时间 : 2 倍的传播时延 接收方处理时延 路由器转发处理时延 RTT 不包括从 发送方 的发送时延 , 和发送方的处理时延 ; 七、利用率 ---- "利用率" 概念 : 信道利用率 : \cfrac{数据通过的时间}{总时间
2.5K00编辑于 2023-03-28 - 来自专栏城域网光通信
数据中心低时延光传输应用
本内容就数据中心低时延传输的应用需求，提出了可行性的解决方案。 满足当前4K/8K高清视频，VR互动技术，在线有限，网络直播等应用的兴起。 克服了基于Internet网络架构带来的时延问题，令网络“提速”。 提出的应用由最初的干线网络的低时延要求，下移至城域网的应用，令“错综复杂”的城域网络趋于简化发展，演变成大带宽低时延的传输网络。
90900发布于 2018-06-26 - 来自专栏星融元
星融元：浅谈RDMA与低时延网络
网络的发展好像在各方面都是滞后于计算和存储，时延方面也不例外，网络传输时延高，逐渐成为了数据中心高性能的瓶颈。 星融元Asterfusion CX-N系列云交换机搭建的超低时延无损以太网能够很好地承载RoCEv2，并基于RoCEv2打造一张低时延、零丢包、高性能的HPC高性能计算网络。 图片超低时延交换芯片，降低网络转发时延星融元Asterfusion CX-N系列云交换机，具备业界领先的超低时延能力，可满足高性能计算三大典型场景的低时延网络的需求以及对紧耦合场景中“对于各计算节点间彼此工作的协调 、计算的同步以及信息的高速传输有很强的依赖性”提出的超低时延需求。 发送服务器收到被标记的CNP报文，解析后使用对应的数据流限速算法进行限速。
2.1K30编辑于 2023-04-06
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号