- 综合排序
- 最热优先
- 最新优先
写入P99延迟突破1秒含义
写入P99延迟突破1秒” 这个表述指的是在测量数据写入操作的延迟（响应时间）时，衡量尾部延迟的关键指标 P99 超过了 1000 毫秒。具体含义需要从以下几个方面理解： 1. P99 延迟： 这是一个百分位数指标。它表示在测量时间段内，99% 的写入请求的延迟都低于或等于这个值。换言之，只有最慢的 1% 的写入请求的延迟超过了这个值 。 3. 突破 1 秒： 指这个 P99 延迟的值超过了 1000 毫秒（ms）。即： 99% 的写入请求都能在 1 秒内完成。但最慢的 1% 的写入请求，完成时间超过了 1 秒。
19010编辑于 2025-12-23- 来自专栏云云众生s
如果 P99 延迟不准确，那用什么？
如果 P99 延迟不准确，那用什么？ 那么 P99 存在什么问题？如果它们确实不准确，我们应该考虑什么替代指标呢？ 翻译自 If P99 Latency Is BS, What’s the Alternative? 。 批评一个会议名称的核心概念通常是不被社会接受的。但 P99 CONF 并不是一次普通的会议。 在 P99 CONF 22 上，社区和主办方都非常喜欢三位大胆的演讲者公开挑战 P99 延迟的价值。 最后，Honeycomb 公司的CTO Charity Majors 以会议中最生动且引人注目的方式表达了“P99 是胡说八道”。 那么 P99 存在什么问题呢？ 当你测量 P99 时，你的终端用户（个人或客户）会经历比 99 百分位数更糟糕的情况的机会有多大？实际上相当大。P99 并不意味着 99% 的事情会比这更好。
40710编辑于 2024-03-28 - 来自专栏云云众生s
P99大会：Rust、Linux、SLO和性能优化
P99 CONF 是一场免费的虚拟会议，专注于性能。每年，来自世界各地的数千名对延迟痴迷的工程师都会参加 P99 CONF。它纯粹是技术性的，有意地虚拟化，高度互动且以开源为中心。 随着我们为 P99 CONF 24 做准备（稍后会详细介绍），我们认为现在是分享过去 P99 CONF 中一些最受关注的会议的好时机。 这次演讲会让你想知道在我们活动徽标中看到的图表背后真正发生了什么——并且可能让你对 P99 的概念本身思考很多。 奖励：在“如果 P99 延迟是 BS，那么替代方案是什么？” 加入 P99 CONF 2024 社区 就像 P99 CONF 社区一样，我们痴迷于持续优化。这将我们带到了 P99 CONF 2024。
38210编辑于 2024-09-07 - 来自专栏10km的专栏
c语言下利用p99:模拟实现try-cath-finally
的开源项目，P99提供了大量的的宏和函数定义，用于简化C编程,。 说白了，P99提供的就是一大堆.h头文件，.h文件中定义了大量的宏函数，利用这些宏函数可以简化C代码开发。 比如下面用了P99中提供的例程实现了C++中才有的try-catch-finally语句： #include <stdio.h> #include <stdlib.h> #include <string.h 手册 《P99 - Preprocessor macros and functions for C99 and C11 》。 为了快速熟悉P99的内容建议从分类说明入手《Modules》 安装 p99提供的只是一堆头文件，所以从http://p99.gforge.inria.fr/ 这里下载p99.zip或p99.tgz解压到自己的项目文件夹下
87210发布于 2019-05-25 - 来自专栏10km的专栏
c语言宏编程:P99:if语句使用实例,P99_IF_EMPTY
childId,type) (type*)ncsGetChildObj(user_admin_wdiget->hwnd,childId) 唉，为这么点事儿，就定义俩宏，太麻烦了，最好在用一个宏搞定，这时就可以用到P99
78210发布于 2019-05-25 - 来自专栏Rust 编程
P99 Conf Talk 汇总 | Rust 在高性能低延迟系统中的应用
P99 Conf[1] 是一个由 Scylladb[2] 组织的新的跨行业的线上Conf，为工程师而设。 P99 CONF只面向技术人员，你的老板不在邀请之列。 四场演讲分别为： Rust，莱特定律和低延迟系统的未来[3] 芜湖！我用 Rust 重写了推特的内存缓存框架 Pelikan 模块 ！ Glommio 中，请看代码 ：https://github.com/bryandmc/glommio/blob/xdp/glommio/src/net/xdp_socket.rs 参考资料 [1] P99
2.2K20发布于 2021-10-13 - 来自专栏nginx
深入解析请求响应时间：P99、P95、P90 和 P75 及其优化方法
具体来说，P99、P95、P90 和 P75 就是常见的百分位数，它们帮助我们了解数据的分布情况，特别是响应时间的表现。 P99：99%的请求耗时小于或等于 P99 指定的时间。 这些百分位数能够揭示出系统中大多数请求的响应时间分布，并且帮助我们聚焦于 长尾请求 和 极端请求 的优化。 2. 2.4 P99 - 系统性能的极限 P99 = 694ms 表示 99%的请求 的响应时间都小于或等于 694ms，而只有 1% 的请求的响应时间超过了这个值。 P99 越高，说明系统在某些特殊情况下可能会产生非常长的响应时间，影响少数用户的体验。因此，优化 P99 是提升系统稳定性和用户体验的一个关键步骤。 3. 在性能优化的过程中，特别需要关注 P99，因为它反映了 最差的 1% 请求 的响应时间。提升 P99 可以显著提高系统在高并发和高负载下的表现，从而提升用户的整体体验。
1.8K10编辑于 2025-11-15 - 来自专栏PingCAP的专栏
Prometheus 常用函数 histogram_quantile 的若干“反直觉”问题
P99 耗时 50ms，那么推测 B 过程的 P99 耗时情况是？ P99=50 B = 1, 1, ... 1, 1, 50 // 共 100 条数据，P99=1 X = 51, 51, ... 51, 100, 100 // 共 100 条数据，P99= 问题3：服务 X 由顺序的 A，B 两个步骤完成，其中 A 过程 P99 耗时 100ms，B 过程 P99 耗时 50ms，那么推测服务 X 的 P99 耗时情况是？ 路径统计 P99 耗时为 100ms，B 路径统计 P99 耗时 50ms，那么推测服务 X 的 P99 耗时情况是？ 如果测得 X 保存数据耗时的 P99 为 100ms，那么推测 M 请求数据库的 P99 耗时情况是？
7.8K11发布于 2020-02-02 - 来自专栏MGS浪疯 Blog
2核2G服务器跑270M LLM模型[测试]
否总运行时间:130.61秒每秒请求数(RPS):0.77总输出token数:4640模型名称:gemma3:270m延迟统计(单位:秒):平均延迟:1.306延迟P50:1.273延迟P95:1.917延迟P99 :2.392Token生成速度(tokens/sec):平均速度:35.81速度P50:39.04速度P95:14.93速度P99:8.08首token响应时间(单位:秒):平均时间:0.413TTFTP50 :6.756Token生成速度(tokens/sec):平均速度:9.23速度P50:9.26速度P95:1.12速度P99:1.06首token响应时间(单位:秒):平均时间:4.134TTFTP50 Token生成速度进一步恶化至1.43tokens/s（P99仅0.05tokens/s），表明模型几乎无法有效处理并发请求。 但尾部延迟明显增加（P99延迟达4.47秒，TTFTP99达3.55秒），表明长时间运行下系统可能出现轻微资源累积压力或调度波动。整体仍适合低频、稳定推理任务，但对响应一致性要求高的场景需谨慎。
28730编辑于 2026-02-07 - 来自专栏FunTester
性能测试中过滤异常的响应时间
int size = c.size() double min = c.first() double max = c.last() double p99 def mid = c.get(size / 2 as Integer) new FunIndex(avg: avg, mid: mid, min: min, max: max, p99 : p99, p999: p999, p95: p95) } /** * 统计结果 */ static class FunIndex extends AbstractBean { Double avg Double mid Double min Double max Double p99 p95 @Override String toString() { "平均值:$avg ,最大值$max ,最小值:$min ,中位数:$mid p99
1.1K20编辑于 2022-04-01 - 来自专栏腾讯技术工程官方号的专栏
Prometheus 指标值不准：是 feature，还是 bug？
于是，在 PTS 还拥有 P99 的那些年，我们三番五次、屡屡破防，最终忍痛拿掉了 P99： histogram 百分位（percentile）不准，这是为啥呢？ 下面以 P99 为例说明（其他百分位也不一定准，但 P99 经常离最大的谱）。 首先，搬运 ChatGPT 老师对 P99 的概念介绍： P99 是一个统计术语，代表着第99百分位数（99th percentile）。 在性能监控和服务质量评估中，P99 常用来衡量响应时间或延迟的指标。具体来说，P99 的含义是在所有测量值中，有 99% 的数据点小于或等于这个值，而只有 1% 的数据点大于这个值。 简单理解 P99 是怎么得来的：把样本按值的大小依序排队，队伍里第 99% 个样本的值，就是 P99。
1.2K21编辑于 2024-05-15 - 来自专栏腾讯云可观测专栏
Prometheus 指标值不准：是 feature，还是 bug？
于是，在 PTS 还拥有 P99 的那些年，我们三番五次、屡屡破防，最终忍痛拿掉了 P99： histogram 百分位（percentile）不准，这是为啥呢？ 下面以 P99 为例说明（其他百分位也不一定准，但 P99 经常离最大的谱）。 首先，搬运 ChatGPT 老师对 P99 的概念介绍： P99 是一个统计术语，代表着第99百分位数（99th percentile）。 在性能监控和服务质量评估中，P99 常用来衡量响应时间或延迟的指标。具体来说，P99 的含义是在所有测量值中，有 99% 的数据点小于或等于这个值，而只有 1% 的数据点大于这个值。 简单理解 P99 是怎么得来的：把样本按值的大小依序排队，队伍里第 99% 个样本的值，就是 P99。
1.7K42编辑于 2024-12-16 - 来自专栏Spark学习技巧
实时数仓不保障时效还玩个毛？
「报警机制」：定时（比如 1min/次） check 监控指标的 P99 指标。 「报警阈值」：判断监控指标的 P99 指标是否超过某个阈值（比如 5 min）。 「报警机制」：定时（比如 1min/次） check 监控指标的 P99 指标。 「报警阈值」：判断监控指标的 P99 指标是否超过某个阈值（比如 5 min）。 「报警机制」：定时（比如 1min/次） check 监控指标的 P99 指标。 「报警阈值」：判断监控指标的 P99 指标是否超过某个阈值（比如 180s）。 「报警机制」：定时（比如 1min/次） check 监控指标的 P99 指标。 「报警阈值」：判断监控指标的 P99 指标是否超过某个阈值（常用 180s）。 「报警机制」：定时（比如 1min/次） check 监控指标的 P99 指标。 「报警阈值」：判断监控指标的 P99 指标是否超过某个阈值（常用 180s）。
1.4K30发布于 2021-07-27 多模态搜索时代：哪些向量数据库能同时驾驭文本与图像？腾讯云方案深度解析
核心优势 腾讯云VectorDB 文本+图像+音频 P99 IVF/DiskANN 按量付费/包年包月 AI原生设计，支持混合检索；千亿级规模日均1600亿次请求，成本低于行业40% Milvus 文本+图像 P99 HNSW/IVF/DiskANN 开源免费 云原生架构，支持GPU加速；社区活跃，适合技术团队自主运维 Pinecone 文本+图像 P99 自动优化索引 $0.1/GB/月起 Serverless架构，零运维；集成OpenAI生态，适合快速原型开发 Weaviate 文本+图像+视频 P99 HNSW/IVF 开源免费 内置CLIP模型，支持零样本分类；GraphQL接口灵活 Qdrant 文本+图像 P99
47510编辑于 2025-12-17- 来自专栏【腾讯云开发者】
GitHub最火开源监控系统Prometheus，我却发现了它的一个Bug(feature)？
——“P99 百分位的值，竟比最大值还高？” ——“用不同时间范围计算 rate，出来的曲线天壤之别？” 于是，在 PTS 还拥有 P99 的那些年，我们三番五次、屡屡破防，最终忍痛拿掉了 P99： P99 是一个统计术语，代表着第99百分位数（99th percentile）。 在性能监控和服务质量评估中，P99 常用来衡量响应时间或延迟的指标。具体来说，P99 的含义是在所有测量值中，有 99% 的数据点小于或等于这个值，而只有 1% 的数据点大于这个值。 简单理解 P99 是怎么得来的：把样本按值的大小依序排队，队伍里第 99% 个样本的值，就是 P99。 让我们看一个简单案例，模拟每秒产生一个新的 HTTP 请求耗时的观察值，然后计算其 P99。
58420编辑于 2024-05-21 - 来自专栏深度学习与python
好大夫在线在解构服务风险治理方面的实践
探 险 不知道大家有没这样的疑问： 夺命线 p99 到底是个啥，p50，p75，p95 这一家子暗藏什么玄机？ 故此选择 SLI：接口延迟 -p99。并设定了 SLO：后端服务 p99<100ms，前端服务 p99<600ms。 服务延迟就是符合正太分布满足长尾效应，故此我们取 p99 作为 SLI。在服务延迟中，如果 p50,p75,p95,p99 无限接近，服务越稳定，p99 值越小服务具备了更高的抗压性，也就是弹性更强。 p99 是个神奇的指标，我们以后会经常遇到。 好，关于为何选择 p99，应该大家都清楚了吧。接下来我们就围绕降低 p99 去挖掘服务存在的风险点。 寻找风险 哪些因素会影响接口延迟呢？ 最终达到后端服务 p99 小于 100ms，前端服务 p99 小于 600ms。
52220编辑于 2021-12-16 - 来自专栏大数据-BigData
RedisJson 横空出世，比 ES 快7 倍，惊爆了！
RedisJSON* 的 p99 低于 2.61 毫秒，而 ElasticSearch p999 搜索达到 10.28 毫秒。 在写入时，MongoDB 和 RedisJSON* 即使在 p99 时也能保持亚毫秒级的延迟。 RedisJSON* 是更稳定的解决方案，其 p99 读取时间为 3 毫秒，而 Elastic 的 p99 读取时间为 162 毫秒。 在更新时，RedisJSON* 保留了 3 毫秒的 p99，而 ElasticSearch 则保留了 167 毫秒的 p99。 RedisJSON* 将 p99 保持在 33 毫秒以下，而 ElasticSearch 上的 p99 百分位数为 163 毫秒，高出 5 倍。
76520编辑于 2022-09-16 - 来自专栏颇忒脱的技术博客
各大API网关性能比较
响应时间分布 光看平均响应时间是不够的，我们还得看P50、P90、P99、P99.9以及Max响应时间（可惜Gatling只能设置4个百分位，否则我还想看看P99.99的响应时间）。 2）观察P99、P99.9、P99.99的响应时间能够帮助你估算用户体验。假设你有一个页面会发出5次请求，那么这5次请求均落在P90以内概率是多少？ 如果你的P99=10s，那么用户只有5%的概率会在访问页面的时候超过10s。如果P99.9=10s，则有0.4%的概率。 可以看到几个很有趣的现象： Haproxy、Nginx的P50、P90、P99、P99.9、Max都是逐渐递增的。 Netty的P50、P90、P99、P99.9是很平坦的，Max则为基准值的207%。 Spring Cloud Gateway和Zuul2则是相反的，它们的平面呈现下降趋势。
6.7K00发布于 2019-04-18 - 来自专栏CNCF
Linkerd基准测试
在500rps条件下，Linkerd的p99延迟为6.7ms，比无服务网格3.1ms的基线p99延迟多3.6ms。 相比之下，在500rps的情况下，Istio的p99延迟为643ms，几乎比Linkerd的p99慢100倍。 （更新：Kinvolk重新调优的Istio基准将Istio的p99从Linkerd的100倍降低到26x和59x。它还将Istio的p999降到不到一秒，不过仍然是Linkerd的两倍。） Linkerd的p99从6.7ms提升到7ms，超过了“无服务网格”基线的4ms，而Istio的p99整整4.4分钟（！）。 在500rps条件下，Istio的p99是Linkerd的100倍。在600rps条件下，Istio的延迟始终是不可接受的。
87010发布于 2019-12-04 - 来自专栏速入大数据
别等系统“凉了”才响铃：聊聊延迟敏感系统的监控与报警设计
高价值用户大客户核心风控请求所以延迟敏感系统，第一条铁律：别用平均值骗自己三、监控设计的第一原则：分位数，比均值值钱真正有用的延迟监控，至少要盯这几个：P50：系统“日常体感”P90/P95：开始影响用户体验P99 histogram_quantile(0.99,sum(rate(http_request_duration_seconds_bucket[1m]))by(le))我自己的习惯是：P50：看趋势P95：设一级报警P99 ：设强报警+自动降级记住一句话：P99是系统良心指标，P999是系统底线。 半夜响白天响周末响啥都响还经常是误报最后的结局就是：真正出事的时候，大家已经对报警免疫了我自己总结的报警三原则：原则一：报警要“贴业务”不要只报：“P99延迟>2s”而是：“支付接口P99延迟>2s，影响订单成功率 推荐逻辑：连续3分钟或5分钟内4次超阈值示意规则：展开代码语言：TXTAI代码解释P99_latency>2000ms持续3分钟原则三：报警要分级我一般这样分：P95超阈值：钉钉/飞书提醒P99超阈值：
20510编辑于 2026-01-12
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号