The main use case is something like: Let's say you've got a mysql query that's going to take a few seconds. In the meantime, you can do some other useful work in PHP while the query runs.
Probably true. But it depends. Let's say you've got 5 queries that take 1 second each.. There's a potential 5x speedup if you can run them in parallel.
I think some basic concurrency support in PHP (such as Futures) would have a pretty huge benefit. The other alternative is to have async APIs for libraries like mysql.
You could argue that anything that is taking too long that it needs parellelizing is probably a candidate for a background queue + frontend polling (or similar).
My web app has a large amount of data that needs random portions to be served by a PHP script. Because speed is of utmost importance, the data resides in RAM.
I first built a working solution in PHP using IPC Shared Memory Segments and later ditched it in favour of PHP+Redis (you could use your own NoSQL datastore of choice of course).
For me, it was way simpler/cleaner to implement and I got a bunch of features for free.
*: SysV shared memory is incredibly clumsy to implement anything more complex than a cache in, and memcached still does a better job of that. There's really very few reasons you would ever want to use it in production code.
Those are all still cruddy SysV IPC methods you're pointing to. They're marginally better than just throwing data into shared memory and hoping it sticks, but you're still much better off sending messages across a UNIX domain socket.
11 comments
[ 2.9 ms ] story [ 20.2 ms ] threadhttp://github.com/dhotson/phork
The main use case is something like: Let's say you've got a mysql query that's going to take a few seconds. In the meantime, you can do some other useful work in PHP while the query runs.
I think some basic concurrency support in PHP (such as Futures) would have a pretty huge benefit. The other alternative is to have async APIs for libraries like mysql.
You could argue that anything that is taking too long that it needs parellelizing is probably a candidate for a background queue + frontend polling (or similar).
Basically anything where you're blocked waiting for a response you could be busy doing something else.
Synchronous APIs are kind of wasteful in a lot of cases. Node.js does a good job of this by using async APIs.
It's a tradeoff. But the extra complexity can be worth it if it means your pages load 2x faster.
I first built a working solution in PHP using IPC Shared Memory Segments and later ditched it in favour of PHP+Redis (you could use your own NoSQL datastore of choice of course).
For me, it was way simpler/cleaner to implement and I got a bunch of features for free.