Edit report at https://bugs.php.net/bug.php?id=74178&edit=1
ID: 74178
Comment by: spam2 at rhsoft dot net
Reported by: alex at alex-at dot ru
Summary: Suggestion/Idea: Stateful / Application Script
Status: Open
Type: Feature/Change Request
Package: FPM related
PHP Version: Next Major Version
Block user comment: N
Private report: N
New Comment:
here you go: http://appserver.io/
if the initialization time is your problem than make your script a long running process the one or
other way, initialization of all database connections is no problem - persistent connections exists
Previous Comments:
------------------------------------------------------------------------
[2017-02-28 05:33:07] alex at alex-at dot ru
>>> for that below you ... use the wrong programming language
And it finally came to to what the entire request is about, why and what for. Thanks. People still
think that way, and this feature can help reduce 'PHP is wrong for that' way of thinking
at least a certain bit.
First of all, 'PHP is wrong for that' thing is total BS, at least in our case. It already
works for us, it took very small time to develop the app, the app is stable, manageable and
satisfies clients' needs. Porting state generation / Asterisk/gateway/PBX/phones integration
code to anything without handy things like associative arrays and lax typing would be so much pain
in the neck and take so much time/effort that we don't even consider it viable.
Then, the performance is already ok for us. We see it can be improved in terms of performance by
using different coding paradigm for parts of it, and see a clear way for PHP, hence the request.
------------------------------------------------------------------------
[2017-02-27 20:12:46] spam2 at rhsoft dot net
problem is that you don't gasp how FPM works
isloated processes to overcome the problems of a threading server (memleaks, non-thread-safe
libraries and many more) - whatever you cache and try to be stateful needs to consider how it can be
shared between the processes which are there for one reason: isloation
frankly that don't work even for things existing over a decade like https://bugs.php.net/bug.php?id=73888 where even
the real_path cache is completly useless in real workloads
__________________________
for that below you don't oly use the wrong programming language you are in fact most likely
even use the wrong operating system, at least a default linux kernel is *not* RT capable at all
A very good example of it is large telephony system state. We need to push each extension state to
each state database client approximately each 0.5 seconds. States and channels information gets
pushed to application handling client request via ZeroMQ in real time (and it is combined with
specific client data), but alas we have to reload full state each time each client request is
started
------------------------------------------------------------------------
[2017-02-27 20:10:34] alex at alex-at dot ru
By realtime, I mean applications dealing with lots of requests for partially changing state, where
reloading all the state information all the time can be costly, uses lots of CPU time and eventually
makes response times go out of required scale.
A very good example of it is large telephony system state. We need to push each extension state to
each state database client approximately each 0.5 seconds. States and channels information gets
pushed to application handling client request via ZeroMQ in real time (and it is combined with
specific client data), but alas we have to reload full state each time each client request is
started.
------------------------------------------------------------------------
[2017-02-27 20:02:02] alex at alex-at dot ru
>> seriously - it don't work that way in no environment
I don't know where you got this 'double cores = double requests' thing. I'm
talking about quite the contrary as well. For math, 1000/1.1 = 909.something, do you want it or not.
Your i7 was able to run 1.3 request in parallel at average, hence the ~1200.
---
Next thing, I'd prefer to stop the empty bickering here, it's completely pointless.
The whole point of this ticket is that _realtime_ applications like gaming, monitoring, telemetry or
realtime process management can all be encompassed by PHP as well with a relatively small change not
introducing any heavy complexity internally.
I'm quite sure PHP devs already considered this one multiple times, so this is just in case it
simply got lost/forgotten in the pile of things to evolve :)
------------------------------------------------------------------------
[2017-02-27 19:52:52] spam2 at rhsoft dot net
> 1000/1.1 is obviously about 909 requests per second per core
seriously - it don't work that way in no environment as well as "oh, i double the cores
and get twice requests per second" don#t work in real life
also no idea why the feature request is "FPM related" and if what ever you consider would
be FPM specific and not work the same way with mod_php you clearly see it has no place in the
ecosystem
get xdebug and look where you really lose performance
at the same time realize that benchmarking is *not* that easy as you may think - when as example
mod_defalte is part of the game php requests are even faster handeled than static files with the
same content
so before you think you need new features please learn how to benachmark na drealize *waht* youa re
benchmarking in reality - often this are two different things
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=74178
--
Edit this bug report at https://bugs.php.net/bug.php?id=74178&edit=1