Что касается php, то его производительность может оказаться хуже только по причине того, что в php с этим местом всё плохо, но это уже другой вопрос, решаемый вычеркиванием такого ЯП из своей головы и использованием более добротно сделанных инструментов, у которых и с fastcgi всё впорядке, и работа с памятью правильно реализована.
Во-первых, после того как вы распакуете тело запроса в nginx, то придется отравлять в php уже больший объем данных, соответственно больше операций копирования и, возможно, больше системных вызовов потребуется.
Во-вторых, на время распаковки nginx будет CPU-bound, его воркер не сможет выполнять свою прямую обязанность, как то обрабатывать соединения и запросы других пользователей.
В-третьих, nginx сначала принимает тело запроса в body buffer и если оно в нём не помещается, то складывает его на диск. С распаковкой всё становится ещё сложнее, потребуется ещё один буфер для распакованных данных, которых может быть в несколько раз больше и вероятность необходимости вовлечения диска — значительно возрастает. Кроме того, это создает вектор для атаки на nginx, поскольку передать можно килобайт, который будет пытаться распаковаться в несколько гигабайт. Он конечно осознает, что распакованный ответ превышает заданное ограничение, но для этого ему всё равно нужно будет сперва распаковать его хотя бы до этого ограничения, что для рабочего процесса nginx будет куда критичнее, чем для обработчика php, коих много.
Любая грамотная настройка начинается с вдумчивого чтения манов и хорошего понимания принципов работы настраиваемого сервиса. Больше никаких секретов. На единственный «секрет» ссылку уже дал. А дальше вперед читать документацию по gentoo, sshd, exim, dovecot, nginx, nsd, ejabberd, и т.д., всё, что у вас крутится. Я не вижу, например, никакого смысла в Naxis, если только вы не хостите какое-нибудь ПО сомнительного качества. Не вижу смысла в каких-то упражнениях с iptables, пока вы не столкнулись с какой-то реальной проблемой, и если вы следуете элементарным основополагающим принципам, а именно изолируете сервисы друг от друга, пускаете их под своими пользователями с максимально урезанными правами и не вешаете ничего лишнего на внешние интерфейсы.
Я посмотрел с точки зрения nginx-а. Но видимо вопрос был гораздо шире, тогда грозит ещё обрезанными страницами/файлами, которые клиент считает целыми, в случае ошибки и разрыва соединения в процессе передачи ответа.
Вы написали:
1. чтобы сервер мог отдавать ответ по кускам — это не так, сервер может отдавать ответ по кускам и без chunked encoding.
2. Если его отключить, то сервер должен сохранить ответ от бекенда в буфер — и это тоже не верно, не должен.
Не очень понял, как вы сделали такой вывод, что авторы не знают и при этом привели цитату, которая вполне ясно дает понять зачем он нужен.
Т.ч. если освоите Gentoo то больше не сможете найти более удобную и гибкую систему.
Это верно. Я периодически поглядываю, что там творится с Funtoo и Exherbo, но пока не созрел даже на попробовать.
X-Accel-Redirect
предполгает передачу URI, а не абсолютного пути к файлу. Когда-нибудь такое решено конфигом закончится очень плохо.