EKS集群中WordPress响应慢于Minikube的问题排查问询

在eks Pod中运行无持久卷的WordPress（测试场景下MySQL及所有文件均存放在Pod文件系统中），执行curl http://localhost的平均响应时间为1.5s；相同配置在minikube集群中运行时响应时间仅为0.5s，两者的数据库、PHP内容均从同一备份恢复，完全一致。
测试使用官方wordpress:php7.4-apache镜像，集群节点配置为16GB内存、4vCPU，补充验证显示：使用与EKS节点相同的AMI创建独立EC2实例运行相同配置，可复现相同的慢响应问题，已提供节点监控、存储卷监控、Xhprof性能分析数据供排查参考。

• 先对比底层计算性能差异：PHP属于单线程密集型应用，单核心CPU性能直接影响响应速度。先确认minikube运行环境和EC2实例的CPU型号、代次、睿频配置，同规格vCPU的不同硬件（比如x86的不同代次、是否为Graviton架构）单线程性能差距可达到1倍以上，可使用sysbench cpu --cpu-max-prime=20000 run直接测试两边的单线程CPU性能做量化对比。
• 排查AMI系统配置差异：因为同AMI的EC2也能复现问题，优先排查AMI的操作系统配置：是否开启了CPU节能模式（C-state、P-state调整导致CPU降频）、透明大页（Transparent Huge Page）配置是否异常、磁盘IO调度器是否和minikube环境不同，另外导出两边的sysctl -a配置做diff，重点看网络、文件句柄、虚拟内存相关参数的差异。
• 排查资源限制与运行时配置：检查EKS Pod是否配置了CPU limits导致CPU节流（throttling），即使节点整体CPU空闲，不合理的CPU limits也会导致单Pod响应变慢，可查看Pod的CPU throttling指标确认；另外检查Apache、PHP-FPM的进程数配置是否和运行环境的CPU核心数匹配，避免出现进程排队等待调度的情况。
• 排查存储IO性能差异：虽然没有使用持久卷，但Pod临时存储底层是EC2的块存储，对比minikube的存储介质（比如本地SSD）和EC2卷的类型（gp2/gp3/io1等）、IOPS/吞吐量配置，WordPress运行时需要加载大量PHP小文件，小文件随机读性能不足会直接拉长响应时间，可使用fio测试两边4K随机读的性能做对比。
• 基于Xhprof结果做细粒度定位：对比minikube和EKS环境下Xhprof的函数调用耗时占比，重点查看是否有数据库查询、文件读取、网络请求类函数的耗时明显偏高，定位到具体耗时模块后再针对性排查。
• 排查网络额外开销：分别在两个环境用tcpdump抓包看请求全链路耗时，确认是否存在DNS解析延迟、外部接口调用超时、localhost回环链路配置异常的问题，由于独立EC2也能复现问题，可以先排除K8s CNI插件带来的网络开销影响。

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