What's the advantage of using AMP Server vs the traditional route (Niginx, Apache etc.)?

[abdullahseba]

Hi,

I'm looking to create a new app with AMP integrated and I wasn't sure what the advantage of using PHP to serve directly with AMP server vs the FastCGI approach. Are there any major pros or cons?

Thanks!

[xpader]

Why did you want to use AMP? If you don't know why, then don't use.

[abdullahseba]

Haha, a most excellent non-answer. I'm using it for its concurrent capabilities. But I'm not sure how concurrency works with FastCGI, what the pros and cons are, and if a hybrid approach can be taken. I would assume something like Nginx has more features as a HTTP server than this library, and I have no experience of using Nginx as a proxy. It may be that using Nginx as a proxy gives you much the same advtanges as with FastCGI, I don't know. There's plenty of documentation on this with NodeJS as that's it's standard behaviour, but I'm not finding much on PHP. I assume it's something relatively new and I'm curious how production-ready it is.

[xpader]

The biggest advantage of AMP is that it can perform multiple concurrent IO operations in a single process at the same time.
PHP FastCGI, One php-fpm process can perform only one IO operations at same time.

[kelunik]

Another advantage is being able to keep things in memory. For production you'd likely put nginx or some other HTTP server in front to serve static assets and use it as reverse proxy instead of FastCGI for dynamic application requests.

[abdullahseba]

Makes sense. It's difficult to understand how the architecture works from the docs. Am I right in thinking this essentially makes it the same as Node JS? Node JS is single-threaded but has native syntax sugar as I understand it. I previously thought something like that wasn't at all possible with PHP unless an extension is used - like what Swoole does.

[razshare]

To build on what @kelunik said, since it's just one process, you can get away with doing some weird specific things with shared memory.

For example, if you go with this architecture, suddenly forks become more attractive by default.
The parent process can share some memory ids with its children at launch.
You pay a bit in memory usage because forks copy the whole program in memory (if you do it well it will be at most a 30-40 MB penalty per child), but you achieve in memory communication, instead of using message exchange.

Forking is just one example.

Another (perhaps better use case) is taking advantage of the JIT, because your program usually lives longer, giving the JIT more chances to optimize.

Another big one, you might think this is a stretch (I don't think it is), but moving the community towards this type of programming opens php to being more general purpose, and you get nice things like php-sdl and raylib-php, which fit well with async programming.