Introduce PHP Fiber to Laravel; e.g., to support parallel DB querying

[Vectorial1024]

A continuation of the issue from the archived repo: laravel/ideas#2540

It seems there are some opportunities to achieve parallel processing in Laravel by using PHP 8.1 Fibers, e.g. by introducing parallel DB querying.

---

First responding to the original post, it mentioned 4 contexts:

1. Laravel HTTP Client
2. Database Connections
3. Laravel Unit Testing
4. Laravel Request/Response context

Some of the above contexts actually do not need PHP Fibers to be processed in parallel:

• Context 1: Guzzle HTTP or even the PHP curl extension can already process parallel requests by themselves update: I remembered something wrongly, see Introduce PHP Fiber to Laravel; e.g., to support parallel DB querying #47077 (comment)
• Context 3: we may use a Laravel variant of Paratest to test in parallel (see https://blog.laravel.com/laravel-parallel-testing-is-now-available)
• Context 4: it depends on the server config, but e.g. Apache can use MPM to handle incoming HTTP requests "in parallel" (see https://httpd.apache.org/docs/2.2/mod/worker.html)

This leaves Context 2 unresponded.

---

This is where I think Fibers may be useful to Laravel: database connections. Specifically, the potential ability to run multiple DB queries in parallel without one blocking the other.

One existing use case could be this: sometimes, when I try to insert many data into MySQL via Laravel Eloquent, I find that the data size exceeded the MySQL binding limit of 65536. To insert them, I will have to chunk them into several queries. However, if I know that the exact order of insertion does not matter, then I can use Fibers to issue several parallel queries to the DB, and just wait all of them to complete.

So, instead of this:

$chunks = array_chunk();
foreach ($chunks as $piece) {
   DB::insert($piece);
}

Perhaps I can do the following:

(pseudocode)
DB::insert()->chunkToBindingLimit()->parallelizeWithFiber();

One potential new use case is this: e.g., for whatever reason, I know that I will have to load quite some data from multiple DB tables, and I already know for each table which IDs are needed. Those tables are not related to each other through foreign keys, etc. Currently I have to do something like this:

// (existing)
$a = TableA::query()->whereIn()->get();
$b = TableB::query()->whereIn()->get();
// $b needs to wait for $a, but $b is unrelated to $a

Then, with Fibers, since both tables are unrelated, perhaps I can do something like this:

(pseudocode)
$a = null, $b = null
DB::doParallel({
    load TableA with where, store at &$a,
    load TableB with where, store at &$b,
});
// now $b and $a are available at the same time

---

Of course, parallel DB querying can be done already without using Fibers (can be discussed in another topic). But for something this fundamental, it is surprising that there is no equivalent operation in Laravel or any of its dependent libraries. What we currently have close to parallel querying is when loading relations in one line of code, but if those data are not related by relationships, then we currently have nothing.

Therefore, it seems Laravel can try to use Fiber to allow for DB querying in parallel.

[Sophist-UK]

As far as I can tell (i.e. guess), and as stated above, you would indeed need to programme your application to do things in parallel i.e. have some Laravel interfaces to start things running in parallel and then to wait until one or more of them have completed and the data is available. IMO ideally you would want this to be a lot more flexible than the pseudocode above which is a way of parallelising just DB calls and then wait for them all to complete. So e.g.

• You might want to run Database, HTML and file access in parallel with one another;
• You might want to do some process on some parallel tasks where the I/O has completed for some whilst continuing to wait for other parallel tasks to complete.
• Even for database access, you might want to use one or more or a mixture of DB, Query Builder, Eloquent etc.

In other words you might want to do something more akin to:

(pseudocode)
doParallel({
    doParallel({
            load modelA;
            preprocess_modelA;
    }, {
            load modelB;
            preprocess_modelB;
    });
    process_modelsAandB;
    html_get_dataC;
},{
    doParallel({
            load modelD;
            preprocess_modelD;
    }, {
            load modelE;
            preprocess_modelE;
    });
    process_modelsDandE;
});
process_modelsAthroughE;

In essence you need to have some generic way of splitting into parallel streams and then combining them back again, and you would need the whole of the Laravel code to be Fibre safe/aware against random sequencing of access to shared objects (in the same way that other languages that use native threading need to be thread safe/aware).

PHP closures would appear (at first glance) to help with this, because "A closure encapsulates its scope, meaning that it has no access to the scope in which it is defined or executed.".

It appears to me that the four challenges are:

1. Syntactic - making it easy and Laravel-like to create code which takes advantage of the parallelism;
2. Technical - making every part of Laravel robustly support this syntax;
3. Testing - enhancing the test infrastructure and actual tests to prove that the code is reliable regardless of the sequence in which parallel tasks execute.
4. Packages - ensuring that all the Laravel packages also support parallelism (or ideally doing it technically in such a way that this will be the case by default except for a defined list of exception programming techniques). You might in fact want Composer to have a flag that says whether a package supports parallelism, and (because Composer is PHP-wide and not just Laravel) that might then imply that the parallelism technical approach should be PHP-wide and not just Laravel-wide.

I suspect that these are NON-TRIVIAL.

[rasmuscnielsen]

Context 1: Guzzle HTTP or even the PHP curl extension can already process parallel requests by themselves

Could you give a bit more context to this one - are there options available in Guzzle which provide fully non-blocking parallel requests?

Laravel has some parallel functionality in the Http client too, but AFAK these are blocking and runs in separate threads. It would truly be a game changer if parallel Http requests could be implemented in a non-blocking way. I've come across https://amphp.org, but I've yet to try out if it can be combined with Laravel Http client.

[Vectorial1024]

are there options available in Guzzle which provide fully non-blocking parallel requests

Upon self-reflection, I realized I have remembered the entire thing wrongly.

Even if we use php-curl, we still encounter this section of code:

// pseudocode
$multi = curl_multi_init();

// add your requests here...
curl_multi_add_handle($multi, null);

// let's say all the requests are already added to the multi-curl instance...

// note that no HTTP requests have been sent yet!

$active = null;
do {
    // this blocks until there is an update
    // this update can be e.g. "requests sent", "response received", "timeout"
    $status = curl_multi_exec($multi, $active);
    // you can now do something else, e.g. sleep(10);
    // you can always call curl_multi_exec() again to see how things are going, and receive the responses etc.
} while ($active);

So yeah, the entire PHP HTTP situation is unfortunately blocking. Apologies for mistaking things.

---

Therefore, the idea by @rasmuscnielsen about implementing a truly non-blocking HTTP client is suddenly very attractive to me.

I've also come across AMPHP myself earlier, but I have largely forgot about it until the mention; and I also have not tried it yet.