Cursor写性能压测问题提示词怎么生成多个角度

在线上系统的日常运维中，性能压测是检验系统韧性的关键手段。但很多压测脚本要么过于简单，要么流于形式，无法真正暴露深层次问题。这篇文章的目标，就是给出能精准定位系统瓶颈、模拟资源争用、触发数据倾斜、混压冷热路径以及验证依赖服务降级这五大典型场景的压测提示词。这些场景，每一个都对应着线上真实会让人头疼的问题。下面，我们就逐一拆解，看看如何让Cursor生成真正有效的压测脚本。

定位数据库连接池耗尽问题

先从数据库连接池说起，这是系统最脆弱的环节之一。目标是聚焦DBCP连接池满载后的排队与超时行为，明确告诉Cursor，不关心缓存，也不关心前端响应。

怎么模拟？用100个并发线程，每个线程执行5次订单查询。注意，每次查询后强制sleep 50毫秒，目的是模拟业务逻辑处理耗时。然后，在第6次查询时，立即发起请求，这样做的核心在于制造“连接复用失效”的现象，迫使新请求去等待连接。

那么，如何判断脚本是否生效？需要让Cursor输出几个关键指标：每一轮中，getConnection()方法阻塞了多少毫秒、连接池activeCount的峰值是多少、以及是否抛出了包含“waited for connection”关键词的SQLException。这些数据是定位问题的铁证。

模拟Redis热点Key打爆带宽

接下来，我们看看Redis。热点Key是线上最常见的性能杀手之一。这里有两种压测思路：

方法一：构造单Key高频读写组合

让AI生成一个压测脚本，持续对一个热点Key，比如“hot:order:status:10086”，执行GET、INCR、EXPIRE这三连操作。QPS固定为800，持续时间90秒。这里有个关键：必须禁用pipeline。为什么？因为我们要复现的是网络包碎片化现象，如果用了pipeline，请求会被合并发送，就达不到模拟带宽压力的效果了。

方法二：混合Key分布制造带宽挤压

更贴近真实环境的做法是混合压力。设置70%的请求打向1个热点Key，25%打向100个随机Key，剩下的5%打向10个超大Value的Key（每个value至少1MB）。这个比例并非拍脑袋，它需要匹配你线上监控中Redis带宽使用率超过92%时的流量分布。在压测脚本中，应该把这层约束注明。

触发JVM GC导致STW抖动

JVM的GC问题，尤其是Stop-The-World，对系统响应时间的冲击是毁灭性的。如何复现？需要明确的内存参数约束：-Xms4g -Xmx4g，指定使用G1GC，最大GC暂停时间目标设为200毫秒。更关键的是，强制要求压测进程每30秒分配一次128MB的byte[]数组，并且不释放引用。

这个操作在代码层面很好实现，直接把上述JVM参数和内存分配逻辑粘贴进Cursor对话框即可。AI会自动注入GC日志收集指令，例如使用-Xlog:gc*:file=gc.log。但需要留意的是，要手动确认它没有遗漏-XX:+PrintGCDetails这类关键参数。

生成的报告必须包含每次Full GC前后的堆内存使用占比、STW时长的柱状图，以及是否因Allocation Failure触发了Young GC的连锁反应。

验证下游HTTP服务熔断阈值

说到熔断机制，很多人会觉得这不就是设置一个阈值嘛。但如何验证它是否真的按预期工作？

第一步：定义故障注入规则

对下游支付服务注入三种故障：30%的请求返回503状态码，并且响应头部要有Retry-After: 30；20%的请求TCP连接超时（connect_timeout设定为800毫秒）；10%的请求TLS握手失败。故障注入的路径，可以伪造一个接口来模拟。

第二步：绑定熔断器行为

熔断器的行为必须清晰：当连续5次调用，且失败率超过45%时，Hystrix应开启熔断。之后10秒内，所有请求直接走fallback逻辑。10秒后进入半开状态，允许一个试探请求。如果试探成功，熔断关闭；如果失败，则重新计时。

第三步：输出判定依据

压测报告里，需要提供一条简单的curl命令来验证熔断状态：curl -I https://api/v1/order | grep "X-Circuit-State"。返回值必须是OPEN、CLOSED或HALF_OPEN三者之一，清晰明了。

复现Kafka消费者组Rebalance风暴

最后，是Kafka场景下的消费者组Rebalance。这是一个老生常谈，却又非常棘手的问题。复现它的关键在于，要让消费者进程非优雅退出。

启动5个消费者实例，订阅同一个topic，并配置相同的group.id。前30秒保持正常消费。从第31秒起，直接对其中2个实例执行kill -9。为什么要用kill -9？因为只有非优雅退出，才不会主动发送离开请求给Coordinator，才能触发Coordinator的心跳超时，进而引发真正的Rebalance。

观察剩余3个实例的Rebalance耗时、Lag增长曲线，以及__consumer_offsets分区写入量的突增情况。AI生成的脚本里，必须包含定时快照命令：每隔5秒执行一次kafka-consumer-groups.sh --describe，持续捕获2分钟。这样才能完整记录整个Rebalance风暴的演变过程。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Cursor写性能压测问题提示词怎么生成多个角度要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题