Nginx Unit + PHP seems to handedly out-perform Nginx + php-fpm[1][2][3]. Also, Docker environments running PHP via Nginx Unit will no longer need separate containers for http + fpm, as it works similar to Apache's mod_php. 1. https://habr.com/en/articles/646397/ 2. https://medium.com/@le_moment_it/nginx-unit-discover-and-ben... 3. https://github.com/nginx/unit/issues/6#issuecomment-38407362...
You don't need separate containers to run nginx and php-fpm.
I too would like to see a properly configured php+php-fpm container benchmark. There's a lot of overhead when you link by http instead of a unix socket, in the same container.
Well I commend the Nginx team for trying something new and launching this, even though I'm not sure what I would use it for personally. Slightly tangental, but it always irks me when I see these kinds of responses in JSON: { "success": "Reconfiguration done." } Really this should be something like "result": "success". Using "success" as a key name tells me nothing about the data it's representing.
If I were designing it I’d probably have a result field too, or even a success boolean. But I don’t hate what they’re doing here: the presence of the key is the Boolean value, the value is the description. A two for one.
An economy not worth investing in in my book. It’s always more clear to separate success and result. Sometimes, you’ll have no result, so there will be some parasitic (or truthy) value like null or true. And when you check success-named result deeper/further in code, it looks like you’re indexing into a boolean. Trying to make it clear on-site creates miniprotocols not worth remembering. Worst case scenario is {success:x, error:y}, x and y being 4 combinations of null and non-null, where you aren’t even sure what happened and may swallow a false positive with an optimistic check. Also, since undefined is not in json standard, the existence becomes ephemeral in languages where that’s distinct from just being undefined. You may think that returning undefined from a wrapped worker is okay, but it results in “error encountered: undefined” down the line due to {} payload. It’s one of the things that make programming harder for no good reason.
You don't need separate containers to run nginx and php-fpm.
does it involve running supervisor inside the container? that’s fine but it’s definitely not kosher. in my experience those are the ones that kick and scream when they don’t start as root.
Well I commend the Nginx team for trying something new and launching this, even though I'm not sure what I would use it for personally. Slightly tangental, but it always irks me when I see these kinds of responses in JSON: { "success": "Reconfiguration done." } Really this should be something like "result": "success". Using "success" as a key name tells me nothing about the data it's representing.
That's like when I see APIs that give you responses with a 200 code, but then in the message there's a backend error.
The opposite of that is people who try to loosely project the variety of error modes their app has to http status codes. You then print out a table of http code actual meaning and try to outline ranges and messages you want to handle differently. On top of that, their backend may be down and you have to deal with bare reverse proxy statuses as well, which adds another dimension to that mess.
You don't need separate containers to run nginx and php-fpm.
I too would like to see a properly configured php+php-fpm container benchmark. There's a lot of overhead when you link by http instead of a unix socket, in the same container.
Technically, you should be able to share a domain socket via a shared volume too (between an "app" and "web" container) - as with postgres:
Nginx Unit + PHP seems to handedly out-perform Nginx + php-fpm[1][2][3]. Also, Docker environments running PHP via Nginx Unit will no longer need separate containers for http + fpm, as it works similar to Apache's mod_php. 1. https://habr.com/en/articles/646397/ 2. https://medium.com/@le_moment_it/nginx-unit-discover-and-ben... 3. https://github.com/nginx/unit/issues/6#issuecomment-38407362...
Those benchmark outcomes are ridiculously in nginx-unit’s favor over php-fpm, way more than I would have believed was possible. What is php-fpm doing architecturally that is so different to warrant such poor relative performance?
You see similar performance improvements in bencharmarks of Litespeed & PHP LSAPI [1].
Unfortunately said benchmarks are usually done by the software company making said webserver, so have to be taken with a pinch of salt.
> Yes, this is as bad as it looks: “success” isn’t even part of the schema. It’s in the examples, but not the actual schema definition. Having gone through a pretty heavy overhaul of an "OpenAPI" (full code in Elixir at https://github.com/etalab/transport-site/pull/3351 ), I stumbled on that exact type of problem! At the scale of nginx, having automatic verification that the examples (and the output of the API in gen…
I recently found this open source postman typed alternative, hadn't had time to really try it yet but the types stuff should help here no? https://recipeui.com/
The type support in OpenAPI is fairly good (enough for us), and using a tool directly built on our stack allows nice things.
Well I commend the Nginx team for trying something new and launching this, even though I'm not sure what I would use it for personally. Slightly tangental, but it always irks me when I see these kinds of responses in JSON: { "success": "Reconfiguration done." } Really this should be something like "result": "success". Using "success" as a key name tells me nothing about the data it's representing.
Why including that in the response body? 200 status code states everything.
Why the obsession (it seems to be the prominent point in the readme) with configuration via API? How often do you need to add php support on the fly? I want to configure my app server via files so it just starts up in the state that I expect. What am I missing?
Why? To scale infra of my offering to my customers. They need it too. I’d like for my remaining customers to not suffer downtime. I’d like to use the existing infra I have without spinning up new ones. I’d like to offer a dashboard so my customer can configure their host.