Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104437
MIME-Version: 1.0
References: <BYAPR02MB5766B8D8FCE674BF544B7FB0BF660@BYAPR02MB5766.namprd02.prod.outlook.com>
 <CAF+90c9uK1+xW1HbUq5BeiWxxP6bNb6CiVS6AXMoBNo1OMPKVw@mail.gmail.com>
 <CAOwTYAvx7igQW3BhKvnbUvzj7qOfw3GcQc=4jUFr-y876Ao42A@mail.gmail.com>
 <CAJHtznzrUK=HykJfvHi8i_AW-0BXWkdTe14MECxVYbdTuxrudw@mail.gmail.com>
 <d9464082-3839-c51a-6591-e0ed2b6d4201@gmx.de> <CALKiJKqFsN5R8b7i=t3QyT-vC-0pcsOYD=G6taXXBVDuSjkcQw@mail.gmail.com>
 <CAOwTYAsoMNUw3Pm_eHy2zf7NVB8iG3Y7VvA=Ovh+_ymTyaa5HQ@mail.gmail.com>
 <CAJHtznxmLaT1xeT7HHoJaa+Su_bt4Rozfk03wUfaY9A1Uin+dQ@mail.gmail.com>
 <CAFMT4NogTLm3-g8MuPt5rA2qMCMZemTr8wMcOJv1fN+Az4FuAQ@mail.gmail.com>
 <CAJHtznze_scKea1xE-jpkep0tVVLZyw0DuQ+oGK-2xFOETMVsw@mail.gmail.com> <CAEPJdunO-r6raYAG2GQEmO2YmAMNzPnP3Jzkcnxx8cQjP-v9CQ@mail.gmail.com>
In-Reply-To: <CAEPJdunO-r6raYAG2GQEmO2YmAMNzPnP3Jzkcnxx8cQjP-v9CQ@mail.gmail.com>
Date: Fri, 15 Feb 2019 11:12:29 +0000
Message-ID: <CALKiJKq55JhvW8FFoOVgc6pvm-oJPYPQo0fi3di8YVAL6L=rdA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000071e1e20581ecda7b"
Subject: Re: [PHP-DEV] Re: ZTS improvement idea
From: rowan.collins@gmail.com (Rowan Collins)

--00000000000071e1e20581ecda7b
Content-Type: text/plain; charset="UTF-8"

On Fri, 15 Feb 2019 at 07:26, Benjamin Eberlei <kontakt@beberlei.de> wrote:

> This is like the 80% use-case of threading, Multiple HTTP requests, multiple long running SQL queries. An API like parallel would allow each and everyone of us to make controllers faster today without a large effort.
>
>
I think an expanded example would better demonstrate the power of this.
Consider a search API that aggregates other search APIs; for each API, it
will need to do several steps:

- Look up code mappings in a DB to convert input into format needed by this
API
- Perform an auth request to get a fresh token
- Send the search API call
- Look up more code mappings to convert the response
- Post-process results into a standard form

The challenge is to call as many APIs as possible at once, and get the
results to the user. The slow parts of this are mostly I/O bound, but to
take advantage of async I/O you need to rewrite not just the I/O parts but
the entire process to use some async framework. Maybe there's even parts
that are CPU heavy in between the requests - a complex cryptographic
algorithm, for instance - that async I/O wouldn't help with at all, but
which could happen on separate cores when load was low.

It would be absolutely amazing if you could use something like Joe's new
parallel extension to handle this workload: run the handling of each API as
a thread, and leave the code inside them entirely unchanged.

I realise it's probably not as simple as that in practice, but to me, the
ability to adapt existing code is a huge benefit of a straightforward
parallel/thread/worker API over one based explicitly on async I/O.

Regards,
-- 
Rowan Collins
[IMSoP]

--00000000000071e1e20581ecda7b--