IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签:Pipelining

共 2 篇相关文章

IT 累计浏览 1,861

通过Twemproxy提升PHP/Redis的性能

这篇文章讲的是如何用 Twemproxy 这个看似“古老”的 Redis 代理,来解决 PHP 应用中难以实现真正连接池的性能痛点。作者没有从复杂的理论入手,而是直接从一个已知的“曲线救国”方案(借助 Nginx Stream 模块)出发,转而尝试用现成的 Twemproxy 来达到相同目的。 核心方案是让 Twemproxy 与 PHP 部署在同一台服务器上,并通过本地 Unix Domain Socket 进行连接。经过初步压测,作者发现默认的单进程 Twemproxy 并没有带来性能提升,问题根源在于其单线程架构无法利用多核 CPU。因此,他调整策略,按照 CPU 核心数启动了多个 Twemproxy 进程,并让 PHP 请求随机分配到这些进程对应的 Socket 上。 最终的测试结果非常直观:性能提升了整整 100%。作者在文中指出了性能跃升的关键因素:Twemproxy 的 Pipelining 功能将多个请求打包发送,减少了网络 RTT,同时还优化了连接建立过程。文章不仅给出了具体的配置文件示例和压测命令,还提到了如 mbuf-size 设置和绑定 CPU 等实战细节,为读者提供了可直接参考的落地步骤。

IT 累计浏览 7,415

记Redis那坑人的HGETALL

这篇讲的是Redis的HGETALL命令可能引发的性能陷阱。作者从亲身踩坑经历出发,描述了在HASH字段从十几个扩展到一百多个,并使用Pipelining批量获取时,意外导致服务器宕机的过程。 问题的根因在于Redis的单线程模型:当执行HGETALL时,Redis必须遍历每个字段来获取数据,其消耗的CPU时间与字段数量成正比。配合Pipelining一次性发起大量HGETALL请求,单个线程被长时间占用,从而阻塞了所有其他命令,导致服务不可用。 文章随后分析了三种解决思路:引入多线程的Memcached作为缓存层;部署多个Redis实例以利用多CPU核心;或采用序列化字段冗余,将多个字段合并为一个“all”字段存储,从而将多次HGETALL简化为一次HGET,大幅减少操作数。作者最终指出,技术坑就是用来踩的,重要的是从中爬出来并找到解决方法。