Swow is a high-performance pure coroutine network communication engine written in PHP and Cwhich is committed to using a minimal C core and most PHP code to support PHP high-performance web programming.
Project original intention
Although the PHP coroutine ecology now has a very diverse selection, all coroutine frameworks and libraries have a very fatal problem, that is, they all evolved from asynchronous frameworks, not bottom-up for coroutines. Due to some compatibility considerations, many capabilities that should be possessed are often sacrificed, or reasonable design changes cannot be made due to historical burdens.
Therefore, the Swow project is committed to creating a high-performance, highly controllable, and easily compatible engine designed for coroutines from the bottom up. Relying on the advantages of architecture design, it will fully release the true strength of coroutine technology. This is the original intention of Swow and its team members. We will continue to invest and work hard for this, and you are welcome to join us to participate in open source construction.
Swow’s minimum C core design determines that it is more about pursuing secondary development capabilities and debuggability in addition to ensuring key performance.
The seamless integration of Swow kernel and PHP code greatly improves the developer’s programming efficiency and flexibility.
Swow provides a variety of debugging mechanisms and powerful and low-threshold debugging capabilities to ensure that developers are free from bugs to the greatest extent. Ordinary developers can also have near-expert-level DEBUG capabilities through the blessing of tools.
Written before the introduction of capabilities: The development of PHP high-performance coroutine network communication engine has a long way to go. This is an open source work that is too high. I am very grateful to the following partners for their code contributions to the Swow project. Without everyone, there would be no current Swow ! Among them, we would like to thank @dixyes, the core member of the team, for his dedication, which has raised the capabilities and stability of Swow to a whole new level!
|operating system||swow||Other asynchronous coroutine libraries|
|Win32||✅ IOCP native support||❌ No native support|
|GNU/Linux (including musl)||✅ Epoll support + planned io_uring support||⚠️ No io_uring plan support|
|macOS||✅ Kqueue support; support intel and m1 chips||⚠️ Not Tier 1 support|
|FreeBSD||✅ Kqueue support||⚠️ Lack of official support statement|
|other [^other-platforms]||⚠️ Second class support: AIX / IBM i / z / OS / Android / MinGW / SunOS||⚠️ not clear|
[^other-platforms]: Other system support depends on libuv support and community needs
C stack coroutine implementation
|C stack coroutine implementation||swow||Other asynchronous coroutine libraries|
|boost-context||✅ First class support [^boost-context-tier-1]||✅|
|ucontext||✅ Better compatibility||✅|
|thread-context||✅ You can observe the status of all C stack coroutines through gdb||⚠️ Only Swoole supports|
[^boost-context-tier-1]: First-class support means that members of the Swow development team will submit code contributions to boost-context to better support the application scenarios required by Swow.
|Coroutine model||swow||Other asynchronous coroutine libraries|
|main coroutine||✅ Wherever you go, there are coroutines||❌ Not supported, not perfectly compatible with traditional PHP ecology|
|Cross-coroutine scheduling||✅ Support nested coroutine cross-level scheduling||❌ Not supported, unable to achieve cross-level interruption|
|independent environment||✅ A single coroutine crash does not affect global stability||❌ Not supported, all crashed|
|Benchmarking Process Model||✅ Imitate the process model, the design is reasonable to follow||❌ self-made concept|
|Single Stack Lightning Switching||✅ The scheduler or internal coroutine only needs a single-stack switch||❌ Not supported, always dual-stack switching|
Coroutine control ability
|Coroutine control ability||swow||Other asynchronous coroutine libraries|
|forced wakeup||✅ Equivalent to ECANCELED or ETIMEDOUT||⚠️ Imperfect / no full scene support|
|abort||✅ Equivalent to SIGTERM||⚠️ Not fully supported|
|kill coroutine||✅ Equivalent to SIGKILL||❌ not supported|
|coroutine debugger||swow||Other asynchronous coroutine libraries|
|SDB||✅ Customized for the coroutine model||❌ Lack of Debugger fully oriented to coroutine design|
|Xdebug||✅ Supported from PHP-8.1||✅ Supported from PHP-8.1|
Coroutine debugger capability
|Coroutine debugger capabilities||swow||Other asynchronous coroutine libraries|
|PHP writing & secondary development||✅ Inheritable extensions||❌ Depends on other extension capabilities|
|Production environment support||✅ No performance impact||⚠️ Not recommended to enable in production environment|
|list of coroutines||✅ Equivalent to the ps command to view the process||⚠️ Not fully supported, libraries that rely on traditional PHP debuggers have no support for coroutine granularity|
|View all coroutine information||✅ You can view the status of the coroutine, the information of each stack frame of the full call stack, the content of the source code executed, the variables on the stack, etc.||⚠️ Not fully supported, libraries that rely on traditional PHP debuggers have no support for coroutine granularity|
|Enter a coroutine and track debugging||✅ Equivalent to gdb attach||❌ not supported|
|Breakpoints, single-step debugging||✅ Only affects debugged coroutines||⚠️ Rely on tools such as Xdebug, and will block the entire process|
|Dynamically insert PHP instructions while debugging||✅ When using the debugger for breakpoint debugging to the BUG, you can dynamically execute PHP instructions to debug the BUG [^gdb-print]||❌ not supported|
|Scanning zombie coroutines||✅ Find coroutines that have been inactive for a long time||❌ not supported|
|kill coroutine||✅ Equivalent to kill command||❌ not supported|
|kill all coroutines and exit||✅ Equivalent to graceful shutdown||❌ not supported|
[^gdb-print]: Equivalent to the print command of GDB, dynamically execute the expression given by the debugger, and print its return value.
The core effective code is less than 300 lines, and the unit test coverage rate is 100%.
|channel capability||swow||Other asynchronous coroutine libraries|
|zero-buffered channel||✅ New Channel(0)||❌ not supported|
|buffered channel||✅ new Channel(n)||✅|
|select||✅ Selector | CallbackSelector||❌ not supported|
|circular reference GC||✅ Can handle circular references in the queue||❌ not supported|
|read after close||✅ The remaining data in the queue can still be read after the channel is closed||❌ not supported|
|WaitGroup||✅ Built-in high performance implementation|
|WaitReference||✅ Implemented by reference counting mechanism, coding is easier|
|coroutine library||event driven|
|swow||✅ Self-maintained based on libcat [^libcat]libcat is a derivative project of libuv [^libuv]|
|Swoole||✅ Self-developed, but no Windows native support|
|Other asynchronous coroutine libraries||❌ Rely on event-driven extensions maintained by third parties, and some extensions are no longer maintained|
[^libcat]: libcat is the coroutine version of libuv, which is independently maintained by the Swow team and can be used by all C-based projects. For example, you can use libcat to write a C++ coroutine project, or provide C stack coroutine capabilities for Python and Node.js Wait.
[^libuv]: The asynchronous event driver of libuv provides mainstream full-platform support, has passed extensive and rigorous production verification in languages such as Node.js and Julia, and has reached industrial-grade standards. The Swow team will submit code contributions to libuv to make it better support the application scenarios required by Swow.
|signal ability||swow||Other asynchronous coroutine ecology|
|Windows signal simulation||✅ Use Linux-like signal mechanism under Windows||⚠️ Lack of Windows native support|
|Network programming ability||swow||Other asynchronous coroutine ecology|
|Buffer||✅ Accurately control the memory usage of each byte to achieve high-performance data processing||❌ Coarse-grained memory management|
|Buffer (copy-on-write)||✅ Copy-on-write mechanism + memory mapping mechanism||❌ php_stream needs to create an internal memory copy|
|Socket||✅ Can be linked with Buffer to achieve data transmission and reception accurate to every byte||❌ Coarse-grained memory management|
|Socket (writev support)||✅ Single system call zero copy to send multiple blocks of memory data||❌ unavoidable memory copy or multiple system calls|
|IpAddress||✅ Perfect high-performance IP address resolution library to help network programming||⚠️ Lack of relevant built-in support|
|HttpParser||✅ Can be controlled by PHP code to complete high-performance HTTP protocol analysis||❌ Can only receive underlying processed HTTP objects|
|WebSocket||✅ Can be controlled by PHP code to complete high-performance WebSocket protocol analysis||❌ Can only receive the underlying processed WebSocket object|
With the help of the minimal capability provided by the underlying core of Swow, a high-performance API gateway can be realized by writing PHP code. The specific project practice content and production environment verification sharing, please look forward to the follow-up Twitter update of the official Swow team!
synchronous blocking coroutine
|synchronous blocking coroutine||swow||Swoole||Other asynchronous coroutine ecology|
|PHP stream (blocking mode)||✅||✅||❌|
|PHP stream (non-blocking mode)||✅ BIO mode||✅ SSL_read/write mode||❌|
|PHP stream (file IO)||✅||✅||❌|
|PHP stream (file lock)||✅ Full scene coverage||✅||❌|
|pdo_pgsql||⚠️ Not supported yet [^not-supported-yet]||⚠️ Not supported yet [^not-supported-yet]||❌|
|sockets extension||⚠️ Not supported yet [^not-supported-yet]||✅||❌|
|sleep, usleep, nanosleep…||✅||✅||❌|
|shell_exec, exec, passthru…||✅||✅||❌|
|Gethostbyname and other DNS related functions||✅||✅||❌|
|stream_poll_one||✅ Workerman special offer||✅ Swoole\\Event||❌|
[^not-supported-yet]: Not supported at the moment means that it will be supported in the future, or it is already in the implementation plan
Benefits of this technology:
|Advantages of ecological reuse||swow||Swoole||Other asynchronous coroutine ecology|
|Open source libraries based on file_get_contents(), cURL (such as: Guzzle, etc.)||✅||✅||❌ Ecological fragmentation|
|The cURL-based SDK provided by the cloud platform (such as the SDK of Alibaba Cloud, Tencent Cloud, AWS and other platforms)||✅||✅||❌ Ecological fragmentation|
|Open source library based on PDO, mysqli, phpredis||✅||✅||❌ Ecological fragmentation|
|Based on stream_select() or other event-driven asynchronous open source libraries (such as: workerman, reactphp, amphp)||✅||✅||❌ cannot work simultaneously|
|FileSystem related open source libraries (eg: symfony/filesystem)||✅||✅||❌ Unable to solve, block directly|
|Print directly to standard output or log libraries that need to read and write log files (such as: symfony/console, monolog)||✅||✅||❌ Unable to solve, block directly|
Watchdog provides CPU scheduling capabilities for PHP. The core principle is that the Watchdog thread will periodically check the activity of the coroutines in other threads. If it is found that the coroutines in the worker threads are no longer active, they will be checked through the interrupt mechanism of ZendVM. Confirm that if the VM interrupt fails, it indicates that the worker thread is blocked by a system call and triggers an alarm; if the VM interrupt succeeds, it indicates that the worker thread is caught in CPU-intensive operations or an infinite loop, and immediately triggers the scheduling rules set by the user for scheduling.
|CPU scheduling capability||swow||Swoole||Other asynchronous coroutine ecology|
|CPU blocking alarm||✅ Contains system call blocking warnings||⚠️ Silent scheduling, no alarm||❌ No alarm, direct downtime|
|CPU blocking slowdown||✅ Dynamically adjustable||✅ Fixed scheduling time||❌ Unable to slow down, directly down|
|CPU blocking throttling||✅ Support killing coroutines stuck in an infinite loop||⚠️ Only timed transfer is supported to reduce negative impact||❌ Unable to cope, direct downtime|
|Dynamic Switch Scheduler||✅ API switch scheduler||⚠️ Only support settings via ini||❌ No CPU scheduling capability|
|Dynamic Programming Scheduling Behavior||✅ Programmable, dynamically determine the scheduling method when blocked||⚠️ Fixed scheduling rules||❌ No CPU scheduling capability|
|modernization capabilities||swow||Other asynchronous coroutine libraries|
|object oriented||✅ The kernel and PHP code are seamlessly integrated, all objects can be extended through inheritance, and secondary development can be easily completed||⚠️ Not fully object-oriented|
|exception mechanism||✅ Fully embrace the exception mechanism, and chain calls are easy to code||⚠️ Incomplete use of exception mechanism|
|Composer||✅ Support the whole process to install and deploy through Composer, and support All in one or sub-library pull methods||⚠️ The extension needs to be installed by other means|
|IDE assistant||✅ Composer built-in IDE assistant code in the package after installation||⚠️ Need to pull additional IDE assistant|
Other debugging capabilities
|Other debugging capabilities||swow||Other asynchronous coroutine libraries|
|class strace log||✅ In Debug mode, it supports printing the underlying coroutine scheduling, network sending and receiving, and system call information in strace format (supports multiple formats of time, module information, and PHP source code location display), and SSL network sending and receiving data supports plain text display, eliminating the need to capture packets Tool and certificate configuration troubles.||❌ No related support|
|debugInfo support||✅ Print internal objects through var_dump(), and you can also see rich debugging information||⚠️ Need to manually print the required information|
|build capacity||swow||Swoole||Other asynchronous coroutine ecology|
|Builder||✅ The project can be pulled through Composer, and the extension can be installed with one click using the built-in script, supporting independent extended version of each project||⚠️ Only manual compilation or PECL installation is supported||❌ You need to install third-party event-driven extensions yourself|
|PECL||❌ No planned support, PECL is in disrepair, lack of maintenance||✅ First class support||⚠️ Event-driven extensions are provided by a third party, and reliability cannot be guaranteed independently|
|Windows DLLs||✅ Can be downloaded directly from the release page||❌ Does not support Windows||❌ No Windows native support|
|CLI issue||✅ Based on lwmbs capability, it can be downloaded directly||✅ swoole-cli||❌ Need to compile it yourself or install it through the system package manager|
|One-click packaging of micro into binary||✅ Based on lwmbs capability, Swow is optional for PHP project binary packaging and release, once packaged and run in multiple places [^hyperf-box]||⚠️ Not supported yet [^not-supported-yet]||❌ Not supported, but can be achieved with the help of PHP packaging capabilities provided by the Swow team|
[^hyperf-box]: Hyperf Box provides out-of-the-box one-click packaging binary tools for the Swow project, and more open source community partners are welcome to re-develop more out-of-the-box packaging tools based on micro technology to benefit the community.
The above capability enumeration is just the beginning of Swow. The Swow core also contains a lot of detailed design and some experimental functions that have not been officially disclosed.
In general, the future of Swow is full of imagination. It provides PHP with possibilities far beyond the past. We can use Swow’s ability to think and do more things that have never been thought about.
In the future, we will share with you the detailed description and best practices of each capability item in detail by “publishing a large number of short articles”, and disclose a large number of internal implementation details and production applications, so stay tuned!
#Swow #v100 #released #News Fast Delivery