You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
this code works as you would expect regardless of the runtime, available extension, or application/framework.
one neat thing about it, is that even tho Shell\execute returns a string, it's an async function, meaning while waiting for the output, any other callback in the event loop can be executed!
now assume we have the following scenario in roadrunner worker.
roadrunner receives a payload
the application starts running to provide a response
the application calls Shell\execute which might take a minute to finish
roadrunner worker will need to wait until Shell\execute is finished, before responding, and being able to handle any new connections.
This in my opinion is a waste of time!
roadrunner could have used to time Shell\execute took waiting to accept new connections, start it up, and then go back to the previous one!
I attempted to create a PoC of what a worker/pool scenario like this would look like.
and here, we have 8 workers, each capable of handling 100 concurrent connections ( configurable ), accepting and handling 800 jobs ( were each job executes $ sleep 1 ), in just 4 seconds!
If we would attempt to do the same with roadrunner, it would take 100 seconds!
For this feature to land in roadrunner-worker, there's going to be alot of BC breaks, one of which is the removal of stdin/stdout relay support, as that wouldn't be easy to handle.
I wanted to share this feature idea here as it could help provide better performance of end users.
If interested in seeing how Really\Pool and Really\worker work, i can push it to GitHub, but for now it's just another toy project for me locally 😋 see: https://github.com/azjezz/really
Note: the examples above use azjezz/psl 2.0.x branch.
The text was updated successfully, but these errors were encountered:
P.S: update result for running really\worker, it actually takes 4 seconds, not 17 seconds!
The issue was that i was stopping the poll before waiting for workers, this forces the worker to wait for all running jobs, and we are doing this to all workers serial, instead of concurrently, now when waiting concurrently, the result is 4 seconds, 96 seconds less than roadrunner :)
Note: This feature would only be possible using tcp/unix relay.
we the arrival of
Fiber
in PHP 8.1, writing async code within a traditional PHP application is extremely easy.for example:
this code works as you would expect regardless of the runtime, available extension, or application/framework.
one neat thing about it, is that even tho
Shell\execute
returns a string, it's an async function, meaning while waiting for the output, any other callback in the event loop can be executed!now assume we have the following scenario in roadrunner worker.
Shell\execute
which might take a minute to finishShell\execute
is finished, before responding, and being able to handle any new connections.This in my opinion is a waste of time!
roadrunner could have used to time
Shell\execute
took waiting to accept new connections, start it up, and then go back to the previous one!I attempted to create a PoC of what a worker/pool scenario like this would look like.
and here, we have 8 workers, each capable of handling 100 concurrent connections ( configurable ), accepting and handling 800 jobs ( were each job executes
$ sleep 1
), in just 4 seconds!If we would attempt to do the same with roadrunner, it would take 100 seconds!
For this feature to land in roadrunner-worker, there's going to be alot of BC breaks, one of which is the removal of stdin/stdout relay support, as that wouldn't be easy to handle.
I wanted to share this feature idea here as it could help provide better performance of end users.
If interested in seeing how
Really\Pool
andReally\worker
work,i can push it to GitHub, but for now it's just another toy project for me locally 😋see: https://github.com/azjezz/reallyThe text was updated successfully, but these errors were encountered: