[discussion] Starting a new project, should use Swow or Swoole?

[kspaced]

Hello,

We're starting a new project that will include a number of microservices with critical performance requirements. Some HTTP servers and some WebSockets servers.

The question is, should we use Swow or Swoole since we have limited hardware resources and want to make the most of what we have and performance is of essence, and what should be the use cases for each of Swow and Swoole?

[kspaced]

@twose Is it possible to have input here :) ?

[AuroraYolo]

Yes, I think swow can be used,https://github.com/SerendipitySwow/Serendipity-job,
https://github.com/swow-cloud/music-server. Websocket demo

[twose]

@kspaced
I'm busy with other work at the moment.
But I am willing to write a detailed reply later :)

[cayolblake]

@twose I'm also interested in your reply on this matter.

[cayolblake]

@twose May be you cna write a blog post, or something in the Wiki?

[cayolblake]

@twose Any clarification/elaboration here yet :) ?

[dixyes]

Sorry for the late reply. We have been busy with some realistic matters for a long time.

In my opinion:

• Swow won't give you a performance boost like riding a rocket, if you have the patience to optimize, both Swow and Swoole will work perfectly.
• Swow now still not providing stable API/ABI (but we may make basic API stability after 0.2.0). You have to face breaking behavior changes. (Of course, just pinning to some version is still OK)
• Swow code has been checked by multiple static analyzing tools and most C codes have good coverage, and it was continuously tested in many ways. We may think Swow is stable for common workloads.
• We have many rare machines (and OS) to test and run Swow, if you are using some rare hardware (like an arm64 XX pie), it may be easier to debug Swow on it.

@twose has written a long answer about "why there are no release versions and should you choose Swow" (but in Chinese): #81 (comment)

Let me translate it for you (not 100% accurate):

First of all, Swow's kernel stability has been production-ready for a long time. From the perspective of data quantification, our unit test coverage has achieved a very high level. Because it's impossible to write many over-complicated test cases (like malloc fail), the coverage level now we have achieved is almost the highest level that it can be.

After coroutine-ize PHP, we have proven above 99% over more than 10,000 PHP unit tests have no breaking behavior, only some special cases have little impact. And we have a perfect cross-platform capability too, Swow now may be the most portable PHP coroutine extension, even supported by environments such as Loongson or Windows Arm64 (even PHP itself does not support it, currently our team member @dixyes is working on this, including contributing a Windows arm64 patch to the PHP kernel (it was merged now)). You can also see on the commits that we are running a lot of automated CIs, covering various platforms and PHP versions.

I understand that everyone is so concerned about the Swow release because of the stability of the Swow kernel, but in fact, the stability has nothing to do with whether the released version is out or not. The key reason for not making a released version is that we cannot determine the stability of the API/ABI. That is to say, we may also redesign some APIs. If 1.0 is released, it will be more difficult to change the API. If you can accept that there will be some API changes in the future, you can use Swow right now. Otherwise, you may wait for API stabled versions. As far as I know, there are already some companies using Swow for their production projects. If you want to use a framework like Hyperf that supports Swow, it encapsulates Swow's API well. So that you can be free from the impact of API changes. Hyperf 3.0 or future versions of the IMI framework will fully support Swow. If you have already chosen a framework without Swow support, you may wait a little longer.

Due to lacking time, updating is not very diligent, many TODO items are still to do in the Projects. We have a discussion thread for showing what we have done in a period ("News since some date"). The development of PHP core extensions is really hard work with little understanding (original words: "曲高和寡" "The tune is too elegant so few people sing together") and takes huge time (original words:"十年磨一剑" "ten years of sharpening a single sword"). Also, Swow has always been at the forefront of exploration, we will design a thing with thorough consideration, so as not to leave historical baggage. So the progress may not be very fast. But we are close to the release of the first major version. At present, most of the development of Swow's core dependency libcat library has been completed. We have coroutine-ized most of the functions of libuv, and the rest works is to encapsulate C API into PHP API.

There are lots of exciting features that have been implemented that I will probably share by writing a blog post when I have time (translator: however he never has time).
In the future, we also plan to coroutine-ize more synchronous blocking libraries in the current PHP ecosystem. Among them, the very popular pgSQL and MongoDB are our first goals, but they are still in the early research stage.
We may use a lot of PHP codes to implement some things that might be implemented by C codes, and the debuggability of Swow will be greatly improved in the future. By the way, Swow currently supports the Xdebug extension under PHP-8.1. And built-in GDB-like SDB tool (written in PHP), which is very convenient for debugging without affecting performance.

Our company currently uses the PHP + Swoole stack for all projects. It is expected that our new projects next year will (this year have already) use Swow as the core driver. Now there are projects in the development stage, so for me, the best time to release Swow v1.0 should be after our company verified it in production, because many small boundary bugs can be exposed in production easily. And we are also developing more community contributors to participate in this project. If the development team has acquired enough developers and resources in the future, we still have many grand projects that will benefit the PHP ecosystem. In conclusion, you don't have to worry that this project will be abandoned or no longer be maintained.