I think the standard PHP model (one process per request), while still popular, is being replaced with fairly robust event loops. I've been using Swoole (<a href="https://github.com/swoole/swoole-src" rel="nofollow">https://github.com/swoole/swoole-src</a>) in my company for about a year now, and it has matured into quite a stable code base, even if the documentation is lacking at times. The performance is pretty phenomenal and it has useful async coroutines for interacting with redis/MySQL/PgSQL. I saw some benchmarks in their GitHub issues list where it outperformed Node and Go (taken with a pinch of salt obviously).<p>If you're afraid of something as experimental as Swoole, more stable options do exist, such as ReactPHP. Not quite as performant apparently, but seem to be popular.<p>In general, I find that the PHP ecosystem is still thriving. It's definitely one of the easier languages to get up and running with, and now thanks to the community, it's imbibing some of the more advanced features found in more modern languages.<p>I still love PHP, as much as the 10 year old me did when I started using it 20 years ago. It just gets the job done, even if it is a bit ugly at times!
> we can no longer use f5-debug<p>Sums up what is still one of the major issue-slash-weirdness of the php dev world. For all the frameworks and language advance, despite xdebug existing for over 15 years and working great in pretty much any editor or IDE, most PHP dev including the "experienced" ones have no idea how to use a debugger, or if they do they don't apply it to PHP.<p>Can you imagine debugging your C/C++/Rust/Go/... programs by adding printf everywhere and re-run the whole thing ? Again and again to find which variable fail; while a simple step by step with watches would solve it in a single run, in a tenth of the time, without needing to crappify the source ? That's what 99% of PHP dev still do.<p>Even the javascript world have adopted proper debugger right in the browser. But in PHP it's so freaking terrible that when people need to solve a bug you don't hear "step until you spot the issue" but "var_dump all the things" or "log to the symfony debug bar !".
If the goal is to save resources, maybe it's worth switching to Go entirely.<p>It's a shame the article does not explain what was unsatisfactory about php-pm [1], which is a native php solution that also allows the application to boot just once for all requests.<p>[1] <a href="https://github.com/php-pm/php-pm" rel="nofollow">https://github.com/php-pm/php-pm</a>
I'm also one of those who switched from PHP to Go and now I have quite a bit of legacy PHP code that just works and don't have time to rewrite.<p>My solution:<p>Use a Go FastCGI client library to call PHP by talking directly to php-fpm. It saves on the HTTP request overhead and no need to run a web server. Actually, php-fpm is a decent application server itself.<p>Edit: Here's a link to example code: <a href="https://github.com/tomasen/fcgi_client" rel="nofollow">https://github.com/tomasen/fcgi_client</a>
This probably works ok, but it's doubling down on the terrible that is modern php. PHP has this wonderful conceptual model of get a request, return a response, and throw everything away. The logical consequence is that everything you built up in objects or variables along the way of making your response is garbage (because you're throwing it away when you're done).<p>Since you're just making garbage, it doesn't need to be pretty, it just needs to be fast.<p>Since you're making garbage, it doesn't need to be future proof, it will only be alive for 10ms.<p>You can make some really fast pages with PHP if you try, but modern frameworks are going to take longer to load than a fast page will take to be finished.
40x speedup claim with 0 evidence or reproduction scenario. It's like that meme: "source: trust me dude". The conclusionnis: they made a middleware, something that nginx's auth module does.<p>I want to believe this.
I want to be hyped.
It sounds great.
But there's no reproduction scenario.
Some claims are also false (php doesn't kill the process to start the processing cycle).
Others seem too good to be true - like 40x speedup.<p>It just smells like "hey, we are cool kids too, look at us, we're advertising using the hype that other kids use!".<p>If I'm able to reproduce 40x speedup, I'll so gladly eat my words and flame myself.
Without wanting to sound critical of this, they seem to have reinvented long-lived PHP servers. Gearman has allowed you to do this with PHP for almost ten years now, and it was even the case that you could plug it directly into mongrel2 with 0mq.<p>Fundamentally, it's an idea that works incredibly well - it's amazing that more people don't make use of it....
Classic ASP is a similar framework to PHP. In Classic ASP there are a Session and a Application object. The Session object can store variables that will be available during the user session (using session cookie). And the Application object can store variables that will be available to <i>all</i> other scripts. So when the server starts, you put everything in the Application object, so when you get a new request, you load the data from the Application object instead of re-creating everything, doing database lookups etc on <i>every</i> request. This makes Classic ASP very performant with sub-millisecond requests.
I used Classic ASP until recently and have now switched to Node.JS which uses an event loop. Per-request as in ASP and PHP is <i>much</i> easier then a event loop. In Node.JS for example, it's very common to pull in a framework like Express to do the routing, while PHP and ASP already do that job for you. One problem with ASP and PHP however - they're not optimal for real time stuff like chats or progress-bars.
I had a similar idea a while back. The implementation I came up with (but never implemented) was to create a PHP extension that would link to a statically compiled GO module. Basically it would instantiate a network server on the GO side, and marshal the HTTP request/response data structures back and forth between PHP and Go. I imagined I would probably utilize a pthreads extension or one of the event loop extensions to handle each incoming request:<p><a href="http://php.net/pthreads" rel="nofollow">http://php.net/pthreads</a><p><a href="http://php.net/manual/en/book.event.php" rel="nofollow">http://php.net/manual/en/book.event.php</a>
Can anyone dumb this down for me?<p>I don't really understand this use case - is this for PHP developers to eke out some more performance for their web apps?<p>The goridge library (<a href="https://github.com/spiral/goridge" rel="nofollow">https://github.com/spiral/goridge</a>) makes a little more sense to me; it's a bridge between golang and PHP via RPC.<p>I went through the code (<a href="https://github.com/spiral/roadrunner" rel="nofollow">https://github.com/spiral/roadrunner</a>) but it doesn't seem like something you can swap into an existing PHP project. Can anyone explain what use case this might be for?
Found another rilkef: <a href="https://christine.website/blog/experimental-rilkef-2018-11-30" rel="nofollow">https://christine.website/blog/experimental-rilkef-2018-11-3...</a>
PHP is the worst programming language ever made in current widespread use. There was never an excuse to use it, there were always other options, even many years ago.<p>> "To them, we say “think again.” We believe that the only limit PHP has is the limit you set."<p>You shouldn't be writing PHP in the first place, and should slowly work to (incrementally, slowly) shift your codebase into any other programming language in existence if it is already written in PHP.<p>The core language is terribly designed. PHP 7 did not fix this. Even JavaScript is miles better (PHP has a type system equally as bad, if not worse).<p>Of course, this sentiment is unpopular, because you're never supposed to rewrite anything even incrementally, and Popular Means Quality, and saying otherwise is heresy.<p>I propose the more radical solution of killing PHP entirely (again, incrementally, slowly), and replace it entirely with the language of your choosing (maybe that's Go).