Comment by lastangryman | Hacker News Reader

Comment by lastangryman | Hacker News Reader

Used PHP for many years for high volume web applications. My biggest gripe is you (at least had to) run php behind another server (nginx, Apache) which meant your "scope" is always restricted to serving the current request.

If you want to do something like share some heavily read data across processes you need to then introduce memcahe/redis in to your stack, whereas in something like Go this can be done in your application code. This also means PHP is a nightmare for connection management to others resources like your database - if you autoscale your API you are in a very vulnerable place for maxing out connections on your database as every client request needs to create it's own. You can solve this with something like Envoy I think, but again it's adding more complexity to your stack, more tools to configure and deploy.

This was my main issue with PHP. I found the language itself fine to be honest. Not the most elegant but hardly as bad as people make out.

Next time you need to take a look at PHP, those two problems can be solved by php-apcu for caching and proxysql running side-by-side with php-fpm on each server.

Nice, thanks for the heads up on these.

With apcu you're going to pay the cost of serializing/deserializing the data.

If you dump your read heavy data into a PHP file on disk, that just has a return of your generated data, you can be benefit from having that bytecode compiled data stored in opcache for free (for the entire lifetime of the php-fpm service, or until you reach the maximum opcache allocateable memory).

I think that PHP gives you a few nice utilities to handle sharing, but they are problem specific. For example you might also spawn threads within a background PHP task, and there is shared memory functionality you can use in that case as well which is going to be faster than apcu or opcache.

I see comments like this an it always confuses me. AFAIK pooling or proxying a DB is actually worse for concurrent performance, because as soon as you hit the connection limit threads start waiting. It almost always makes sense to increase your DB capacity, or move hot data to a cache.

Latency just connecting to PostgreSQL (in my case) sucks anyway, so I end up having a connection pooler between PHP and the database in production just for the latency's sake, even if I don't care about scaling.

And that solves both issues at once.

check out the swoole extension. async server and faster throughput than any other php setup.

[1] https://openswoole.com/

This looks really interesting and seems like it would offer a similar programming model to node/go/etc. Will check it out, thanks.

Reply on news.ycombinator.com