Before we get into this topic, we need to know about CGI,FASTCGI.

CGI is the Common Gateway Interface, which enables any program with standard input and output to provide web server capabilities. Suppose we write a c++ program that writes Hello World. The program takes input {text} and output {text},Hello World.

For example, nginx accepts an HTTP request, forks a process, takes the HTTP request’s text parameter as input, executes the Hello World program, outputs {text}, hello world as output. The process forked out is destroyed and returned to the client by nginx.

This approach is simple, but involves constantly forking and destroying processes.

FASTCGI, as the name suggests, is an improved version of CGI and is a resident CGI service. The common php-Fpm runs in this mode, where phP-Fpm is responsible for Forl multiple processes, each of which runs the PHP interpreter. You can take a look at the phP-FPM process in the terminal



A main phP-fpm process,pid 1263, forks 3 child processes. In the nginx+ php-FPM combination, nginx is responsible for accepting HTTP requests, wrapping them up and handing them off to php-FPM, which then sends the requests to a child process that executes them according to certain rules. The PHP interpreter in the child process loads the PHP code and runs it. For this reason, traditional PHP can only be used as a Web server.

We then found that the nginx+ PHP-FPM combination was very similar to the way our Reactor+Worker child process ran.

Here’s swoole as an HTTP server (traditional PHP is almost always a Web service).

First of all, Swoole implements HTTP server, which means that nginx is no longer needed as an HTTP server. Of course, Swoole is not trying to replace Nginx. In fact, swoole’s current implementation of HTTP server is limited in functionality, for example, it only supports Get and Post. So often Swoole also runs an Nginx in front of it as a front-end proxy server.

Second, swoole is memory resident. Unlike phP-FPM’s resident service, where PHP’s resident interpreter loads PHP code repeatedly and initializes the environment, Swoole loads only at startup, which automatically improves performance. This is evident in development. Under PHP-FPM, the modified PHP code takes effect immediately, whereas with Swoole you need to restart the Swoole server for the code to take effect.

With a few of the above explanations, it’s clear what swoole and traditional PHP development have to offer.

Swoole Server has the following advantages: – Swoole has higher performance – Swoole can be used as TCP and UDP server – Under the requirements of high IO and high concurrency server, swoole operating mode is fully competent

Swoole Server disadvantages: – Harder to get started. This requires developers to have a better understanding of how multiple processes run – more prone to memory leaks. Be careful when handling global and static variables, because variables that are not cleaned up by the GC will last their entire life cycle and can easily run out of memory if not handled correctly. With phP-FPM, memory is freed as soon as the PHP code executes. – Cannot do intensive computing. This, of course, is a problem with PHP and even with all dynamic languages. I wrote it here because I don’t want to mislead the reader into thinking that with swoole, PHP can be used to do intensive computations.


Original: www.myway5.com/index.php/2…