Born for speed: the combination of PHP and Golang - RoadRunner

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 severely 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 actual development problems, and how we can turn it into a tool to eliminate the PHP Death Model some questions.

General PHP development environment

#Before telling how Go improves the PHP death model, let’s first understand the general 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 techniques, microframes, 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)

A PHP process can 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.

Things have 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), where The information contained is the packet type, its size and binary mask information, used to check the integrity of the data.

On the PHP side, we used the

pack function, and on the Go side, we used the encoding/binary library.

One protocol is a bit obsolete for us and we added the ability to

call the net /rpc Go service 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.

In order to store the active worker process pool, we use a

buffer channel. In order to clear the unexpected "dead" worker process from the pool, we Added a mechanism to track errors and worker process status.

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 currently available .

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 (which has not yet received a name) looks like this:

RoadRunner - High - Performance PHP Application Server

Our first test task is an API backend on which there are periodically unpredictable bursts of requests (more frequent 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 the middleware net/http on the Go side, even in JWT validation before requests go into PHP, as well as handling 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. 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.

English original address: https://sudonull.com/post/6470-RoadRunner-PHP-is-not-created-to-die-or-Golang-to-the-rescue

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

Recommended learning: "PHP Video Tutorial"

The above is the detailed content of Born for speed: the combination of PHP and Golang - RoadRunner. For more information, please follow other related articles on the PHP Chinese website!