副标题 / 摘要

CGI 每个请求启动一个进程，带来巨大启动与切换成本。本文解释为什么 CGI 难以扩展。

目标读者

  • 学习 Web 架构的开发者
  • 关注性能瓶颈的工程师
  • 需要理解历史技术限制的人

背景 / 动机

CGI 是早期 Web 方案，但在高并发场景很快暴露性能问题。
理解原因有助于理解现代 Web 服务器的演进。

核心概念

  • 进程模型：每请求一个进程
  • 上下文切换：进程切换成本高
  • 冷启动：启动解释器与加载环境

实践指南 / 步骤

  1. 理解 CGI 的执行流程
  2. 评估进程启动与切换开销
  3. 比较常驻进程模型（FastCGI/WSGI）
  4. 选择更高效的服务模型

可运行示例

# 模拟进程启动成本
import subprocess
import time


def spawn_cost(n=5):
    start = time.time()
    for _ in range(n):
        subprocess.run(["/bin/true"], check=True)
    return time.time() - start


if __name__ == "__main__":
    print(spawn_cost())

解释与原理

CGI 需要频繁启动进程与加载运行环境，导致延迟高、吞吐低。
常驻进程模型可以复用资源，显著提升性能。

常见问题与注意事项

  1. CGI 一定不能用吗？
    低并发场景仍可使用，但成本高。

  2. FastCGI 如何改善？
    通过常驻进程减少启动开销。

  3. 现代框架为什么快？
    因为多采用常驻服务与连接复用。

最佳实践与建议

  • 生产环境避免 CGI
  • 使用 WSGI/ASGI/容器化服务
  • 关注进程数与上下文切换

小结 / 结论

CGI 的瓶颈来自“每请求一进程”的模型。
现代架构通过常驻进程与连接复用解决了这一问题。

参考与延伸阅读

  • CGI 规范
  • FastCGI 文档

元信息

  • 阅读时长：6~8 分钟
  • 标签：CGI、性能
  • SEO 关键词：CGI 扩展性, 进程模型
  • 元描述：解释 CGI 扩展性差的原因。

行动号召（CTA）

对比 CGI 与常驻进程模型的响应时间，看看差距有多大。