This article mainly records the process of learning swoole, the pitfalls that have been filled, and how powerful swoole is!
First let’s talk about our understanding of swoole: a C program dressed in PHP. Many PHPer friends saw the powerful functions provided by swoole and the admiration of the outside world, so they eagerly installed, debugged its demo, wrote new functions, and then rushed to tell each other excitedly. A few days later, when you continue to use swoole according to your own understanding, you find that the code does not run as you expected, and then you start to curse, what a crap thing, the code is basically the same as the demo, why doesn't it run? What nonsense work, tasks, shared memory, ipcs, asynchronous, all kinds of questions emerged, and then I quickly checked the official documents and found that there was no mention of these in the documents, but a brief introduction on how to use it. At this time, I almost lost hope in swoole. .
Because swoole is multi-threaded programming, global cannot be shared among multiple processes. Example
global $i = 0;
function onRequest() {
echo $i ;
}
If you write the above program in swoole, it will not output an increasing number every time it is accessed. If you want to achieve the expected effect, you need to use the related functions of swoole_table.
For PHPer, the understanding of asynchronous and callback is probably ajax. When I saw the explanation of asynchronous and callbacks in swoole, it seemed very simple. So I used swoole rashly without any multi-threaded editing experience. As a result, I was tricked into secretly coding for several nights to fill my own pit.
The server can receive multiple requests sent by the client at once. It’s not that the client sends it once and the server receives it once
Write an http server, then access this homemade server through the browser, refresh the browser, why does the server receive two requests? This problem probably troubles many friends who are using swoole to write httpserver for the first time. Because the browser will send one more favicon.ico request.
The reason for this situation is actually very simple. Most phpers only know php, and their main purpose is to make web and write business logic. Few people understand the development of server programs. Once, a friend used swoole to write a simple server and a client. He came to me and asked me why he couldn't receive data even after starting it. I briefly looked at the code and found that all connections were indeed successful. The onReceive callback was set up, and the code was fine. At the end, I found that both the server and the client had set callback functions for receiving messages, but neither end sent a message to the other, and the two ends were in a stalemate. Then swoole officials did not give any explanation on this common sense issue. They just talked about how to set up callbacks, how to send messages, how to do this, and how to do that. For students with server-side development experience, they will definitely not encounter this problem, and the swoole document does not need to specify the need to do this, because it is common sense. But for phper, it is very important to indicate this point, because as mentioned above, phper does not have this knowledge. Only programmers with server-side development experience will have it.
Swoole’s features: network communication framework, asynchronous, multi-threading. These features are exactly the imperfect functions of PHP (although the official provides many basic functions to realize these functions, but there is a lack of Chinese documentation, and few people use PHP to implement these functions). Ordinary PHP does not have the basic understanding of these features. You know, so if you use swoole rashly, you will inevitably encounter some common sense problems that cannot be found on the swoole official website.
A long time ago, I was also a programmer who only knew PHP. Then I needed to use httpsqs by chance. After using it for a while, I found that I had some unique needs, so I started looking at the source code. This is really hard to see, but I was shocked when I saw it. httpsqs is just a simple packaging. Inside is a Tokyo Cabinet database. In my impression, the packaged code is only more than 100 lines. The main idea is to use libevent in C language to make an http server to receive requests to read and write the Tokyo Cabinet database. At that time, there were indeed many programs based on this idea. Later, I suddenly thought that since C language can use libevent function, PHP can definitely use libevent to monitor the network, read and write the database for queue service after receiving the request. Later, after checking the official PHP documentation, I found that PHP does provide a complete system of functions to complete these functions, and even a full set of multi-threaded functions are provided. However, there are too few Chinese documents, and mature codes are rarely found online. As a last resort, I learned the basic principles of Linux-C multi-thread development, common methods of inter-process communication, and also used it to make some simple demos. The only feeling is that writing a simple function is really complicated to design. Just when I was about to give up, swoole appeared. The functions provided by swoole are exactly the functions missing in PHP, which is simply great. As a network communication framework, swoole only requires a few simple lines of settings to set up a server. From now on, we will continue to improve the business code. I learned in the libevent communication group that swoole's design is not the best framework design in CC, but its highlight is that the basic functions are encapsulated in C, and the business functions are left to PHP, the best language in the world, to write. Since then, Swoole's journey of filling holes has begun.
Swoole is not a simple PHP framework. Just as the first sentence on the official homepage of swoole is "Redefine PHP", never use the old PHP thinking to write swoole code! swoole reactivates PHP, and php makes swoole!