zlacker

"First people wrote cgi-bin scripts in Perl, which were not efficient because they forked a process for each request"

I don't recall the sequence of events that way. That is, there was regular cgi, then mod_php with problems similar to mod_perl...then later fastcgi options existed for both.

>>tyingq+(OP)
Wait. Isn't fastcgi essentially the same as mod_php? IPC with a long-running process rather than forking and capturing stdout?

What's the newer fastcgi php method that isn't mod_php?

>>torste+m1
FastCGI and mod_php are both ways of running PHP on a web server, but they differ in how they achieve this.

FastCGI is a protocol that allows a web server to communicate with external programs that provide dynamic content, such as PHP scripts. In FastCGI, the web server launches an external program, called a FastCGI process manager, which is responsible for starting and managing a pool of long-running PHP processes. When a request for a PHP script comes in, the FastCGI process manager assigns one of these processes to handle the request, and the process generates the dynamic content and sends it back to the web server.

mod_php, on the other hand, is an Apache module that embeds the PHP interpreter directly into the Apache web server. This means that PHP scripts are executed directly within the Apache process, without the need for an external process manager.

While both FastCGI and mod_php are ways of running PHP on a web server, they differ in their implementation and how they handle requests for PHP scripts.

>>torste+m1
The mod_* meant apache modules managing the process pool without a socket connection to a separate pool manager. Which meant issues there could affect the webserver, which was typically also serving static assets, etc.

>>tyingq+X1
You're right, I guess I misremembered how I set my web server up. I'm using mod_proxy_fcgi with php-fpm, not mod_php.

>>dysarr+A1
Is there no rule about GPT/bot responses on HN?

>>torste+K8
We don't allow bots on HN and ban such accounts.

>>dang+bm
One ChatGPT reponse to:

> Write an explanation for the user who posted the following comment: "Wait. Isn't fastcgi essentially the same as mod_php? IPC with a long-running process rather than forking and capturing stdout? What's the newer fastcgi php method that isn't mod_php?"

is:

> FastCGI and mod_php are similar in that they both use a long-running process to handle PHP requests, rather than creating a new process for each request. However, they differ in how they are implemented and how they interact with the web server.

FastCGI is a protocol that allows a web server to communicate with external programs, such as PHP, to handle dynamic content. It is typically used with web servers such as Apache or Nginx. In the case of PHP, the web server uses FastCGI to send PHP requests to a PHP-FPM (FastCGI Process Manager) process, which then executes the PHP code and returns the result to the web server. This allows the web server to handle multiple PHP requests simultaneously, improving performance.

On the other hand, mod_php is an Apache module that embeds the PHP interpreter directly into the Apache web server. This means that Apache can handle PHP requests itself, without the need for external programs or FastCGI.