Jmeter无GUI环境下测试Memcached的Set/Get操作不生效问题咨询

• TCP采样器默认响应码规则误解：TCP采样器返回的200仅代表TCP连接建立、数据发送成功，不代表Memcached服务端成功执行了set操作。你需要检查响应内容是否包含STORED字段，这才是set操作成功的标识。
• 行尾符变量未正确解析：请确认你配置的${CR}和${LF}变量已正确生效，部分预处理器配置遗漏会导致变量原样发送，Memcached无法识别不符合协议规范的请求，会静默忽略不返回错误。
• set命令字节长度不匹配：你配置的set命令中声明value长度为9，若实际发送的memcached字符串前后存在多余空格、换行，会导致长度不匹配，Memcached会拒绝执行该写入操作。
• TCP采样器结束符配置错误：若你未将TCP采样器的「结束符字节」设置为10（对应LF），会导致JMeter未完整发送整个请求包，或提前中断接收服务端响应，操作未实际执行。
• 脚本编码不兼容：Windows环境编写的JMX脚本默认编码可能为GBK，上传到Linux主机后解析乱码，导致发送的请求内容不符合Memcached协议要求。

• 开启TCP采样器调试日志：运行脚本时追加日志级别参数，直接输出收发的原始TCP内容：

  ./jmeter -n -t "Sample.jmx" -l testresults.jtl -Jlog_level.jmeter.protocol.tcp.sampler=DEBUG
  

  运行后查看jmeter.log文件，即可确认实际发送的请求内容是否符合Memcached协议规范。
• 存储响应内容到结果文件：追加参数开启响应内容存储，直接查看Memcached返回的操作结果：

  ./jmeter -n -t "Sample.jmx" -l testresults.jtl -Jjmeter.save.saveservice.response_data=true
  

  生成的jtl文件中可查看服务端返回的内容，若存在CLIENT_ERROR、ERROR等字段即可定位具体的协议错误原因。
• 本地抓包验证请求内容：在远程Memcached主机上用tcpdump抓端口流量，直接查看ASCII格式的请求内容：

  tcpdump -i any port 11211 -A
  

  运行JMeter脚本的同时执行抓包命令，即可直观对比JMeter发送的请求和手动telnet发送的请求差异。

• 若无需复杂的JMeter联动场景，可直接使用mutilate、memcached-tool等专用Memcached压测工具，无需GUI操作，直接在Linux无头环境下安装运行，原生支持批量set、get压测，配置更简单，性能开销更低。

内容的提问来源于stack exchange，提问作者S Yuki