What Is Difference Between PHP Cli and PHP Cgi

What is difference between PHP cli and PHP cgi?

PHP CLI is the command-line interface for PHP (e.g. for creating standalone applications)

PHP CGI is the common gateway interface for PHP (e.g. for web applications)

performance difference between cli and apache cgi mode for php

consider when you are using php as a apache module, when someone hit your web server an apache process is created which has php in it and apache process calls php.
so one main difference is when you execute a php script in cli mode you call php directly but when using apache first you call apache and apache has itself initializations and after that it calls php and also after that php gives back the result to apache and then apache returns the result to http client which has hit the server.

Difference between php-cli and php-fpm mode in regard to APC/APCu

php-fpm ist running in its own process all the time. It can use apc because it uses continuously the ram over several requests. The memory is only released through the garbage collector or if you kill the fpm process. But the a CLI process lives only for one command and when its finished the memory is released. So apc cannot store any data over severel cli calls because it allocates new memory in the ram each call.

Why is PHP CLI considered as a kind of SAPI?

"Why" is always a slippery, somewhat philosophical, question; ultimately, the answer to "why is CLI considered a SAPI" is "because that's how the developers defined it". If they'd called it "CLI mode", would you still have asked "why"?

But you do ask a more concrete question, which can be paraphrased as:

When running a program on the CLI, why do you need a SAPI as well as the Zend Engine?

Or even more succinctly:

What does the CLI SAPI do?

The Zend Engine on its own takes a series of instructions, and executes them. It can manage variables, arithmetic, function definitions and calls, class definitions, and so on. But none of those are very useful if you can't get any output from the program; and most commonly you want to provide some variable input as well.

Some forms of input and output are based only on the operating system you're running on, not the SAPI - reading or writing a file based on an absolute path, or accessing something over a network connection. You could theoretically have a running mode that only gave access to those, but it would feel very limited. (Would that still be a "SAPI"? Definitely a philosophical question.)

Consider something as commonplace as echo: there's no absolute definition of "output" that the Zend Engine can manage directly. In a web server context, you expect echo to add some output to the HTTP response the server will send the client; in a command-line context, you expect it to show the output in the console where you ran the command, or be "piped" to another command if you run something like php foo.php | grep error.

The CLI SAPI doesn't provide all the same facilities that a web server SAPI would, but it fills a similar role in interfacing your program, running in the Zend Engine, to the outside world. Here are a few of the things it needs to do:

• Attach output to the parent console or "standard output" stream
• Make the "standard input" and "standard error" streams available
• Populate $argv and $argc based on the arguments the script was invoked with
• Populate $_ENV with the environment variables the process inherited
• Define an initial value for "current working directory" for use with relative file paths

Return headers in output when running php -f index.php

You can achieve this by using php-cgi without the -f option:

php-cgi index.php

X-Powered-By: PHP/7.3.3
Content-Type: application/json

Hello

---

Related Topics