Enjoy the powerful combination of PHP and Go [RoadRunner]!

                                                                                                                                     

Enjoy the fun of it!

---

For the past ten years, we have been developing applications for Fortune 500 companies and businesses with 500 users or less. Historically, our engineers have primarily used PHP to develop the backend. But two years ago, some issues arose that seriously affected not only the performance of our products, but also their scalability - so we introduced Golang (Go) into our technology stack.

Almost simultaneously, we discovered that Go not only allowed us to create larger applications, but also improved performance by up to 40x. With it, we are able to extend existing products written in PHP and improve them by combining the best of both languages.

We will tell you through a lot of Go and PHP experience, how to use it to solve real development problems, and how we can turn it into a tool to eliminate some of the problems related to the PHP death model.

Recommended study: "PHP Video Tutorial"

General PHP development environment

is telling how to improve Go Before PHP death model, first understand the regular PHP development environment.

Usually, applications run on nginx and PHP-FPM. nginx handles static requests, while dynamic requests are redirected to PHP-FPM, which executes the PHP code. Maybe you are using Apache and mod_php, but they have the same principle and only slight differences in how they work.

Look at how PHP-FPM executes code. When a request is received, PHP-FPM initializes the PHP subprocess and forwards the request details to it as part of its status (_GET, _POST, _SERVER, etc.).

The state cannot be changed during the execution of the PHP script, so there is only one way to get a new set of input data: clear the process memory and initialize it again.

This performance model has many advantages. You don't need to worry too much about memory consumption, all processes are completely isolated, if one of the processes "dies", it will be automatically recreated and will not affect other processes. However, this approach has drawbacks when you try to scale your application.

Disadvantages and Inefficiencies of a Typical PHP Environment

If you develop professionally in PHP, then you know where to start when creating a new project - choosing a framework . It is a library for dependency injection, ORM, transformations and template methods. Of course, all user-entered data can be conveniently placed in a single object (Symfony / HttpFoundation or PSR-7). These frames are great!

But everything has its price. In any enterprise framework, in order to handle a simple user request or access a database, you have to load at least a few dozen files, create many classes, and parse multiple configurations. But the worst thing is that after each task is completed, you need to reset everything and restart: all the code you just started will become useless, and with its help you will not be able to process another request. Tell this to any programmer writing in other languages ​​- and you'll see the confusion on his face.

For years, PHP engineers have been looking for ways to solve this problem, using lazy loading technology, micro-frames, optimization libraries, caching, etc. But eventually, you still have to abandon the entire application and start over* (Translator's Note: With the emergence of preloading in PHP7.4, this problem will be partially solved) Handle multiple requests?

You can write PHP scripts that last longer than a few minutes (up to hours or days): e.g. Cron jobs, CSV parsers, queue handlers. All of these jobs follow a pattern: they get a task, process it, and then get the next task. The code resides in memory, so additional operations to load frameworks and applications are avoided, saving valuable time.

But developing long-running scripts is not that easy. Any error will kill the process, memory overflow will cause a crash, and F5 cannot be used to debug the program.

The situation has improved since PHP 7: a reliable garbage collector has appeared, it has become easier to handle errors, and extensions to the kernel can avoid memory leaks. Yes, engineers still need to carefully deal with the issue of memory and remembering state in the code (what language allows you not to pay attention to these things?) Of course, in PHP 7, there are not many surprises.

Is it possible to adopt a model of resident PHP scripts for more trivial tasks like handling HTTP requests, thereby eliminating the need to download everything from scratch for every request?

To solve this problem, you first need to implement a server application that can receive HTTP requests and redirect them to the PHP worker one by one instead of killing it every time.

We know that we can write web servers in pure PHP (PHP-PM) or with C extensions (Swoole). While each approach has its merits, neither option worked for us – I wanted something more. We needed more than just a web server - we wanted a solution that would allow us to avoid the problems associated with "restarts" in PHP, while being easily adaptable and extendable for specific applications. That is, we need an application server.

Can Go help solve this problem? We know it can because the language compiles the application into a single binary; it is cross-platform; uses its own parallel processing model (concurrency) and libraries for handling HTTP; and finally, we can put more Open source libraries are integrated into our programs.

Difficulties encountered in merging two programming languages

First, it is necessary to determine how two or more applications communicate with each other.

For example, using Alex Palaestras' go-php library, memory sharing between PHP and Go processes (such as mod_php in Apache) can be achieved. But the functionality of this library limits our use of it to solve problems.

We decided to use another more common approach: structuring the interaction between processes by using sockets / pipelines. This approach has proven its reliability over the past decade and is well optimized at the operating system level.

First, we created a simple binary protocol for exchanging data between processes and handling transmission errors. In its simplest form, this type of protocol resembles a netstring with a fixed-size packet header (17 bytes in our example) that contains information about the packet's type, its size and binary Mask information used to check data integrity.

On the PHP side, we use the pack function, and on the Go side, we use the encoding/binary library.

One protocol is a bit obsolete for us and we added the ability to call net/rpc Go services directly from PHP. This feature helped us a lot in later development because we could easily integrate Go libraries into PHP applications. The results of this work can be seen in another of our open source products, Goridge.

Distribute tasks among multiple PHP Workers

After the interaction mechanism was implemented, we began to think about how to better transfer tasks to the PHP process. When a task arrives, the application server must select an idle worker to execute it. If the worker process terminates with an error or "dies", we clear it and create a new one. If the worker process executes successfully, we return it to the worker pool where it can be used to perform tasks.

To store the active worker process pool, we use a buffer channel. To clear unexpected "dead" worker processes from the pool, we add a tracking error. and worker process status mechanism.

Finally, we have a working PHP server capable of handling any request rendered in binary form.

In order for our application to start working as a web server, we must choose a reliable PHP standard to handle any incoming HTTP requests. In our case, we simply convert a simple net/http request from Go to PSR-7 format so that it is compatible with most of the PHP frameworks available today.

Since PSR-7 is considered immutable (some would say technically not), developers must write applications that do not, in principle, treat requests as global entities. This is fully consistent with the concept of PHP resident processes. Our final implementation (has not yet received a name) looks like this:

RoadRunner - High-Performance PHP Application Server

us My first test task was an API backend on which I periodically experienced unpredictable bursts of requests (more frequently than usual). While nginx capabilities are sufficient in most cases, we often encounter 502 errors due to the inability to quickly balance the system under expected load increases.

To solve this problem, we deployed our first PHP/Go application server in early 2018. And achieved amazing results immediately! Not only did we completely eliminate 502 errors, we also reduced the number of servers by two-thirds, saving a ton of money and solving a headache for engineers and product managers.

In the middle of the year, we improved our solution and released it on GitHub under the MIT license under the name RoadRunner, thus emphasizing its amazing speed and efficiency.

How RoadRunner can improve your development stack

The use of RoadRunner allows us to use middleware net/http on the Go side and even do JWT before the request goes into PHP Authentication, and handling of WebSocket and global aggregate state in Prometheus.

Thanks to the built-in RPC, you can open the API of any Go library in PHP without writing an extension package. What's more, with RoadRunner, you can deploy new servers that are different from HTTP. Examples include running AWS Lambda processors in PHP, creating powerful queue selectors, and even adding gRPC to our applications.

Using both PHP and Go, the solution has been steadily improved, improving application performance by 40x in some tests, improving debugging tools, enabling integration with the Symfony framework, and adding Support for HTTPS, HTTP/2, plugins and PSR-17.

Conclusion

Some people are still bound by the outdated concept of PHP, thinking that PHP is a slow, cumbersome language suitable only for writing plugins under WordPress. These people even go so far as to say that PHP has a limitation: when the application gets large enough, you have to choose a more "mature" language and rewrite the code base accumulated over the years.

To these questions, my answer is: think again. We believe it's just you who has set some limits on PHP. You can spend your life moving from one language to another, trying to find the one that perfectly matches your needs, or you can treat languages ​​as tools. With a language like PHP, its supposed flaws may be the real reason for its success. If you combine it with another language like Go, you create a more powerful product than just using one language.

After using Go and PHP interchangeably, we can say that we like them very much. We are not going to sacrifice one for the other, but instead we are going to find ways to get more out of this dual architecture.

Original address: https://sudonull.com/post/6470-RoadRunne...

Translation address: https://learnku.com/php/t/61733

The above is the detailed content of Enjoy the powerful combination of PHP and Go [RoadRunner]!. For more information, please follow other related articles on the PHP Chinese website!