5 ms·

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 yo

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.

rvr_ 5y ago
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.
- lastangryman 5y ago
  Nice, thanks for the heads up on these.
  - mhitza 5y ago
    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.
- PetahNZ 5y ago
  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.
datalopers 5y ago
check out the swoole extension. async server and faster throughput than any other php setup. [1] https://openswoole.com/ https://openswoole.com/
- lastangryman 5y ago
  This looks really interesting and seems like it would offer a similar programming model to node/go/etc. Will check it out, thanks.
megous 5y ago
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.

rvr_ 5y ago

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.

lastangryman 5y ago
Nice, thanks for the heads up on these.
- mhitza 5y ago
  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.
PetahNZ 5y ago
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.

datalopers 5y ago

check out the swoole extension. async server and faster throughput than any other php setup. [1] https://openswoole.com/ https://openswoole.com/

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

megous 5y ago

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.