在2000年代初期，CGI（通用网关接口）程序是使网站动态化的主要方式，通常用Perl或C语言编写。CGI机制简单但强大，服务器接收请求后，通过环境变量传递请求信息，生成新进程执行CGI程序，并通过stdin和stdout处理请求和响应。CGI程序在处理完单个请求后退出，自动释放资源，确保了代码的可靠性。开发者体验良好，部署新版本只需替换文件，无需重启服务器。

文章《Serving 200 million requests per day with a cgi-bin》探讨了在现代硬件上使用CGI（Common Gateway Interface）技术处理高并发请求的可行性。CGI是早期动态网站开发的主要技术，通常使用Perl或C编写。其工作原理是：当Web服务器接收到请求时，会启动一个新的进程来执行CGI程序，程序通过环境变量获取请求信息，处理请求后通过标准输出返回HTTP响应。

主要内容总结：

1. CGI的工作原理：

   • Web服务器接收请求后，设置环境变量并启动CGI程序。
   • CGI程序通过标准输入读取请求体，处理请求后通过标准输出返回响应。
   • 每次请求结束后，CGI程序退出，释放所有资源。

2. 早期Web服务器的限制：

   • 早期服务器通常只有1-2个CPU和1-4GB内存，Apache等服务器会为每个连接创建一个进程，限制了并发处理能力，容易导致“Slashdot效应”（因流量激增导致服务器崩溃）。

3. 现代硬件的优势：

   • 现代服务器拥有更多CPU核心和更大的内存，CGI程序能够充分利用多核处理器的优势，显著提升性能。

4. 性能测试：

   • 作者在16线程的AMD 3700X服务器上进行了性能测试，使用Apache和自定义的Go net/http服务器运行CGI程序，并使用plow工具进行并发请求测试。
   • 测试结果显示，CGI在现代硬件上能够处理2400+请求/秒，相当于每天处理2亿+请求。

5. 示例代码：

   • 作者编写了一个简单的留言板程序guestbook.cgi，使用Go语言和SQLite数据库实现，代码已开源在GitHub上。

6. 测试结果：

   • Apache服务器：在写入和读取测试中，分别达到了2468.836 RPS和1959.026 RPS。
   • Go net/http服务器：在写入和读取测试中，分别达到了2742.432 RPS和2469.613 RPS。

结论：

尽管CGI技术在现代Web开发中已不再是主流选择，但在现代硬件上，它仍然能够高效处理大量请求，展示了其在高并发场景下的潜力。

图片：

• Image 1: cgi-bin writes Apache benchmark
• Image 2: cgi-bin reads Apache benchmark
• Image 3: cgi-bin writes gohttpd benchmark
• Image 4: cgi-bin reads gohttpd benchmark

评论内容总结：

1. Apache Tomcat 11的推荐

   • 作者Traubenfuchs推荐使用Apache Tomcat 11，认为它可以轻松处理.jsp文件和Java Servlet应用程序，并且通过共享JVM、数据库连接池和缓存等资源来提升性能。
   • 引用：“You can just dump .jsp files or whole java servlet applications as .war file via ssh and it will just work!”
   • 引用：“One shared JVM for maximum performance!”

2. 对Apache选择的质疑

   • 作者sugarpimpdorsey认为Apache已经不是最佳选择，除非有遗留系统依赖它。
   • 引用：“The only reason for still running Apache is you have legacy cruft that requires Apache (like .htaccess).”

3. CGI与现代硬件的性能讨论

   • 作者simonw指出，现代硬件使得短生命周期进程的性能开销不再像过去那样显著，CGI模型在AWS Lambda中得到了重生。
   • 引用：“modern hardware means that it really isn't prohibitively expensive to do that any more.”
   • 引用：“AWS Lambda described as the CGI model reborn.”

4. CGI的优势与局限性

   • 作者10000truths强调了CGI在多租户场景中的隔离优势，如进程隔离和资源分配。
   • 引用：“A bug in one request doesn't corrupt another request, due to process isolation.”
   • 引用：“You can use per-tenant cgroups to fairly allocate resources like memory, CPU and disk/network I/O.”

5. 对FastCGI的兴趣

   • 作者petee和znpy建议进行FastCGI的比较，认为FastCGI比CGI更适合现代需求。
   • 引用：“A fastcgi comparison would be interesting.”
   • 引用：“At the very least go for FastCGI, for christ’s sake…”

6. 对复杂架构的反思

   • 作者p0w3n3d和apgwoz反思了现代复杂架构的必要性，认为简单的技术（如CGI）在强大硬件下仍然有效。
   • 引用：“We’re moving towards complicated architecture while having possibility to use good ol’ tech with newest CPUs.”
   • 引用：“you could probably get pretty far with CGI and adjusting capabilities and such, with far less complexity.”

7. 对基准测试工具的质疑

   • 作者kiitos对文章中使用的基准测试工具plow提出了质疑，认为其结果不可靠。
   • 引用：“lots of issues in that repo, no tests, etc. etc.”
   • 引用：“The results in the README are also pretty clearly unsound!”

8. 对过度复杂化的批评

   • 作者TZubiri批评了过度依赖复杂技术（如Kubernetes、Kafka等）的现象。
   • 引用：“you need Kubernetes and Kafka and RabbitMQ and Graphana and a 300K$/day bill.”

总结：评论中对Apache、CGI和FastCGI的性能和适用性进行了广泛讨论，部分人认为现代硬件使得CGI等传统技术仍然有效，而另一些人则推荐使用更现代的解决方案如FastCGI。同时，也有对基准测试工具和过度复杂架构的批评。