SWOOLE_BASE vs SWOOLE_PROCESS - why should SWOOLE_BASE be preferred?

[linuxd3v]

The differences between these 2 modes (SWOOLE_BASE vs SWOOLE_PROCESS) are not very clear (at least to me).

When I look at the documentation - I was assuming (perhaps incorrectly) BASE = basic, so I would automatically configure SWOOLE_PROCESS mode thinking that is better and preferred.

But now - I see that swoole version 5 has made SWOOLE_BASE as default, and I also see some indications that SWOOLE_BASE should be preferred mode:

#4757
SWOOLE_BASE has never been deprecated, instead, it should be the preferred mode.
The reason why SWOOLE_PROCESS is still the default mode today is for backward compatibility.

Is there some documentation on why SWOOLE_BASE should be preferred and how is it better than SWOOLE_PROCESS?

[leocavalcante]

BASE is not the same as BASIC

At BASE mode, Swoole will skip a lot of overhead done at PROCESS mode so you can have a more reliable and faster system.

Use PROCESS mode only if you need your Workers to communicate between each other.

If you are in a cloud-native + k8s/container-orchestrated environment, you should be favoring BASE instead of PROCESS even more because your scale is based on new Pods, not on Swoole Workers inside the same machine.

[linuxd3v]

@leocavalcante Hi - really appreciate your response. 🙏

Use PROCESS mode only if you need your Workers to communicate between each other.

what do you mean by "communicate". I'm using swoole tables to share data between workers - does that count as communication? or is there some specific communication mechanism you are referring to?

If you are in a cloud-native + k8s/container-orchestrated environment, you should be favoring BASE instead of PROCESS even more because your scale is based on new Pods, not on Swoole Workers inside the same machine.

So with pods and k8s you guys set workers_num = 1 and pod resources as cpu: 1 respectively( and then just scale through pod count)?

[leocavalcante]

what do you mean by "communicate". I'm using swoole tables to share data between workers - does that count as communication? or is there some specific communication mechanism you are referring to?

Things like sendMessage() will not work across Workers in SWOOLE_BASE mode.

So with pods and k8s you guys set workers_num = 1 and pod resources as cpu: 1 respectively( and then just scale through pod count)?

Yeap, It is a cloud philosophy to have just a single process per container, so there is only a single Worker receiving requests and processing I/O Loop (SWOOLE_BASE) then we scale adding more pods.
At SWOOLE_PROCESS you will have a worker to receive TCP connections and a reactor threads to handle I/O loops, there are some advantages, but this is what adds the ICP overhead I mentioned before.

My personal recommendations:

• There will be a dedicated (virtual)machine for your application and you want to make a better use of its resources? Go for SWOOLE_PROCESSES and make worker_num the number of virtual CPUs.

• Will you be using container and container orchestration, like K8s? Go for SWOOLE_BASE and set worker_num to 1. And if you need to share resources, like Swoole Table, use something like Redis.

Here you can have more info: https://wiki.swoole.com/#/learn?id=server%e7%9a%84%e4%b8%a4%e7%a7%8d%e8%bf%90%e8%a1%8c%e6%a8%a1%e5%bc%8f%e4%bb%8b%e7%bb%8d (right click and translate to english)

[linuxd3v]

@leocavalcante extremely helpful and informative. tyvm.
We use swoole table in addition to redis - because it's much faster due to lack of network trip. If I'm not mistaken swoole tables work with either SWOOLE_BASE or SWOOLE_PROCESS.

Yeap, It is a cloud philosophy to have just a single process per container, so there is only a single Worker receiving requests and processing I/O Loop (SWOOLE_BASE) then we scale adding more pods.

Yes - one process one container is a typical approach with containers -which probably works for many applications just fine.
But here I'm conflicted - as I'm using following in my applications:

• using task worker to offload async tasks
• I'm using side process (via addProcess) for cache prewarming on application start and (and keeping things warm perpetually) in swoole tables.

^ task worker process and prewarming process are technically side proceccess (In addition to main application one) - so technically I would never be able to achieve one process per container unless I re-architect. But any architecture here will inevitably add some network IPCs instead (like redis queue call or grpc calls perhaps) - which not gonna be that performant.

it seems to me in my use case - SWOOLE_PROCESS would be preferred given i would rather not add additional network calls.

[smathersPersonal]

Things like sendMessage() will not work across Workers in SWOOLE_BASE mode.

This does not seem to be true, at least 3 yrs later on Swoole v6.0.0.
My logs you can see i sendMessage to worker 6 from 5, worker 6 receives it. Also to note, on the log line is the PID of the processes and they are different:

$server = new Swoole\WebSocket\Server('[::]', 9000, SWOOLE_BASE);
$cpus = swoole_cpu_num();
$server->set([
  'log_level' => 5,
  'enable_coroutine' => true,
  'reactor_num' => $cpus * 2,
  'worker_num' => $cpus * 4,
  'hook_flags' => SWOOLE_HOOK_TCP | SWOOLE_HOOK_NATIVE_CURL | SWOOLE_HOOK_SLEEP | SWOOLE_HOOK_BLOCKING_FUNCTION
]);

Lately I've been trying to figure out what i would lose going for the more efficient SWOOLE_BASE. Seems to be only that the connections are not broken when restarting workers. Which doesn't really matter in my case because every WebSocket client has proper reconnection logic..

[fakharksa]

@leocavalcante

At SWOOLE_PROCESS you will have a worker to receive TCP connections and a reactor threads to handle I/O loops, there are some advantages, but this is what adds the ICP overhead I mentioned before.

Many people do not have idea of the overheads of single-process containerized applications. In front of those overheads (in context of those overheads), the Inter-process Communication (IPC) is not a overhead, how ?

Containers are single-process and to mimic an application spanning over multiple-processes (parallel processing), you throw multiple single-process Containers (using Kubernetes). Now, in order to communicate between those single-Process containers, you ideally use gRPC oevr Network which in turn uses HTTP-2.

Container itself is a "image-copying" technique which is too slow at scale if compared to "Process Pool' in multi-process environment.

Some also use Docker-engine (consider that a layer over Linux Containers) to run Docker-containers which internally use Linux containers, in turn.

Ability to communicate between workers (which is an example of Broadcasting / publishing) on SWOOLE_PROCESS mode makes broadcasting lighting fast because through this technique data can be broadcast / published to different WebSocket Connections without making round-trips to Data Store), so it is faster, more reliable at scale. SWOOLE_BASE mode is same mode on which NodeJS works; all connections and event loops are created in Worker Process so if a Worker Process fails / stops all connections of the clients will break too.

IN SWOOLE_PROCESS, if the worker process goes down then the "Manager Process" tries to pull in a new Worker Process from the pool of worker Process.

there are some good reasons why many distributed applications like Multi-player Games, Databases, Block-chain and many Scalable Business Applications do not make use of Containerization.

[linuxd3v]

@fakharksa hey - thank you very much. This is also very informative and helps one achieve a better sense of differences between these modes. Yeah indeed when one thinks about it this way - gRPC communication is also communicatin and comes with some costs. same with image scaling. Indeed.

but practically speaking - what alternatives there is to docker containers? lxc/lxd?

i also personally have use cases where I run sidecar process that keeps cache always warm and another one - where its just super fast to kick off async task to a task worker process... Technically both can be moved to some networked service like redis or grpc calls - but surely result would not be nearly as fast as internal swoole ipc using unix sockets, which is I think a good argument for swoole_process.

[fakharksa]

@fakharksa hey - thank you very much. This is also very informative and helps one achieve a better sense of differences between these modes. Yeah indeed when one thinks about it this way - gRPC communication is also communicatin and comes with some costs. same with image scaling. Indeed.

but practically speaking - what alternatives there is to docker containers? lxc/lxd?

i also personally have use cases where I run sidecar process that keeps cache always warm and another one - where its just super fast to kick off async task to a task worker process... Technically both can be moved to some networked service like redis or grpc calls - but surely result would not be nearly as fast as internal swoole ipc using unix sockets, which is I think a good argument for swoole_process.

There are some limitations of Swoole Features in Swoole_Base mode, like if Worker crashes it can not auto restyart so Swoole_Base is not reliable at scale. Your question that "What are other alternatives if not use Containers (or, Docker Containers, or Serverless or AWS Lambda all of which make use of Containers behind the scene)".

I see Asynchronous Programming as a complete replacement of the "(Image-copying) Technique of Containerization; which is an classical hack for Scaling-out / Distributiveness". How / Why ?

Lets first understand a few points.

Point-1: The core objective of Scaling (-out / -up) is "To Scale-up the performance 'Linearly' when Computing (Hardware) resources are Scaled-up (added), and balance the load elastically".

Point-2: Asynchrony (non-blocking mode of operation) is a technique to utilize available / existing / provided Computing (Hardware) resources at their full throttle without depending on Distributively Scaling (without Scaling-out Horizontally, hence without need of Containerization).

According to TechEmpower Benchmarks (which performs only simple test to evaluate maximum http-requests served by Swoole per second), just a single Swoole Service is capable of utilizing 45% of the available computing resources. With simple mathematics, we can conclude that two Swoole Services (for example om same IP but on different ports) can effectively utilize 90% (45% x 2)% of the available Computing resources.
This means with Swoole / Asynchrony, we do not need to throw Containers / Pods, instead we just need to throw more (and more) Swoole Services while enjoying reliable yet fastest multi-process mode "SWOOLE_PROCESS".

If hosrizontal scaling is required (like for multi-dimensional scaling of different but realetd services), You can always create more services dynamically at run time using Swoole\Coroutine\Http\Server which allows to create a new Swoole HttpService inside CoroutineContext (which means inside co\run() OR inside onRequest event).

You can also write a simple few lines php script using "PHPSecLib" library to connect (securely) to a remote shell / system and can easily install whole PHP and Swoole environment, along with pulling Swoole services to be run from a Git Repo (which means deploying everything dynamically at run time on a remote system).

Containerization is an image-copying (a bad hack; way around) technique hyped wrongly as "Micro-services" which is not only expensive (include the cost of DevOps, and expensive Developers with the cost of inefficient and expensive Scaling on dedicated servers of Cloud), yet also slow. This technique is also failing (because many DevOps, Technical Team Leads and CTOs do not even have any clue about what bad they are doing by using such bad techniques specially by using them with blocking-mode PHP-frameworks which further depend on PHP-FPM engine which is modeled on one-process-for-each-request hence one external connection dedicated like DB-connection for each process/request). This does not scale well when there are thousands of requests coming per second.

On cloud, Serverless services like AWS Lambda are still not decoupling the client side I/O and Linux process as of today. This is actually not a very good design. Here by "Decoupling" i mean multiple client connections should be served concurrently by the same Worker Process (all connections "fds" can then use same connection pool like for Database).