Why use swoole

The power of swoole lies in the design of its process model, which solves both the asynchronous problem and the parallelism.

Starting with version 4.0, Swoole offers a complete Coroutine + Channel feature that brings the full CSP programming model. The application layer can use fully synchronous programming, and the underlying layer automatically implements asynchronous IO.

Using resident memory mode avoids the initialization of each frame and saves performance overhead. The underlying 4.x uses automated coroutine conversion.

What is a coroutine?

Coroutine is a history that has a much longer history than threads. A coroutine can be understood as a purely user-oriented thread that switches through collaboration rather than preemption. Relative to the process or thread, all operations of the coroutine can be completed in the user mode, and the consumption of creation and switching is lower. Swoole can create a corresponding coroutine for each request, and reasonably schedule the coroutine according to the state of the IO.

Developers can achieve asynchronous IO effects and performance in a non-perceived way with synchronous code writing, avoiding the discrete code logic and the multi-layer callbacks caused by traditional asynchronous callbacks.

At the same time, because the underlying package is packaged, the developer does not need to use the yield keyword to identify a coroutine IO operation compared to the traditional PHP layer coroutine framework, so there is no need to deeply understand the semantics of yield and for each level. The calls are all modified to yield , which greatly improves the development efficiency.

Here is a comparison:

multi-Progress Multithreading Coroutine
create Fork Pthread_create Go
Recycling Wait Pthread_join -
way of communication IPC interprocess communication Data synchronization/lock Array/chan
LF Process switching overhead Process switching overhead very low
Concurrency Hundreds Thousands 500000
Programming difficulty difficult very difficult easily

Advantages of coroutine

  • User state thread, encountering IO initiative to give up
  • PHP code is still serially executed, no lock required
  • Very low overhead, only memory, no process/thread switching overhead
  • Large amount of concurrency, a single process can open 50W coroutines
  • Anytime, anywhere, whenever you want to concurrency, call go to create a new coroutine

Swoole's coroutine

The swoole's coroutine and golang's scheduling method are completely different. The coroutine in each process is 串行 executed, so there is no need to worry about accessing the resource locking problem, which is also in line with the simple features of php.

Then the process's coroutine is how 串行 implementation uses multi-core CPU achieve 并行 . The answer is to use multi-process implementation. Now the task can also open the coroutine.

This may not be as good as golang performance, but it is very suitable for IO 密集型业务 , and the context switching of coroutines is very fast. The cost of switching a language is also huge for the company, and the ecology of swoole is getting better and better.

4.0 The underlying Hook mechanism is added to make the native Mysql PDO and Redis operations coroutine, and the Curl extension will be supported later. Closer to traditional business code, migration costs are also reduced.

swoole 's http server uses an excellent Reactor 模型 , and processing speed can force NGINX process static pages. Very suitable for Api or 基础服务 . The performance is turned over a few times, no longer have to worry about the php-fpm process too many, causing the CPU be full.

Where swoole needs attention

Of course, it is not without faults.

Unable to do intensive calculations. Of course this is a problem with php and even all dynamic languages. Written here is to prevent misleading readers from thinking that after using swoole , php can be used for intensive computing.

It's easier to leak memory. Be careful when dealing with global variables and static variables. This kind of variables that are not cleaned by the GC will exist throughout the life cycle. If not handled properly, it is easy to consume all the memory. In the past php-fpm, the php code will be completely released after the execution of the memory.

CSP has a classic saying: don't communicate through shared memory, but share memory through communication.

This "communication" you can understand the use of channel communication.

Although the swoole coroutine is serial, the business may cross . For example, if you add a configuration to a service and write the configuration, the context switch may cause configuration inconsistency. You may be curious, the local running is all right. Running online for a while will cause problems, this is a business design problem.