CodeIgniter 3 集成Redis作为会话管理器性能低下原因排查

问题描述 #

我正在将基于CodeIgniter 3的应用迁移为使用Redis作为会话管理器，但由于应用存在大量AJAX请求，发现请求耗时大幅增加：原本11个请求共耗时300ms，现在需要11s。

我对代码做了修改，在每个控制器开头获取所有会话数据并存入模型，之后调用session_write_close()，请求耗时有所改善，平均降至3-5s，但仍未达到理想状态。

查阅CodeIgniter文档时看到：

CodeIgniter’s Session library does NOT use the actual ‘redis’ session.save_handler.

因此我决定禁用CodeIgniter原生会话的自动加载，在控制器开头直接调用session_start()，再获取会话数据并填充模型。令我惊讶的是，应用读取数据的耗时再次降至300ms以内，即使不再使用session_write_close()，速度也保持不变。

请问CodeIgniter在连接和读取Redis会话时耗时较长的原因可能是什么？

可能的原因分析 #

• 会话锁机制差异
  CodeIgniter 3的原生会话库自定义了Redis会话锁逻辑，而非依赖PHP原生Redis会话处理器的锁实现。当大量AJAX并发请求到来时，CI的锁机制会导致请求排队等待，每个请求都需等待前一个会话锁释放，进而造成累积耗时。而PHP原生session_start()使用的Redis会话处理器锁机制更高效，不会产生严重阻塞。

• 额外的序列化/反序列化开销
  CI会话库会对会话数据执行自定义序列化/反序列化操作（区别于PHP原生serialize()），每次读写会话都要额外处理，增加了CPU和IO负担。而PHP原生Redis会话处理器直接使用PHP标准序列化方式，操作更轻量化。

• Redis连接管理低效
  CI会话库在每次请求中可能重复创建Redis连接，或连接池管理不佳，导致每次会话操作都需重新建立连接；而原生session_start()依赖的PHP Redis会话处理器通常会复用连接，减少了连接建立的耗时。

• 冗余的会话附加逻辑
  CI会话库自带会话过期检查、IP/UA验证、自动更新会话数据等附加功能，这些逻辑会在每次请求中执行，即便应用不需要这些功能，也会产生额外性能开销。直接使用session_start()仅执行基础的会话读写，无此类冗余逻辑。

• 会话写入时机不合理
  CI会话库默认在请求结束时自动写入会话数据，即便会话数据未修改，也可能触发写入操作，增加了Redis的IO负载。而PHP原生会话处理器仅在会话数据被修改时才执行写入，减少了不必要的Redis操作。

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