The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Выпуск сервера приложений NGINX Unit 1.11.0"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от opennews (ok), 20-Сен-19, 07:35 
Увидел свет выпуск сервера приложений NGINX Unit 1.11, в рамках которого развивается решение для обеспечения запуска web-приложений на различных языках программирования (Python, PHP, Perl, Ruby, Go, JavaScript/Node.js и Java). Под управлением NGINX Unit может одновременно выполняться несколько приложений на разных языках программирования, параметры запуска которых можно изменять динамически без необходимости правки файлов конфигурации и перезапуска. Код написан на языке Си и распространяется под лицензией Apache 2.0. С особенностями NGINX Unit можно познакомиться в анонсе первого выпуска...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51524

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Выпуск сервера приложений NGINX Unit 1.11.0"  +4 +/
Сообщение от zo0Memail (ok), 20-Сен-19, 07:35 
збс, давно ждал, спасибо
Ответить | Правка | Наверх | Cообщить модератору

21. "Выпуск сервера приложений NGINX Unit 1.11.0"  +3 +/
Сообщение от Ан (??), 20-Сен-19, 10:55 
Количество комментариев намекает на его нужность ....
Ответить | Правка | Наверх | Cообщить модератору

86. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от zo0Memail (ok), 22-Сен-19, 08:22 
о, да
Ответить | Правка | Наверх | Cообщить модератору

2. "Выпуск сервера приложений NGINX Unit 1.11.0"  –4 +/
Сообщение от Анонимemail (2), 20-Сен-19, 08:51 
А разве NGINX сам по себе не отдавал статику?
Ответить | Правка | Наверх | Cообщить модератору

3. "Выпуск сервера приложений NGINX Unit 1.11.0"  +10 +/
Сообщение от Аноним (3), 20-Сен-19, 08:58 
NGINX и NGINX Unit это совершенно разные вещи.
Ответить | Правка | Наверх | Cообщить модератору

87. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от zo0Memail (ok), 22-Сен-19, 08:23 
Nginx отдавал, Nginx Unit нет
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

22. "Выпуск сервера приложений NGINX Unit 1.11.0"  –1 +/
Сообщение от Aytishnik.com (ok), 20-Сен-19, 10:58 
Молодец Игорь Сысоев, теперь спокойно работает, главное вовремя понять, когда надо уезжать.
Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск сервера приложений NGINX Unit 1.11.0"  +3 +/
Сообщение от пох. (?), 20-Сен-19, 11:38 
главное вовремя понять, куда.
А "когда" наступает примерно как можешь отдельно от мамкиной сиськи куда-то ездить.

Ответить | Правка | Наверх | Cообщить модератору

27. "Выпуск сервера приложений NGINX Unit 1.11.0"  +2 +/
Сообщение от Аноим (?), 20-Сен-19, 11:53 
Не, ну чуть попозже, всё же)
Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от test (??), 21-Сен-19, 00:36 
До этого не спокойно работал? Поделитесь о чем речь.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

98. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Lex (??), 25-Сен-19, 08:29 
Надо полагать, примерно об этом:

11 марта 2019 года объявлено, что компания F5 Networks покупает NGINX. Сумма сделки оценивается приблизительно в 670 миллионов долларов

Ответить | Правка | Наверх | Cообщить модератору

23. "Выпуск сервера приложений NGINX Unit 1.11.0"  +9 +/
Сообщение от Аноним (23), 20-Сен-19, 11:01 
Да что за бич опеннета с версткой?

маркеры маркированного списка плывут и на телефоне и на компе.

А еще недавно в новости забыли поставить закрывающий тег ссылке. 100% автор не осилил какой-нибудь markdown и пишут на голом html.

А чтоб не подумали что я ваще злой - скажу что это все же лучший ресурс из русскоязычных ;)

Ответить | Правка | Наверх | Cообщить модератору

28. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Аноним (28), 20-Сен-19, 12:10 
> не осилил мрак даун
> где три с половиной возможности форматирования
> пишут на голом html
> полноценном языке разметки

уж лучше голый html

Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск сервера приложений NGINX Unit 1.11.0"  –3 +/
Сообщение от Аноним (31), 20-Сен-19, 13:08 
они оверинженеры, там и бэкенд на страшной жабе!
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

35. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от iPahcae6 (?), 20-Сен-19, 14:24 
Все хуже. То едут, то не едут
С десктопа едут под игровой виндой, не едут под рабочей линухой. С мобилы едут с Brave на Android и вроде не едут с Firefox(либо с чего-то еще более маргинального даже, не помню точно)
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

36. "Выпуск сервера приложений NGINX Unit 1.11.0"  –1 +/
Сообщение от Аноним (31), 20-Сен-19, 14:25 
"Работают лучше Fronend специалисты индустрии"
Ответить | Правка | Наверх | Cообщить модератору

50. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от KonstantinB (ok), 20-Сен-19, 21:26 
.chtext li {
    text-indent: 0;
}
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

62. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от Maxim Chirkovemail (ok), 21-Сен-19, 10:19 
Спасибо, поправил. Расстановка отступов в CSS на сайте не менялась лет 15 и сдвиг стал наблюдаться только в предпоследнем выпуске Chrome, после того как они добавили break-spaces и что-то поменяли в логике разрыва строк. Думал, что эту регрессию устранят в новом выпуске, но она так и остаётся. Интересно, что проявляется не для всех li, а только выборочно и, как правило, единично. Причины, по каким съезжает, а по каким нет, точно я не уловил, заметил лишь, что если следом идёт pre, как в этой новости, то текст смещается.
Ответить | Правка | Наверх | Cообщить модератору

66. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от KonstantinB (ok), 21-Сен-19, 16:55 
Да, в предпоследнем хроме вообще дров наломали. На паре сайтов, которые я не трогал уже пару лет, поломалось всякое, от подобных мелочей до полного схлопывания до нулевой ширины некоторых div-ов при динамической работе с DOM. Костыли везде придумал, но хром с его монополией явно начинает превращаться в очередной IE.
Ответить | Правка | Наверх | Cообщить модератору

93. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Аноним (31), 22-Сен-19, 09:51 
Ты придумал Reset CSS, который используют все Frontend разработчики. normalize.css чуть иной.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

94. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Аноним (31), 22-Сен-19, 09:54 
https://pastebin.com/r7CN7kve
Ответить | Правка | Наверх | Cообщить модератору

24. "Выпуск сервера приложений NGINX Unit 1.11.0"  –4 +/
Сообщение от пох. (?), 20-Сен-19, 11:37 
интересно, на открытую версию nginx-не-юнит окончательно теперь будет положен $@й, или он на ней уже давным-давно лежит?

Ответить | Правка | Наверх | Cообщить модератору

26. "Выпуск сервера приложений NGINX Unit 1.11.0"  +4 +/
Сообщение от kiwinix (?), 20-Сен-19, 11:53 
Вообще есть повод для таких догадок?

Мое ИМХО - nginx просто в идеальном и стабильном состоянии. Вообще никаких нареканий у меня нет

Ответить | Правка | Наверх | Cообщить модератору

37. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Аноним (31), 20-Сен-19, 14:27 
GZIP нельзя отключить для html контента при HTTPS.

BREACH Attack!

Ответить | Правка | Наверх | Cообщить модератору

56. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от пох. (?), 20-Сен-19, 22:52 
> Вообще есть повод для таких догадок?

не-опоздание родиться за повод считается?

Я прекрасно помню как он развивался до версии 1., и что с ним случилось после.

> Мое ИМХО - nginx просто в идеальном и стабильном состоянии.

"а на кладбище - все спокойненько!"

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

33. "Выпуск сервера приложений NGINX Unit 1.11.0"  +10 +/
Сообщение от Valentin V. Bartenev (?), 20-Сен-19, 13:45 
Без паники. Над Unit и nginx работают две независимые команды. Причем на данный момент команда nginx даже больше. Фактически из бывших разработчиков nginx над Unit-ом трудятся только Игорь и я. Но Игорь и так не работал над nginx ещё с 2012, а я с 2017, что не мешает nginx-у продолжать активно развиваться последние годы.

Это две разные идеологии построения веб-сервера и мы не собираемся никого насильно пересаживать с одного на другое. Какая окажется доминирующей - время покажет. Я верю в Unit.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

38. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Аноним (31), 20-Сен-19, 14:30 
> Но Игорь и так не работал над nginx ещё с 2012, а я с 2017, что не мешает nginx-у продолжать активно развиваться последние годы.

Теперь понятно почему в NGINX больше не производиться работа над доработками.
trac.nginx служит как bash.org.

Ответить | Правка | Наверх | Cообщить модератору

40. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от Valentin V. Bartenev (?), 20-Сен-19, 15:29 
А о каких конкретно доработках идет речь? Множество доработок происходит регулярно. Количество реализуемых фич с момента создания компании возросло в разы, но в 10 раз увеличилось и количество пользователей.

По trac-у очень сложно судить о востребованности той или иной функциональности. Мы собираем информацию из множества разных источников.

Ответить | Правка | Наверх | Cообщить модератору

42. "Выпуск сервера приложений NGINX Unit 1.11.0"  –1 +/
Сообщение от Аноним (42), 20-Сен-19, 15:50 
1. https://trac.nginx.org/nginx/ticket/1083
2. https://trac.nginx.org/nginx/ticket/1388
3. HPACK Dynamic Table Size in HTTP/2
   https://http2.github.io/http2-spec/compression.html#dynamic....
4. Accept-Encoding
   The "identity" content-coding is always acceptable, unless
   specifically refused because the Accept-Encoding field includes
   "identity;q=0", or because the field includes "*;q=0" and does
   not explicitly include the "identity" content-coding. If the
   Accept-Encoding field-value is empty, then only the "identity"
   encoding is acceptable.
5. HTTP/2 prioritization is intermittent and often ineffective
   https://trac.nginx.org/nginx/ticket/1763
6. AIO kernel feature io_uring pool Linux kernel 5.1+

Продолжать?

Ответить | Правка | Наверх | Cообщить модератору

45. "Выпуск сервера приложений NGINX Unit 1.11.0"  +8 +/
Сообщение от Valentin V. Bartenev (?), 20-Сен-19, 18:00 
1. По многим реализуемым фичам поступают десятки запросов в месяц, а тут 1 человек тикет создал и 1 человек в нем отметился. Итого целых два человека за три года.

И не понятно, что мешает выключить gzip для проксируемых запросов. И это решение человек сам в том же тикете обнаружил. Вообще выключать компрессию для динамических HTML ответов - идея так себе. Тогда компрессия и не особо нужна, статика браузером будет кэшироваться и для нее есть gzip_static.

Если у вас злоумышленник может извне свободно контролировать содержимое ответа сервера конкретному пользователю, то у вас проблемы по умолчанию. С компрессией или без.

2. Для CF было толково в рассылке разобрано, почему это нормально не работает в реальных сетях, но они очень любят пиарить себя любимых.

3. Было бы конечно не лишним. Но не всегда и не для всех. При достаточно смешной экономии на заголовках, получаем существенное увеличение расхода памяти на каждое соединение. HTTP/2 сам по себе и так довольно затратный протокол, сплошной вектор для DoS-атак, а тут ещё дополнительные накладные расходы возникнут.

4. Ни одного запроса про это вспомнить не могу. Впрочем я уже не слежу так активно, так что не могу прокомменитровать никак.

5. Максим в тикете дал ответ. Проблемы HTTP/2 более-менее решаются с помощью HTTP/3, а остальное всё полумеры и различные хаки, ещё больше усложняющие и без того переусложненный протокол. Безусловно есть также и поле для улучшения в nginx в этом месте, но это не значит, что нужно все ресурсы тратить на игры в протокол от одной всем известной компании.

6. Для начала необходимо протестировать и измерить, есть ли какой-то выигрыш для паттерна использования nginx-а и стоит ли этот выигрыш тех возможных проблем и усложнений, с которыми предстоит иметь дело. Кроме того, на 5.1+ сейчас хорошо если хотя бы 1% установок nginx наберется, но скорее всего и того меньше.

Это исключительно мой взгляд со стороны, поскольку непосредственно над nginx уже больше двух лет не работаю и никаких решений не принимаю. Крайне наивно пологать, что вот мы там в nginx такие сидим вредные и не хотим реализовывать те или иные фичи на радость пользователям. Все заняты делом и работают над задачами, которые формируются на основании комплексного анализа множества факторов, огромных объемов информации. Мы варимся в этом котле по меньшей мере пять дней в неделю на протяжении многих лет. Каждый день занимаемся этими вопросами. Это наша ежедневная работа, труд множества людей. Просто изнутри крупнейшего вендора серверного ПО с миллионами пользователей, ситуация и картина мира выглядит несколько иначе, нежели со стороны отдельных энтузиастов.

Ответить | Правка | Наверх | Cообщить модератору

107. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Аноним другой (?), 25-Мрт-20, 23:58 
Валентин, что сейчас думаете про io_uring?
Ответить | Правка | Наверх | Cообщить модератору

43. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Аноним (42), 20-Сен-19, 15:54 
cache-aware learning server-push https://h2o.examp1e.net/configure/http2_directives.html#http...
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

48. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 20-Сен-19, 19:15 
Добрый день, Валентин!
У меня давно уже назрел вопрос.
На текущий момент у меня веб сервер на Apache + FastCGI + php-mod_fastcgi
Я уже давно хочу мигрировать или на nginx + php-fpm или на nginx unit (он наконец-то научился отдавать статику), но пока всё руки не доходят.
На Apache, в принципе, меня всё устраивает за исключением отсутствия 0-RTT и так и не начавшуюся работу над HTTP/3.
Из необходимых возможностей мне нужно чтение .htaccess и .user.ini файлов.

С точки зрения производительности и удобства на что лучше мигрировать и какие достоинства и недостатки у этих решений, а также какие трудности и особенности миграции с Apache для каждого из них.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

51. "Выпуск сервера приложений NGINX Unit 1.11.0"  +2 +/
Сообщение от KonstantinB (ok), 20-Сен-19, 21:31 
Я не Валентин, но - если вам нужен .htaccess (действительно нужен, а не банально лень сконвертировать конфиги), то вам от Апача никуда не деться, просто по определению.

Посчитайте число системных вызовов, которое надо выполнить на каждый запрос для реализации аналога .htaccess, заплачьте и забудьте.

Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от пох. (?), 20-Сен-19, 22:47 
> Посчитайте число системных вызовов, которое надо выполнить на каждый запрос для реализации
> аналога .htaccess

вычтите те, что нужны для, собственно, отдачи файла на том же уровне - и удивитесь.

Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от KonstantinB (ok), 21-Сен-19, 17:11 
Я ничего про отдачу и не говорил. Считаем сисколлы только на чтение конфигурации.
Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от пох. (?), 21-Сен-19, 23:17 
> Я ничего про отдачу и не говорил. Считаем сисколлы только на чтение конфигурации.

open/read/close, чего там считать-то? Ну может stat еще, вдруг нам его читать неположено.
И то при наличии этого самого файла, а если его там нет - а чаще всего его там нет - один stat(), который еще и кэшировать можно, в принципе.
От пробегания по всему дереву, проверки симлинков (которые не всегда надо читать) и т д - может десятая часть.

Оно на внутреннюю nginx'овую механику не ложится, с его прекомпиляцией и внутренним представлением, вычисляемым один раз, но вот ее-то как раз всю взорвать до основания, и залить слоем бетона в три с половиной метра, чтоб не фонило - никто бы и не плакал. Но нет, мы будем вечно таскать fastcgi_param и fastcgi.conf для совместимости с незнамочем.
(вот те кто понял последнюю фразу - согласятся и с предыдущей. Это ж надо было ТАКОЙ дремучий п-ц породить! Даже systemd, не к ночи, тьфу-тьфу-тьфу, умеет _отменять_ предыдущие multivalue.)

Ответить | Правка | Наверх | Cообщить модератору

81. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от Valentin V. Bartenev (?), 22-Сен-19, 00:53 
А сами сисколы там и есть самое затратное, особенно если речь идет о небольших файлах, лежащих в кэше страниц, что чаще всего. Даже если sendfile() не использовать, то копирование небольших объемов в памяти на современных системах не такая уж тяжелая операция.

Если это не файлопомойка и не медиа-контент, то чаще всего сервер отдает небольшие странички, скрипты и стили. open(), stat(), send(заголовки), sendfile(). При этом всё сразу помещается в сокетный буфер.

По дополнительному stat() на каждую директорию по пути - вполне себе добавят лишних задержек, что скажется на конечных цифрах RPS и прочего. Вряд ли сильно, но вполне измеримо.

Ответить | Правка | Наверх | Cообщить модератору

99. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от пох. (?), 25-Сен-19, 16:22 
> sendfile() не использовать

учитывая поголовное сочетание zfs с https - его как-то уже особо и негде/незачем становится пользовать.

> Если это не файлопомойка и не медиа-контент,

то непонятно, что это вообще нынче такое.

И небольшие-небольшие: bootstrap.min.css - 150килобайт. (gzipped, полагаю ;-) shitfont.otf не отстает - 140
что это мы такое загрузили сейчас? А-а-а, форму из двух полей login/password и кнопкой submit. Не буду нажимать, хочу сохранить некоторые иллюзии.

> По дополнительному stat() на каждую директорию по пути - вполне себе добавят лишних задержек,
> что скажется на конечных цифрах RPS и прочего. Вряд ли сильно, но вполне измеримо.

ну вот и мне кажется - что измеримо, да, но никого особо не огорчит. А фанаты измеризмов и наносекундных замеров - всегда могут отключить, как, собственно, и в апаче это делают.

Но с существующей конфигурацией это просто вот никак не живет. Там что ни тронь - начинает шевелиться на другом конце тарелки.

Ответить | Правка | Наверх | Cообщить модератору

59. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 21-Сен-19, 00:43 
Он мне нужен для безопасности и маршрутизации.
Сомневаюсь что подобное можно реализовать в настройках виртуального хоста.

RewriteEngine On
RewriteBase /
RewriteCond %{THE_REQUEST} \s/index\.php
RewriteRule ^index\.php/?$ /en/error
RedirectMatch 403 .*\/\..*
ErrorDocument 403 /en/error
ErrorDocument 404 /en/error

RewriteRule ^([a-z]{2})/?$ index.php?lang=$1 [END]

RewriteCond %{QUERY_STRING} ^token=([\w-]{20})&PayerID=([\w-]{13})$
RewriteRule ^([a-z]{2})/(payment)/?$ index.php?lang=$1&view=$2&token=%1&PayerID=%2 [END]

RewriteRule ^([a-z]{2})/([\w-']+)/?$ index.php?lang=$1&view=$2 [END]
RewriteRule ^([a-z]{2})/([\w-']+)/([\d-]+)\.html/?$ index.php?lang=$1&view=$2&id=$3 [END]
RewriteRule ^([a-z]{2})/([\w-']+)/([\w-']+)/([\d-]+)\.html/?$ index.php?lang=$1&view=$2&tab=$3&id=$4 [END]

Да и, как минимум, nginx точно .htaccess читает, синтаксис другой, но главное читает.
По поводу системных запросов я их не считал, но снижение производительности за счёт этого всё равно ничтожно мала на фоне всего остального.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

63. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Sw00p aka Jerom (?), 21-Сен-19, 12:21 
я вот одного не пойму, чем ссылка index.php?lang=$1&view=$2&token=%1&PayerID=%2 такого вида не устраивает?
зачем обязательно нужно её представлять в виде ([a-z]{2})/(payment)/ (якобы ЧПУ), зачем? вам нужно эти ссылки индексировать в гуглях?

пс: западло уже в урле иметь ?lang=$1&view=$2&token=%1&PayerID=%2 и не дай Бог \.php, нет лучше пихнуть туда \.html - зачем ??????????

Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 21-Сен-19, 14:03 
1 Тем что она длинная и не понятная пользователю. (Не ЧПУ)
2 А также тем, что она позволяет принять любые GET-параметры от пользователя, а не только те, которые я разрешил.
3 Эта ссылка сразу палит, что сайт написан на PHP.
Мне нужно чтобы боты и пользователи думали что работают с чистым html-сайтом (ЧПУ).

> пс: западло уже в урле иметь ?lang=$1&view=$2&token=%1&PayerID=%2 и не дай Бог \.php,
> нет лучше пихнуть туда \.html - зачем ??????????

Это строчка работы с PayPal через nvp. PayPal не позволяют сформировать ответ в нужном для меня виде и лепит GET-параметры, которые в моём ЧПУ идут лесом, поэтому эта строка делает исключение для PayPal если получена строка нужного вида.

> зачем ??????????

Эстетика + полный контроль над сайтом (обращаться и передавать можно только то, что я позволил, если что-то не дозволенное то отсылается на /en/error).

Ответить | Правка | Наверх | Cообщить модератору

67. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от KonstantinB (ok), 21-Сен-19, 17:07 
Подобные реврайты прекрасно делается через location с регулярками и динамическое построение QUERY_STRING.

Я обычно делаю пары conf.d/my_server.name.conf и conf.d/my_server_name.fcgi.

Скажем, для 3й с конца строки будет примерно так:

location ~ ^([a-z]{2})/([\w-']+)/?$ {
    set $_script_name "/index.php";
    set $_qs "lang=$1&view=$2";
    include /path/to/my_server_name.fcgi;
}

А в my_server_name.fcgi что-то такое:

fastcgi_pass что-там-у-вас;
fastcgi_param  SCRIPT_FILENAME  $document_root$_script_name;
fastcgi_param  QUERY_STRING       $_qs;
(...остальное стандартное из fastcgi_params)

Хотя я бы просто направил все "как есть" на index.php и написал это все на php - это было бы намного проще.

Что касается \s/index\.php и RedirectMatch 403 .*\/\..*, это можно просто убрать, с php-fpm такое не прокатит.

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

71. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 21-Сен-19, 18:16 
Благодарю Вас за ответ! :-)
Не знал что так вообще возможно.

> Хотя я бы просто направил все "как есть" на index.php и написал
> это все на php - это было бы намного проще.

Ну да это гораздо проще будет сделать.

> Что касается \s/index\.php и RedirectMatch 403 .*\/\..*, это можно просто убрать, с
> php-fpm такое не прокатит.

Вы правильно поняли мой замысел?
\s/index\.php этим я запрещаю напрямую обращаться к index.php  сервер делает вид, как-будто файла нет. (403 у меня всё равно вызывает то же что и 404 и отдают 404 Not a found)
А RedirectMatch 403 .*\/\..* я делаю тоже самое для запросов к скрытым файлам и директориям.

Непроканает в смысле нельзя это будет запретить в php-fpm?

Ответить | Правка | Наверх | Cообщить модератору

72. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от KonstantinB (ok), 21-Сен-19, 22:08 
При такой конфигурации - когда SCRIPT_FILENAME указывается в явном виде - достаточно в явном виде перечислить все разрешенные location-ы, а в конце сделать в конце что-то вроде

location ~\.php$ {
    return 404;
}

А еще лучше вообще не класть php-скрипты в document root. Сделать root для статики поддиректорией, а все php-скрипты разместить выше.

Ответить | Правка | Наверх | Cообщить модератору

73. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от KonstantinB (ok), 21-Сен-19, 22:09 
Вообще то, что в nginx все fastcgi-параметры указываются в явном виде, позволяет куда бОльшую гибкость конфигурации, чем apache. Надо только 1 раз разобраться.
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

76. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 21-Сен-19, 22:19 
> Вообще то, что в nginx все fastcgi-параметры указываются в явном виде, позволяет
> куда бОльшую гибкость конфигурации, чем apache. Надо только 1 раз разобраться.

Ёмаё, так это конфигурация nginx...
А я смотрю на это https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html и недуомеваю откуда Вы это взяли, думал это или в php-fpm настаивается или в nginx.

Понятно, значит в Apache всё равно для ЧПУ mod_rewrite нужен, а вот в nginx можно нативными средствами обойтись, которые Вы ранее показали.

Ответить | Правка | Наверх | Cообщить модератору

83. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от KonstantinB (ok), 22-Сен-19, 01:42 
В Apache никто не заставляет эту конфигурацию держать в htaccess. Ее можно спокойно унести в виртуальный хост.

Вообще - все, что можно написать в htaccess, можно написать и в конфигурации вхоста.

Ответить | Правка | Наверх | Cообщить модератору

95. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 22-Сен-19, 10:56 
Благодарю, Вас!
Я и не знал что так можно было думал что mod_rewrite работает только через .htaccess файлы. :-)

В общем сделал максимально просто и совместимо, в <virtualhost><Directory> заменил
AllowOverride All
на
AllowOverride None
IncludeOptional '/path/to/document_root/.htaccess'

.htaccess файлы я всё равно продолжаю использовать, но теперь их загружает 1 раз сам сервер, если я правильно всё понял и сделал. :-)

А также, видимо, по этой же самой причине стоит отключить чтение .user.ini файлов или загружать их также из виртуального хоста или вообще отказаться от них в пользу ручной установки ini_set() ?

Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от KonstantinB (ok), 21-Сен-19, 22:15 
Еще очень полезно отключить включенный по умолчанию fix_pathinfo в php.ini:

cgi.fix_pathinfo=0

fix_pathinfo - это такой костыль для кривых веб-серверов, который подразумевает "битые" PATH* и "угадывает" что имелось ввиду методом перебора вариантов. В случае cgi.fix_pathinfo=0 полным путем к php-скрипту считается содержимое (нестандартного) fastcgi-параметра SCRIPT_FILENAME и ничего кроме.

Оба поведения неидеальны, конечно. Но мой патч для fpm, который удаляет эту настройку и делает два варианта "разумного" поведения (совместимость с де-факто стандартным для PHP SCRIPT_FILENAME и полная совместимость со стандартом CGI) висит без движения уже лет 10. Ну и фиг с ним, SCRIPT_FILENAME ничем, кроме нестандартности, и не плох.

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

77. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 21-Сен-19, 22:23 
> Еще очень полезно отключить включенный по умолчанию fix_pathinfo в php.ini:
> cgi.fix_pathinfo=0

Благодарю за пояснение. Согласен подобные костыли - зло!
https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidf...
В Apache mod_fcgid он отключен по умолчанию.

Ответить | Правка | Наверх | Cообщить модератору

64. "Выпуск сервера приложений NGINX Unit 1.11.0"  +3 +/
Сообщение от Valentin V. Bartenev (?), 21-Сен-19, 13:29 
Добрый день.

А для чего у вас php c Apache через FastCGI работает вместо mod_php? Есть конечно кейсы в которых даже с Apache такой вариант необходим, но FastCGI имеет свои накладные расходы и тут не добавляет эффективности.

Если так сильно нужен .htaccess, то я бы рассмотрел связку nginx + Apache c mod_php. Но так ли необходим .htaccess? Даже просто отказ от него с сохранением Apache даст заметный прирост производительности. Дело в том, что для его работы приходится на каждый запрос сканировать все директории по пути на предмет наличия в них .htaccess файлов, даже если их нет. Это порождает огромное количество дополнительных системных вызовов на каждый запрос и, как следствие, сильно увеличивает накладные расходы. Последующий их парсинг и интерпретация - это пустяки на этом фоне. Да и вообще хранение конфигурации внутри директории, которая раздается в интернет - идея сомнительная.

Но, допустим, что по какой-то причине отказаться от .htaccess вы не можете. Тогда переход на mod_php уменьшил бы накладные расходы на обработку PHP в Apache, а nginx впереди освободил бы его от взаимодействия с медленной сетью и раздачи статики.

Идея тут такая. Поскольку nginx работает с соединениями асинхронно и не блокируясь, то вся обработка происходит в рамках небольшого количества процессов, каждый из которых способен обрабатывать сотни тысяч соединений с минимумом накладных расходов. Дело не сколько в скорости, сколько в масштабируемости при росте нагрузки. Процессы с интерпретатором php дорогие и каждый из них способен обрабатывать только один запрос в момент времени от начала и до конца. Иметь сотни тысяч таких процессов будет очень накладно, как по памяти, так и с точки зрения расходов на переключение контекстов. Поэтому их количество обычно небольшое и задача nginx сделать так, чтобы они работали максимально эффективно, тратя время только на интерпретацию кода, а не сетевые взаимодействия. Поэтому nginx ставят рядом на одну машину. Он работает с медленными соединениями клиентов (а они все медленные по сравнению с локальными процессами) не тратя много ресурсов на обработку. Как только он получил полностью запрос, то максимально быстро передает его в Apache или php-fpm, тот его обрабатывает, и nginx дальше максимально быстро забирает ответ, освобождая процесс c PHP для следующего запроса. Кроме того, все запросы к статике также обрабатываются внутри nginx и не занимая дорогостоящих процессов с php.

У Apache есть event MPM и некоторые заявляют, что это то же самое, что nginx. Но это лукавство, т.к. событийно там обрабатываются только keep-alive соединения в момент простоя. Такие соединения больше не занимают отдельных потоков, но как только начинается обработка запроса, то тут же Apache деградирует до модели с одним потоком на каждый запрос. Да, простаивающие соединения в Apache теперь примерно такие же дешевые, как в nginx, но не более того. Под нагрузкой всё это также схлопывается.

TLS 0-RTT nginx поддерживает, см. директиву конфигурации ssl_early_data (https://nginx.org/r/ssl_early_data/ru).

HTTP/3 запланирован в 1.17.x и точно появится в течение ближайшего года, может быть даже быстрее, полгода.

Если от .htaccess всё же можно отказаться, то замена Apache/mod-php на php-fpm в связке с nginx даст более простой и специализированный инструмент, проще конфигурацию PHP на мой взгляд. Но если в Apache повыключать всё лишнее, особенно .htaccess, то какой-то заметного превосходства по производительности у nginx+php-fpm перед nginx+apache/mod_php не будет. Тут скорее вопрос удобства и простоты.

Наиболее удобным и оптимальным со всех стороны решением мог бы стать Unit. Он делает то, что делает nginx, эффективно работает с соединениями и при этом имеет минимум накладных расходов на обмен данными с процессами интерпретатора. Но, к сожалению, 0-RTT в нем пока ещё нет, как и HTTP/3. И вообще конфигурация TLS в этом месте на данный момент убогая. В результате его пока что также придется использовать за nginx. И часть преимуществ из-за этого теряется. Тем не менее, даже в таком варианте можно начинать пробовать с целью познакомиться, поэкспериментировать и возможно в будущем отказаться от nginx, оставив один лишь Unit. Из плюшек nginx + Unit перед nginx + php-fpm, которые можно получить сразу - это динамическая конфигурация. В частности будет возможность изменять параметры php.ini и управлять процессами без перезагрузки всего Unit-а и потери запросов. Чтобы изменения в конфигурации php-fpm вступили в силу, его нужно полностью перезагрузить, даже если изменения касаются всего лишь одного пула. Это может быть  очень накладно, если пулов много, и создает момент времени, когда php-fpm будет не способен принимать соединения. Кроме того, если вы хотите одновременно использовать несколько версий интерпретатора php, то вам необходимо несколько отдельных php-fpm и раскидывать с помощью nginx между ними запросы. Unit может одновременно работать с несколькими разными версиями php, можно раскидать по ним разные проекты, либо протестировать то же приложение, но с другой версией, а затем без потерь переключить основной поток запросов на новую версию. Вариантов тут много, архитектура Unit-а позволяет любые комбинации и множество паттернов использования, кому как нравится. Кроме того, в новой версии у нас появилась изоляция за счет Linux namespaces и она дальше будет прогрессировать, обрастая новыми возможностями. Можно будет какой-нибудь вордпресс заизолировать, как в контейнере, но без необходимости связываться с Docker-ом. Ничего не имею против последнего, но многие очень приветствуют такую возможность в Unit-е.

Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

69. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 21-Сен-19, 17:16 
Благодарю Вас, Валентин, за подробный и развёрнутый ответ! :-)
Вы меня серьёзно озадачили и заставили пересмотреть некоторые мои знания, впрочем этого я и хотел. :-)

> А для чего у вас php c Apache через FastCGI работает вместо mod_php? Есть конечно кейсы в которых даже с Apache такой вариант необходим, но FastCGI имеет свои накладные расходы и тут не добавляет эффективности.

Мне казалось что mod_php это удел конфигураций всяких денверов на локалхостах, которые не могут осилить нормальную конфигурацию сервера.

В mod_php:
- можно использовать только prefork, нельзя использовать event, что мне тогда казалось снижает производительность.
- интерпритатор задействован даже когда отдаётся статика.
- на каждый запрос создаётся свой процесс что приводит к повышенному расходу ОЗУ
- Ошибка в одном PHP-скрипте может положить Apache со всеми виртуальными хостами
- нельзя использовать разные версии PHP для разных виртуальных хостов.
- не читаются .user.ini файлы https://www.php.net/manual/ru/configuration.file.per-user.php

В FastCGI этого всего нет, мне тогда он казался однозначно лучше, хотя сейчас погуглив эту тему, пишут что при высокой нагрузке mod_php показывает большую производительность.
Почему большую, мне не понято. Читая Ваш ответ про MPM event, он должен быть. как минимум, не хуже.

> Но так ли необходим .htaccess?
> Даже просто отказ от него с сохранением Apache даст заметный прирост производительности.

Вот это для меня было новостью.
Я и не предполагал что mod_rewrite так сильно влияет на производительность Apache.
Я его использую для маршрутизации, тут https://www.opennet.dev/openforum/vsluhforumID3/118512.html#59 привёл пример его использования.

Пол дня думал над тем, могу ли я от него отказаться.
Если кратко, то в DOCUMENT_ROOT у меня есть только 2 объекта к которым можно обращаться
это директория static и файл index.php
Если я откажусь от .htaccess мне нужно чтобы на стороне сервера я мог прописать нечто такое.
- Если URI начинается на /static/ (/static/img/favicon.png) то сервер отдавал статику, даже не пытаясь задействовать php (короче чтобы он не вмешивался и делала что и обычно).
- Но если запрос НЕ содержит /static/ (/ru/user/1.html) то мне нужно чтобы сервер НЕ изменяя URL (пользователь должен всегда оставаться на том URL с которого он пришёл, если я сам в PHP/JS  не решу иначе) вместо попытки обращения к директориям ru и user и поиска там файла 1.html сразу перенаправил запрос на index.php?get=/ru/user/1.html а на стороне PHP я уже сам смогу определить что делать дальше с этим URI из $_GET['get']

Такое можно прописать на Apache или nginx или nginx unit?
Ну или какие-нибудь иные соображения как можно эффективно организовать ЧПУ маршрутизацию без mod_rewrite?

Ответить | Правка | Наверх | Cообщить модератору

75. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от KonstantinB (ok), 21-Сен-19, 22:19 
mod_php нормально работает только с prefork MPM. С event вообще не работает. С worker очень рискованно: php в принципе можно собрать с thread safety, но эта safety касается только Zend VM: все php-расширения - это врапперы вокруг библиотек, в которых с thread safety все не очень хорошо.
Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 21-Сен-19, 22:29 
> mod_php нормально работает только с prefork MPM. С event вообще не работает.
> С worker очень рискованно: php в принципе можно собрать с thread
> safety, но эта safety касается только Zend VM: все php-расширения -
> это врапперы вокруг библиотек, в которых с thread safety все не
> очень хорошо.

Это я зная, просто не понимаю почему пишут что на высоких нагрузках mod_php с prefork работает производительнее чем mod_fcgid + php-fastcgi с event?

Ответить | Правка | Наверх | Cообщить модератору

82. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от KonstantinB (ok), 22-Сен-19, 01:41 
Я бы не сказал, что производительнее. Примерно одинаково.
Ответить | Правка | Наверх | Cообщить модератору

80. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от Valentin V. Bartenev (?), 22-Сен-19, 00:23 
> В mod_php:
> - можно использовать только prefork, нельзя использовать event, что мне тогда казалось снижает производительность.
> - интерпритатор задействован даже когда отдаётся статика.

Я вообще не знаток Apache, но полагаю это всё же некое преувеличение. Вряд ли там задействуется интерпретатор PHP (для чего?) в отдаче статики. Скорее речь идет о том, что он просто всегда загружен в память процесса, даже когда тот просто статику отдает, но при этом не задействуется.

> - на каждый запрос создаётся свой процесс что приводит к повышенному расходу ОЗУ
> - Ошибка в одном PHP-скрипте может положить Apache со всеми виртуальными хостами

Тут опять же логика подсказывает, что в режиме prefork должен падать только тот процесс, что обрабатывает конкретный запрос, приводящий к ошибке, а остальные при этом продолжат обрабатываться.

> В FastCGI этого всего нет, мне тогда он казался однозначно лучше, хотя сейчас погуглив эту тему, пишут что при высокой нагрузке mod_php показывает большую производительность.
> Почему большую, мне не понято. Читая Ваш ответ про MPM event, он должен быть. как минимум, не хуже.

Если говорить именно о динамическом контенте, то добавляя в обработку FastCGI - просто добавляются ещё накладные расходы на передачу данных по этому протоколу.

Что происходит в этом случае:

Один из рабочих потоков Apache вычитывает из сокета соединения запрос, затем парсит его, обрабатывает согласно конфигурации, затем преобразовывает в формат сообщений по протоколу FastCGI и далее записывает запрос в сокет, где на другом конце этого сокета уже запрос в формате FastCGI опять читается из сокета, парсится и передается интерпретатору PHP. Тот формирует ответ и далее всю по цепочке происходит в обратной последовательности с преобразованиями форматов, дополнительными записью и чтением из сокета.

Когда у вас mod_php в prefork работает, то рабочий процесс читает запрос из сокета, парсит его, обрабатывает согласно конфигурации и передает его интерпретатору PHP. Накладных расходов на FastCGI в виде системных вызовов, копирования данных и преобразования форматов тут нет.

Фактически ваша конструкция event MPM и PHP по FastCGI похожа на nginx + php-fpm, с той лишь разницей, что nginx будет эффективнее.


>> Но так ли необходим .htaccess?
>> Даже просто отказ от него с сохранением Apache даст заметный прирост производительности.
>
> Вот это для меня было новостью.
> Я и не предполагал что mod_rewrite так сильно влияет на производительность Apache.
> Я его использую для маршрутизации, тут https://www.opennet.dev/openforum/vsluhforumID3/118512.html#59 привёл пример его использования.

mod_rewrite и .htaccess - сущности ортогональные. Он тут ни при чем. На производительность влияет включение .htaccess файлов, даже если их не будет в каталогах или они будут пустыми. Правила mod_rewrite можно писать и в основной конфигурационный файл Apache, благополучно отключив при этом .htaccess. На производительность mod_rewrite не сильно должен влиять.


> Если кратко, то в DOCUMENT_ROOT у меня есть только 2 объекта к которым можно обращаться
> это директория static и файл index.php
> Если я откажусь от .htaccess мне нужно чтобы на стороне сервера я мог прописать нечто такое.
> - Если URI начинается на /static/ (/static/img/favicon.png) то сервер отдавал статику, даже не пытаясь задействовать php (короче чтобы он не вмешивался и делала что и обычно).
> - Но если запрос НЕ содержит /static/ (/ru/user/1.html) то мне нужно чтобы сервер НЕ изменяя URL (пользователь должен всегда оставаться на том URL с которого он пришёл, если я сам в PHP/JS  не решу иначе) вместо попытки обращения к директориям ru и user и поиска там файла 1.html сразу перенаправил запрос на index.php?get=/ru/user/1.html а на стороне PHP я уже сам смогу определить что делать дальше с этим URI из $_GET['get']
>
> Такое можно прописать на Apache или nginx или nginx unit?
> Ну или какие-нибудь иные соображения как можно эффективно организовать ЧПУ маршрутизацию без mod_rewrite?

Можно те же правила mod_rewrite прописать в основном конфиге Apache.

В целом, это достаточно тривиальная конфигурация. В nginx можно делать разными способами. Достаточно настроить пару location'ов (https://nginx.org/r/location/ru) - один для статики, а другой для FastCGI проксирования. А далее, или воспользоваться правилами его собственного модуля rewrite (https://nginx.org/r/rewrite/ru), или, что проще и "прямее", грамотно прописать соответствующие FastCGI переменные. В nginx они просто задаются с помощью директив fastcgi_param (https://nginx.org/r/fastcgi_param/ru), в которых можно указывать комбинации строк и переменных запроса (https://nginx.org/ru/docs/varindex.html). По умолчанию к nginx обычно прилагается файл конфигурации со стандартными значениями: https://hg.nginx.org/nginx/file/tip/conf/fastcgi.conf

В Unit сейчас можно гибко фильтровать запросы и раскидывать их по приложениям или директориям со статикой. Делается это правилами внутреннего роутинга, которые достаточно просты для восприятия: https://unit.nginx.org/configuration/#routes
Что касается rewrite-подобной функциональности, то её пока как таковой нет, но у модуля PHP есть два режима работы:

1. Задана опция "script", содержащая путь к .php скрипту. В этом случае все запросы в приложение будут обрабатываться с помощью данного скрипта. URI запроса будет содержаться в переменной $_SERVER['REQUEST_URI'], просто запущен будет указанный вами в конфигурации скрипт, а не то что пришло в запросе.

2. Опция не "script" не задана. Тогда запускается тот скрипт, на который указывает URI запроса. Также если URI содержит так называемый компонент PATH_INFO (например /index.php/some/path), то Unit отрежет путь после .php (в данном случае "/some/path") и поместит его в $_SERVER['PATH_INFO'].

Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

96. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 22-Сен-19, 11:16 
> mod_rewrite и .htaccess - сущности ортогональные...
> Можно те же правила mod_rewrite прописать в основном конфиге Apache.

Ё-маё... и снова Вы меня удивили. :-)
Я думал что mod_rewrite работает только через .htaccess файлы. :-)

В общем сделал максимально просто и совместимо, в <virtualhost><Directory> заменил
AllowOverride All
на
AllowOverride None
IncludeOptional '/path/to/document_root/.htaccess'

.htaccess файлы я всё равно продолжаю использовать, но теперь их загружает 1 раз сам сервер, если я правильно всё понял и сделал. :-)

Благодарю Вас снова за подробный и детальный ответ! :-)

На данный момент, всё же решил в скором времени мигрировать на nginx + php-fpm, по крайней мере пока Unit не научиться полноценно обходится без nginx, и его статическая реализация будет не хуже.

И вот ещё озадачивает один момент, почему статическую реализацию в unit просто нельзя перенести, как есть, из nginx?
Это обусловлено какими-то конструктивными особенностями unit-а что её в принципе не возможно в нём также хорошо реализовать?
Иными словами можно будет ожидать в будущем от статической составляющей unit что она будет не хуже чем в nginx или nginx всегда будет лучше обрабатывать статику?

Ответить | Правка | Наверх | Cообщить модератору

100. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от Valentin V. Bartenev (?), 26-Сен-19, 14:03 
> И вот ещё озадачивает один момент, почему статическую реализацию в unit просто нельзя перенести, как есть, из nginx?

Потому, что API и внутренние механизмы Unit-а достаточно существенно отличаются от nginx.  Многое сделано иначе: другая работа с буферами, конфигурацией, по-другому выстроена обработка соединений, активно используются очереди, вместо накручивания стека.

Не забывайте, что архитектура nginx закладывалась Игорем Сысоевым 16 лет назад с теми знаниями, тем опытом и теми возможностями, которые у него были на тот момент. С тех пор поменялось всё: интернет, протоколы, ядра операционных систем, железо, требования к серверам, ожидания пользователей и т.д. Unit от nginx взял только отдельные очень удачные и проверенные временем концепции, но многое было переработано, весь код был написан практически с нуля. Особенно подверглись переработке те механизмы, которые по опыту в итоге принесли в nginx огромное количество боли и мешают более эффективной реализации тех или иных возможностей. И таких больных мест не мало, учитывая, как всё изменилось с тех пор. Плюс сам Игорь и команда за долгие годы работы над nginx стали гораздо опытнее и поменяли свое мнение относительно некоторых решений.

> Это обусловлено какими-то конструктивными особенностями unit-а что её в принципе не возможно в нём также хорошо реализовать?

Напротив, благодаря новой архитектуре, в нем возможно реализовать отдачу статики ещё более эффективно, чем это сделано в nginx.

> Иными словами можно будет ожидать в будущем от статической составляющей unit что она будет не хуже чем в nginx или nginx всегда будет лучше обрабатывать статику?

Можно ожидать что она будет лучше, чем что-либо существующее.

Ответить | Правка | Наверх | Cообщить модератору

101. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 26-Сен-19, 14:20 
Благодарю Вас! :-)

Ответить | Правка | Наверх | Cообщить модератору

102. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 16-Окт-19, 13:18 
Добрый день, Валентин и все кто сейчас читает эту ветку!
Я наконец-то сегодня перевёл с Apache на nginx свои сервера, но мне снова понадобится Ваша помощь, так как некоторые моменты мне не ясны, а некоторые и вовсе не получаются.

0 При попытке регистрации на форуме https://forum.nginx.org мне постоянно пишут
Your registration request has been blocked because its suspected to come from a forum spammer!
Хотя я ни разу его до этого вообще не посещал его, так что продолжу общение здесь, в этой тёплой и ламповой, для меня, обстановке. :-)

1 С Вашего наставления я отказался от .htaccess и перевёл ЧПУ на Location-ы, но я не уверен оптимально ли я это сделал.
В apache у меня было коротко и ясно.


RewriteEngine On
RewriteBase /
RewriteCond %{THE_REQUEST} \s/index\.php
RewriteRule ^index\.php/?$ /en/error
RedirectMatch 403 .*\/\..*
ErrorDocument 403 /en/error
ErrorDocument 404 /en/error

RewriteRule ^([a-z]{2})/?$ index.php?lang=$1 [END]

#https://gricargo.com/ru/payment?token=EC-9HP89464U39537617&P...
RewriteCond %{QUERY_STRING} ^token=([\w-]{20})&PayerID=([\w-]{13})$
RewriteRule ^([a-z]{2})/(payment)/?$ index.php?lang=$1&view=$2&token=%1&PayerID=%2 [END]

RewriteRule ^([a-z]{2})/([\w-]+)/?$ index.php?lang=$1&view=$2 [END]
RewriteRule ^([a-z]{2})/([\w-]+)/([\d-]+)\.html/?$ index.php?lang=$1&view=$2&id=$3 [END]
RewriteRule ^([a-z]{2})/([\w-]+)/([\w-]+)/([\d-]+)\.html/?$ index.php?lang=$1&view=$2&tab=$3&id=$4 [END]
RewriteRule ^([a-z]{2})/([\w-]+)/([\w-]+)/?$ index.php?lang=$1&view=$2&tab=$3 [END]
RewriteRule ^([a-z]{2})/(api)/([\w\s-]+)={1,3}([\w\s-]+)={1,3}\.html/?$ index.php?lang=$1&view=$2&data=$3&iv=$4 [END]

Но в nginx это развернулось вот в такую простыню.


error_page 404 /en/error;
error_page 500 502 503 504 /50x.html;

location = /50x.html
{
    root /srv/www/htdocs;
}
location = /favicon.ico
{
    log_not_found off;
    access_log off;
}
location = /
{
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location = /index.php
{
    return 404;
}
location ~ /\.
{
    return 404;
}
location /
{
    try_files $uri return 404;
}
location ~ ^/([a-z][a-z])/?$
{
    set $_query_string "lang=$1";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
#/ru/payment?token=EC-9HP89464U39537617&PayerID=T94MQ4XMUXCWG
location ~ ^/([a-z][a-z])/(payment)$
{
    set $_query_string "lang=$1&view=$2";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string&$query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location ~ ^/([a-z][a-z])/([\w-]+)/?$
{
    set $_query_string "lang=$1&view=$2";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location ~ ^/([a-z][a-z])/([\w-]+)/([\d-]+)\.html/?$
{
    set $_query_string "lang=$1&view=$2&id=$3";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location ~ ^/([a-z][a-z])/([\w-]+)/([\w-]+)/([\d-]+)\.html/?$
{
    set $_query_string "lang=$1&view=$2&tab=$3&id=$4";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location ~ ^/([a-z][a-z])/([\w-]+)/([\w-]+)/?$
{
    set $_query_string "lang=$1&view=$2&tab=$3";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
location ~ ^/([a-z][a-z])/(api)/([\w\s-]+)=\{1,3\}([\w\s-]+)=\{1,3\}\.html/?$
{
    set $_query_string "lang=$1&view=$2&data=$3&iv=$4";
    fastcgi_pass unix:/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param QUERY_STRING $_query_string;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}

Всё работает, как и ожидается, но каждое правило вместо 1-ой строчки, превратилось в блок, в котором почти в каждом повторяется 1 и тот же блок


fastcgi_pass unix:/run/php-fpm.sock;
include fastcgi_params;
fastcgi_param QUERY_STRING $_query_string
fastcgi_param SCRIPT_FILENAME $document_root/index.php;

Можно ли это как-то оптимизировать?
Например, выноести этот блок, а потом вызывать это блок (читал про именованные location но не понял как их использовать и помогут ли они мне тут вообще.)

2 При написании правил, я использовал только Location-ы игнорировал if-ы и rewrite-ы, возможно что-то ещё, так как прочитал, что Location-ы работают лучше и быстрее.
Правильно ли я сделал и почему (почему Location производительнее чем rewrite если это так, и почему именно не стоит использовать if-ы если это так)?

2.1 Отдельно прошу обратить внимание на правило с payment, где в apache можно было задействовать для разбора не только URI, но и QUERY_STRING. В nginx, если я правильно понял, можно использовать только URI.
Конкретную задачу по маршрутизации я вроде решил конкатенацией нового и старого QUERY_STRING, но хотелось бы знать можно ли было это сделать иначе?

3 Стоит ли мне включить опцию в nginx pcre_jit on;?
Сделает ли она обработку моих Location-ов более производительной?

4 Socket vs Port на локалхосте.
Правильно ли я поступаю, что использую сокеты на локалхосте вместо портов с точки зрения производительности? Какие там нюансы?

5 Не получается указать ssl_ciphers и их порядок следования для TLS 1.3.
В апаче есть костыль, и можно указать так, и это работает:

SSLCipherSuite TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384

В nginx, как и везде.

ssl_ciphers TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384;

Это работает только для TLSv1.2 сиферов, а сиферы для TLSv1.3 выводятся те и только в таком порядке, в котором они зашиты в openssl ciphers.
Можно ли что-то с этим сделать?

6 Не получается включить 0-RTT (SSL Labs показывает 0-RTT enabled No)
https://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_...
Тут нет конкретного примера.
Я в http указал
ssl_early_data on;
и даже
proxy_set_header Early-Data $ssl_early_data;
Но оно не работает и, видимо, последняя строчка должна быть другой, ведь у меня nginx никого не проксирует, он сам единственный web-сервер.

7 Каким и можно ли вообще изменять параметр максимального времени жизни запроса для каждого виртуального хоста?
В apache это делалось так: FcgidIOTimeout 300

8 И вопрос по php-fpm, по каким правилам, критериям или стратегиям выбирается оптимальное число процессов в этих, возможно и других опциях для pm = dynamic.

pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

P.S. Буду рад выслушаю конструктивные ответы от всех кто их может дать. :-)

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

103. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от Valentin V. Bartenev (?), 20-Окт-19, 13:55 
> 0 При попытке регистрации на форуме https://forum.nginx.org мне постоянно пишут
> Your registration request has been blocked because its suspected to come from
> a forum spammer!
> Хотя я ни разу его до этого вообще не посещал его, так
> что продолжу общение здесь, в этой тёплой и ламповой, для меня,
> обстановке. :-)

А и не надо на нем регистрироваться. Этот форум - всего лишь веб-интерфейс (причем страшно кривой) к обычному списку рассылки, который когда-то давно приделал один из пользователей.  С тех пор он так и живет.  Мы на него убрали вроде ссылки, но каким-то образом пользователи всё равно его находят.

Есть списки рассылки, ими и нужно пользоваться: https://mailman.nginx.org/mailman/listinfo/nginx-ru


> try_files $uri return 404;

Тут что-то странное написано.

В таком виде директива try_files проверит сначала существование запрашиваемого файла, а затем, если его нет, проверит существование файла с названием "return" и если такого файла тоже нет, то сделает редирект на страницу с именем 404.

Вы наверное пытались написать:

try_files $uri =404; 

Но в такой конструкции нет никакого смысла. Нужно просто оставить location пустым:

location / { }


> Всё работает, как и ожидается, но каждое правило вместо 1-ой строчки, превратилось
> в блок, в котором почти в каждом повторяется 1 и тот
> же блок
>
> fastcgi_pass unix:/run/php-fpm.sock;
> include fastcgi_params;
> fastcgi_param QUERY_STRING $_query_string
> fastcgi_param SCRIPT_FILENAME $document_root/index.php;
>

А и не надо так писать.  То же самое:

rewrite ^/([a-z][a-z])/?$ /?lang=$1? last;
rewrite ^/([a-z][a-z])/(payment)$ /?lang=$1&view=$2 last;
rewrite ^/([a-z][a-z])/([\w-]+)/?$ /?lang=$1&view=$2? last;
rewrite ^/([a-z][a-z])/([\w-]+)/([\d-]+)\.html/?$ /?lang=$1&view=$2&id=$3? last;
rewrite ^/([a-z][a-z])/([\w-]+)/([\w-]+)/([\d-]+)\.html/?$ /?lang=$1&view=$2&tab=$3&id=$4? last;
rewrite ^/([a-z][a-z])/([\w-]+)/([\w-]+)/?$ /?lang=$1&view=$2&tab=$3? last;
rewrite ^/([a-z][a-z])/(api)/([\w\s-]+)=\{1,3\}([\w\s-]+)=\{1,3\}\.html/?$ /?lang=$1&view=$2&data=$3&iv=$4? last;


> Можно ли это как-то оптимизировать?
> Например, выноести этот блок, а потом вызывать это блок (читал про именованные
> location но не понял как их использовать и помогут ли они
> мне тут вообще.)

Не помогут.  Именованные location нужны для перенаправлений без изменения URI. У вас URI требуется менять.


> 2 При написании правил, я использовал только Location-ы игнорировал if-ы и rewrite-ы,
> возможно что-то ещё, так как прочитал, что Location-ы работают лучше и
> быстрее.
> Правильно ли я сделал и почему (почему Location производительнее чем rewrite если
> это так, и почему именно не стоит использовать if-ы если это
> так)?

location-ы производительнее потому, что префиксное сопоставление позволяет построить дерево и по нему искать. Но это не касается location с регулярными выражениями. Никаких преимуществ перед аналогичными конструкциями с регулярными выражениями у location нет. Во всех случаях основной тормоз - это исполнение регулярного выражения.

Все проблемы, увы, PHP программисты создают себе сами. Хотите чтобы было просто и быстро - разбирайте URI в index.php. Будете вы разбирать URI в PHP с помощью той же регулярки или с помощью каких-то более эффективных функций - не так важно.

Сейчас же вы занимаетесь лишней работой. Сначала заставили веб-сервер с помощью регулярных выражений парсить URI и преобразовывать его в аргументы. А затем этот URI с аргументами отправляете PHP-интерпретатору, чтобы тот опять парсил ваш URI, но уже с аргументами, вычленял эти аргументы и запихивал в хэш.  Зачем такое усложнение? Зачем этот лишний этап преобразования URI из одной формы в другую? Почему нельзя его парсить сразу в index.php?


> 2.1 Отдельно прошу обратить внимание на правило с payment, где в apache
> можно было задействовать для разбора не только URI, но и QUERY_STRING.
> В nginx, если я правильно понял, можно использовать только URI.
> Конкретную задачу по маршрутизации я вроде решил конкатенацией нового и старого QUERY_STRING,
> но хотелось бы знать можно ли было это сделать иначе?

Можно проверять аргументы с помощью if.


> 3 Стоит ли мне включить опцию в nginx pcre_jit on;?
> Сделает ли она обработку моих Location-ов более производительной?

Возможно чуть ускорит.


> 4 Socket vs Port на локалхосте.
> Правильно ли я поступаю, что использую сокеты на локалхосте вместо портов с
> точки зрения производительности? Какие там нюансы?

Правильно. Особых нюансов нет.


> ssl_ciphers TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384;
>
> Это работает только для TLSv1.2 сиферов, а сиферы для TLSv1.3 выводятся те
> и только в таком порядке, в котором они зашиты в openssl
> ciphers.
> Можно ли что-то с этим сделать?

Сейчас алгоритмы для TLS 1.3 в nginx можно задать через openssl.conf, подробности в: https://trac.nginx.org/nginx/ticket/1529#comment:12


> 6 Не получается включить 0-RTT (SSL Labs показывает 0-RTT enabled No)
> https://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_...
> Тут нет конкретного примера.
> Я в http указал
> ssl_early_data on;

Ещё сам TLS 1.3 нужно включить с помощью ssl_protocols, а больше ничего и не нужно.  Но следует убедиться, что, во-первых, в системе стоит свежая версия OpenSSL 1.1.1+, а, во-вторых, сам nginx был именно с ней собран.


> 7 Каким и можно ли вообще изменять параметр максимального времени жизни запроса
> для каждого виртуального хоста?
> В apache это делалось так: FcgidIOTimeout 300

fastcgi_read_timeout


> 8 И вопрос по php-fpm, по каким правилам, критериям или стратегиям выбирается
> оптимальное число процессов в этих, возможно и других опциях для pm
> = dynamic.
> pm.max_children = 5
> pm.start_servers = 2
> pm.min_spare_servers = 1
> pm.max_spare_servers = 3

Параметры подбираются исходя из возможностей вашей системы, сколько в ней памяти и процессора доступно, и исходя из особенностей вашего приложения, сколько каждый процесс ест памяти, сколько ждет на I/O, а сколько работает. Пять процессов - это либо какой-нибудь Raspberry Pi, виртуалка, либо приложение на десяток активных пользователей. На нормальном сервере под средние нагрузки будет что-нибудь вроде:

pm.max_children = 300
pm.start_servers = 50
pm.min_spare_servers = 25
pm.max_spare_servers = 75

Ответить | Правка | Наверх | Cообщить модератору

104. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 20-Окт-19, 16:58 
> Есть списки рассылки, ими и нужно пользоваться: https://mailman.nginx.org/mailman/listinfo/nginx-ru

Вот не люблю я их, не удобные они, они не дают развёрнутого диалога как в багзиле или форуме. Тем более многие почтовики на которых они построены даже STARTTLS осилить не могут, и я в принципе ими не могу пользоваться.

>> try_files $uri return 404;
> Тут что-то странное написано.

Согласен, уже самому страшно, я за наделю разобрался как это работает и переписал на


location /
{
    index index.html;
    try_files $uri $uri/ =404;
}

Обязательно в самом конце, и убрал его из всех других блоков!
> Но в такой конструкции нет никакого смысла. Нужно просто оставить location пустым:
>
location / { } 
>

А вот до этого нужно было ещё догадаться...
Для меня не было очевидным что пустой location / и его отсутствие это не одно и тоже.

И с Вами я не соглашусь про пустой location.
При пустом location в лог ошибок заносятся все 404 Not a found, что для меня было нежданностью и удивлением, и чтобы этого не было то вся статика должна обрабатываться на сайте именно так, как я привёл ранее в location /.
Также этот location реализует стандартное поведение Apache к которому я привык. (В лог ошибок не попадпют 404 и обращение к директориям подставляется index.html)

Поправьте меня если я что-то понял не так и не допонял. (Собственно, сегодня ночью я занимался именно этим.)
>[оверквотинг удален]
>

rewrite ^/([a-z][a-z])/?$ /?lang=$1? last; 
> rewrite ^/([a-z][a-z])/(payment)$ /?lang=$1&view=$2 last;
> rewrite ^/([a-z][a-z])/([\w-]+)/?$ /?lang=$1&view=$2? last;
> rewrite ^/([a-z][a-z])/([\w-]+)/([\d-]+)\.html/?$ /?lang=$1&view=$2&id=$3? last;
> rewrite ^/([a-z][a-z])/([\w-]+)/([\w-]+)/([\d-]+)\.html/?$ /?lang=$1&view=$2&tab=$3&id=$4?
> last;
> rewrite ^/([a-z][a-z])/([\w-]+)/([\w-]+)/?$ /?lang=$1&view=$2&tab=$3? last;
> rewrite ^/([a-z][a-z])/(api)/([\w\s-]+)=\{1,3\}([\w\s-]+)=\{1,3\}\.html/?$ /?lang=$1&view=$2&data=$3&iv=$4?
> last;
>

Иными словами, там где мне нужна регулярка (~), я могу заменить на rewrite, а там где нет регулярки (= или /) я могу оставить location и производительность будет такая же?

> Все проблемы, увы, PHP программисты создают себе сами. Хотите чтобы было просто
> и быстро - разбирайте URI в index.php. Будете вы разбирать URI
> в PHP с помощью той же регулярки или с помощью каких-то
> более эффективных функций - не так важно.
> Сейчас же вы занимаетесь лишней работой. Сначала заставили веб-сервер с помощью регулярных
> выражений парсить URI и преобразовывать его в аргументы. А затем этот
> URI с аргументами отправляете PHP-интерпретатору, чтобы тот опять парсил ваш URI,
> но уже с аргументами, вычленял эти аргументы и запихивал в хэш.
>  Зачем такое усложнение? Зачем этот лишний этап преобразования URI из
> одной формы в другую? Почему нельзя его парсить сразу в index.php?

Тут Я Вас не совсем понял. :-(

> разбирайте URI в index.php

От клиента приходит URI /ru/company/cargo/1.html Как мне его разбивать в /index.php если он полезет искать директории ru company cargo в ней файл 1.html, которых на сервере, естественно, нет и быть не может, а про наличие /index.php PHP и знаить не знает, если ему сервер не распарсит URI на GET-параметы и не вызовет /index.php с GET-параметрами? Как?

> Сейчас же вы занимаетесь лишней работой.

Или Вы под лишнюю работу считаете всё ЧПУ?

> А затем этот URI с аргументами отправляете PHP-интерпретатору, чтобы тот опять парсил ваш URI.

PHP URI не парсит. Он, разве что разбивает QUERY_STRING на GET-параметры, что очень лёгкая и быстрая задача, $_GET = explode('&',$_SERVER['QUERY_STRING']); причём деелает он это сам и всегда.
Я его ничем лишним не нагружаю, он даже не понимает что я использую ЧПУ. В этом весь и смысл.

>> 3 Стоит ли мне включить опцию в nginx pcre_jit on;?
>> Сделает ли она обработку моих Location-ов более производительной?
> Возможно чуть ускорит.

Ускорит только (пере)запуск nginx или также дальнейшую работу rewrite-ов.

>> 4 Socket vs Port на локалхосте.
>> Правильно ли я поступаю, что использую сокеты на локалхосте вместо портов с
>> точки зрения производительности? Какие там нюансы?
> Правильно. Особых нюансов нет.

Но почему-то почти у всех серверов в конфигурации по умолчанию, и в документации записаны именно порты, и мне приходится каждый раз тратить время чтобы найти как указывается socket в этом сервере... Думал, может я чего-то не понимаю.

>> ssl_ciphers TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384;
>>
>> Это работает только для TLSv1.2 сиферов, а сиферы для TLSv1.3 выводятся те
>> и только в таком порядке, в котором они зашиты в openssl
>> ciphers.
>> Можно ли что-то с этим сделать?
> Сейчас алгоритмы для TLS 1.3 в nginx можно задать через openssl.conf, подробности
> в: https://trac.nginx.org/nginx/ticket/1529#comment:12

Благодарю. Про это необходимо написать в документации к параметру ciphers.

>> 6 Не получается включить 0-RTT (SSL Labs показывает 0-RTT enabled No)
>> https://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_...
>> Тут нет конкретного примера.
>> Я в http указал
>> ssl_early_data on;
> Ещё сам TLS 1.3 нужно включить с помощью ssl_protocols, а больше ничего
> и не нужно.  Но следует убедиться, что, во-первых, в системе
> стоит свежая версия OpenSSL 1.1.1+, а, во-вторых, сам nginx был именно
> с ней собран.

https://build.opensuse.org/package/view_file/server:http/ngi...


nginx -V
nginx version: nginx/1.17.3
built by gcc 9.2.1 20190903 [gcc-9-branch revision 275330] (SUSE Linux)
built with OpenSSL 1.1.1c  28 May 2019
TLS SNI support enabled

/etc/nginx/nginx.conf


error_log /var/log/nginx/error.log warn;
pid /run/nginx.pid;

events
{
    multi_accept on;
    worker_connections 1024;
}

http
{
    include mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for"';
    access_log /var/log/nginx/access.log main;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains; preload' always;
    ssl_protocols TLSv1.3 TLSv1.2;
    ssl_ciphers TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers on;
    ssl_ecdh_curve prime256v1;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s ipv6=off;
    ssl_early_data on;
    proxy_set_header Early-Data $ssl_early_data;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    keepalive_timeout 70;

    gzip on;

    include conf.d/*.conf;

    server
    {
        listen 443 default_server http2 ssl;
        ssl_certificate /etc/apache2/ssl.crt/gricargo.com.crt;
        ssl_certificate_key /etc/apache2/ssl.key/gricargo.com.key;
        return 301 https://gricargo.com;
    }

    include vhosts.d/*.conf;
}


https://www.ssllabs.com/ssltest/analyze.html?d=gricargo.com
0-RTT enabled     No :-(

>[оверквотинг удален]
> Параметры подбираются исходя из возможностей вашей системы, сколько в ней памяти и
> процессора доступно, и исходя из особенностей вашего приложения, сколько каждый процесс
> ест памяти, сколько ждет на I/O, а сколько работает. Пять процессов
> - это либо какой-нибудь Raspberry Pi, виртуалка, либо приложение на десяток
> активных пользователей. На нормальном сервере под средние нагрузки будет что-нибудь вроде:
>

pm.max_children = 300 
> pm.start_servers = 50
> pm.min_spare_servers = 25
> pm.max_spare_servers = 75
>

Хотелось бы если не формул, то инструкций по тому как узнать что процессов не хватает или их в избытке. Понимаю что эта тема не Ваша, буду разбираться с этим дальше.

Благодарю Вас, за ответ, мне он, как всегда очень помог. :-)

Ответить | Правка | Наверх | Cообщить модератору

105. "Выпуск сервера приложений NGINX Unit 1.11.0"  +2 +/
Сообщение от Valentin V. Bartenev (?), 20-Окт-19, 22:48 
>> Есть списки рассылки, ими и нужно пользоваться: https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Вот не люблю я их, не удобные они, они не дают развёрнутого
> диалога как в багзиле или форуме. Тем более многие почтовики на
> которых они построены даже STARTTLS осилить не могут, и я в
> принципе ими не могу пользоваться.

Почтовики? STARTTLS? Вы случайно с NNTP/Usenet не попутали? В списках рассылки можно хоть из веб-интерефейса Gmail с двухфакторной авторизацией общаться.


> И с Вами я не соглашусь про пустой location.
> При пустом location в лог ошибок заносятся все 404 Not a found,
> что для меня было нежданностью и удивлением, и чтобы этого не
> было то вся статика должна обрабатываться на сайте именно так, как
> я привёл ранее в location /.
> Также этот location реализует стандартное поведение Apache к которому я привык. (В
> лог ошибок не попадпют 404 и обращение к директориям подставляется index.html)

index.html и так подставляется при запросе директории.  А вот эмулировать поведение log_not_found off; с помощью try_files - это странно.


> Иными словами, там где мне нужна регулярка (~), я могу заменить на
> rewrite, а там где нет регулярки (= или /) я могу
> оставить location и производительность будет такая же?

Да.


> От клиента приходит URI /ru/company/cargo/1.html Как мне его разбивать в /index.php если
> он полезет искать директории ru company cargo в ней файл 1.html,
> которых на сервере, естественно, нет и быть не может, а про
> наличие /index.php PHP и знаить не знает, если ему сервер не
> распарсит URI на GET-параметы и не вызовет /index.php с GET-параметрами? Как?

Обычно вся конфигурация сводится к следующим двум location-ам:


location / {
    try_files $uri @php;
}

location @php {
    fastcgi_pass unix:/run/php-fpm.sock;
    fastcgi_param SCRIPT_FILENAME path/to/app.php;
    include fastcgi_params;
}

Всё предельно просто: если файл есть на диске - мы его отдаем, а всё остальное отправляем в приложение. Приложение уже возьмет $_SERVER['REQUEST_URI'] и распарсит как угодно.
Программисты на других ЯП всю дорогу так и делали и только PHP-шники извращаются.

А ещё правильнее - это всю статику положить в отдельную директорию. Посмотрите, к примеру, насколько просто выглядит конфигурация nginx для типичного сайта на Django:
https://uwsgi.readthedocs.io/en/latest/tutorials/Django_and_...


>> А затем этот URI с аргументами отправляете PHP-интерпретатору, чтобы тот опять парсил ваш URI.
> PHP URI не парсит. Он, разве что разбивает QUERY_STRING на GET-параметры, что
> очень лёгкая и быстрая задача, $_GET = explode('&',$_SERVER['QUERY_STRING']); причём
> деелает он это сам и всегда.

Вот вы сначала полностью перезаписываете URI, формируя новый QUERY_STRING из уже существующего URI, а затем этот QUERY_STRING будет парсится в недрах интерпретатора для заполнения хэш-массива $_GET. Хотя можно было бы просто взять $_SERVER['REQUEST_URI'] и выполнить над ним ту же самую регулярку, но сделать это в PHP-скрипте и получить сразу все ваши переменные. Но для этого не надо перезаписывать URI, а просто позвать нужный SCRIPT_FILENAME, ничего больше не меняя.

REQUEST_URI не обязан как-либо пересекаться с SCRIPT_FILENAME. Это в Apache с mod_php и .htaccess иначе сложно, там выполняемый файл эквивалентен запрашиваемому URI. С FastCGI не так и нет смысла тащить костыли от mod_php на FastCGI конфигурацию.


> Я его ничем лишним не нагружаю, он даже не понимает что я
> использую ЧПУ. В этом весь и смысл.

ЧПУ - это изобретение исключительно php-шников для решения собственноручно созданной проблемы. Сначала php-шники придумали, что файлы с кодом приложения надо класть в document root веб-сервера и запрашивать их как .html странички, а затем, обнаружив, что URI с .php на конце выглядят некрасиво - теперь героически придумывают способы преодоления.

Хотя просто не нужно мешать статику с данными в одной директории. Да и то, даже для такой смеси есть выход, см. выше.


>>> 3 Стоит ли мне включить опцию в nginx pcre_jit on;?
>>> Сделает ли она обработку моих Location-ов более производительной?
>> Возможно чуть ускорит.
> Ускорит только (пере)запуск nginx или также дальнейшую работу rewrite-ов.

Только работу. А перезапуск наоборот затормозит и памяти съест чуть больше. Ведь регулярки с включенной опцией pcre_jit будут компилироваться перед использованием. Т.е. есть плюсы и минусы. Поэтому опция по умолчанию и выключена.

Вообще в nginx все значения директив по умолчанию не с потолка взяты и лучше их не трогать без явной нужды.


> https://www.ssllabs.com/ssltest/analyze.html?d=gricargo.com
> 0-RTT enabled  No :-(

Я что-то не нашел  в сети сервера, на котором бы данный сайт показал Yes. Даже на специально созданных для демонстрации 0-RTT тестовых серверах (типа 0rtt.tls13.com) оно показывает No.

При этом в выводе:

% openssl s_client -connect gricargo.com:44

Можно наблюдать Max Early Data: 16384


> Хотелось бы если не формул, то инструкций по тому как узнать что
> процессов не хватает или их в избытке. Понимаю что эта тема
> не Ваша, буду разбираться с этим дальше.

Посмотрите для начала сколько у вас один процесс занимает памяти. Настраивать их количество больше, чем имеющейся свободной памяти на сервере - точно не стоит.

Ответить | Правка | Наверх | Cообщить модератору

106. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Ilya Indigo (ok), 27-Окт-19, 21:40 
> Почтовики? STARTTLS? Вы случайно с NNTP/Usenet не попутали? В списках рассылки можно
> хоть из веб-интерефейса Gmail с двухфакторной авторизацией общаться.

Нет не попутал. Отправить баг в postfix и dovecot через их маиллисты мне не представляется возможным. В Гугле, Яндексе и прочих зондах читающих Вашу почту и разрешающие общение с почтовиками без STARTTLS, можно, но я же PHP-ник, я ими не пользуюсь и никому не доверяю свою почту кроме своих почтовых серверов.

> index.html и так подставляется при запросе директории.  А вот эмулировать поведение
> log_not_found off; с помощью try_files - это странно.

А зачем вообще тогда по умолчанию заносить каждую 404 в лог ошибок?
Я думал логика в том, что каждый отдаваемый nginx-ом должен проходить через try_files, и если он отдаёт каким-то иным способом то именно это должно отображаться в файлах ошибок, но Ваш ответ меня удивил.

> Обычно вся конфигурация сводится к следующим двум location-ам:
> Всё предельно просто: если файл есть на диске - мы его отдаем,
> а всё остальное отправляем в приложение. Приложение уже возьмет $_SERVER['REQUEST_URI']
> и распарсит как угодно.

Огромная Вам благодарность за этот пример!
Во-первых я хоть где-то увидел как используется именованный location, когда в документации упоминается только что он есть и он указывается через @.
Во-вторых мне и в голову раньше не приходило, что так вообще возможно. Не знаю, можно ли так в апаче было сделать?
Мой код теперь.


error_page 404 /en/error;
location = /index.php
{
    return 404;
}
location ^~ /.
{
    return 404;
}
location /
{
    try_files $uri @php;
}
location @php
{
    fastcgi_pass unix:/run/php-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    include fastcgi_params;
}

А на стороне PHP

<?php if(strpos($_SERVER['REQUEST_URI'],'?') > 0)
{
    if(isset($_SERVER['REQUEST_URI'][59],$_GET['token'][19],$_GET['PayerID'][12]) && !isset($_SERVER['REQUEST_URI'][60]) && strpos($_SERVER['REQUEST_URI'],'/payment?') == 3)
        $_SERVER['REQUEST_URI'] = substr($_SERVER['REQUEST_URI'],0,strpos($_SERVER['REQUEST_URI'],'?'));
    else
    {
        unset($_GET,$_REQUEST);
        $_SERVER['REQUEST_URI'] = substr($_SERVER['REQUEST_URI'],0,4).'error';
    }
}
if(strpos($_SERVER['REQUEST_URI'],'/.') === false && strpos($_SERVER['REQUEST_URI'],'.php') === false)
{
    $arr = explode('/',substr($_SERVER['REQUEST_URI'],1));
    if(isset($arr[0][1]) && !isset($arr[0][2]))
    {
        $_GET['lang'] = $arr[0];
        if(isset($arr[1]))
        {
            $_GET['view'] = $arr[1];
            if(isset($arr[2]))
            {
                if($_GET['view'] == 'api')
                {
                    if(substr($arr[2],-6) == '=.html')
                    {
                        $_GET['data'] = substr($arr[2],0,$p=strpos($arr[2],'='));
                        $_GET['iv'] = substr($arr[2],++$p,-6);
                        unset($p);
                    }
                    else $_GET['view'] = 'error';
                }
                elseif(substr($arr[2],-5) == '.html')
                    $_GET['id'] = substr($arr[2],0,-5);
                else
                {
                    $_GET['tab'] = $arr[2];
                    if(isset($arr[3]) && substr($arr[3],-5) == '.html')
                        $_GET['id'] = substr($arr[3],0,-5);
                }
            }
        }
    }
    else $_GET['view'] = 'error';
    unset($arr);
}
else $_GET['view'] = 'error';

Я полностью избавился от регулярок и от дублирования, не считая повторяющийся return 404;
При этом на стороне PHP это делать проще и удобнее, причём для этого мне не нужны регулярки вообще!
Этим кодом я почти доволен.
Осталось только логи отформатировать, статус прикрутить и кеширование со сжатием добавить.

Вот только одна особенность nginx-а и try_files доставила мне проблем.
У Apache 403 всегда сопровождается заголовком Access Denied и означает только это.
У nginx 403 сопровождается заголовком Forbidden и может означать что угодно. :-(


location /
{
    index index.html;
    try_files $uri $uri/ @php;
}

По моей логике при $uri / или /static/js/lib_name/doc/ (в doc есть index.html) алгоритм должен быть такой (эмулирую то, что в Apache по умолчанию)
1 Проверяет если файл $uri Да - отдаёт Нет - идёт дальше.
2 Проверяет есть ли файл $uri/index.html Да - отдаёт Нет - идёт дальше
3 Если дошло до этого шга, то запрос отправляется в PHP.

Но каково было моё удивление и недоумение получить 403 Forbidden в этой конфигурации и далеко не сразу понять почему и где...
оказывается, если $uri/index.html не существует - то никакой передачи дальше в PHP не происходит а nginx тупо выдаёт 403 Forbidden
В итоге приходится не использовать индексирование и указывать полный путь к /static/js/lib_name/doc/index.html и подобным докам не приятно, но жить с этим можно.

Почему в nginx так и зачем так было сделано?
Можно ли как-то просто и универсально исправить проблему и привести к желаемому поведению?
И ещё интересный вопрос, можно ли как-нибудь ещё вызывать именованые location кроме как из try_files? Если да, приведите, пожалуйста, примеры

> Программисты на других ЯП всю дорогу так и делали и только PHP-шники
> извращаются.
> А ещё правильнее - это всю статику положить в отдельную директорию. Посмотрите,
> к примеру, насколько просто выглядит конфигурация nginx для типичного сайта на
> Django:
> https://uwsgi.readthedocs.io/en/latest/tutorials/Django_and_...

Видимо потому-что программисты на других языках, занимаются не web-сайтами, в их классическом понимании, а всякими CRM-ками, встроенными интерфейсами, например для управления IP-камерами и прочими вещами не предназначенными для всеобщего обозрения.
По этому им не нужна ни безопасность, ни ЧПУ, ни индексирование в поисковиках, ни вообще чтобы кто-то про них знал и их находил.

В конфигурации на Django всё, казалось бы красиво, но вот незадача, она совершенно не знает про /robots.txt и /sitemap.xml Эти файлы пойдут лесом. А ещё файлы авторизации различных СЕО-ников для разных систем аналитики, которые в корень кладутся...
Мне, как админу серверов, нужно для каждого из них правило в nginx прописывать и каждый раз сервер передёргивать?
Знаю про то что для последнего можно DNS использовать, но давать СЕО-никам доступ к DNS ещё хуже.

А более, на мой взгляд, главное, эта конфигурация не защищает от отдачи скрытых файлов!
Например .git, или даже .directory,
Слышал, в Яндексе как раз и было такое, что у них их /.git/ спокойно nginx раздавал.

Так что не вижу ничего плохого в том, чтобы класть index.php в DOCUMENT_ROOT и запрещать к нему доступ, как и доступ ко всем скрытым файлам и директориям хотя бы в DOCUMENT_ROOT.
Это и удобнее и безопаснее, тем более у меня ущё со времён апача в нём всего одна строчка <?php require dirname(__DIR__).'/init.php';

Ещё для меня одним неприятным открытием было, когда я убрал index.php из DOCUMENT_ROOT и вызывал сразу init.php, у меня перестал читаться .user.ini файл, даже после того, как я продублировал его за DOCUMENT_ROOT, видимо для его чтения он должен находится только в DOCUMENT_ROOT вместе с вызываемым скриптом (точкой входа).

Так что пользы от выноса index.php из DOCUMENT_ROOT я не вижу, а проблемы появляются достаточно.

> REQUEST_URI не обязан как-либо пересекаться с SCRIPT_FILENAME. Это в Apache с mod_php
> и .htaccess иначе сложно, там выполняемый файл эквивалентен запрашиваемому URI. С
> FastCGI не так и нет смысла тащить костыли от mod_php на
> FastCGI конфигурацию.

Я это уже понял. Для этого я и веду с Вами этот публичный диалог, чтобы работать с nginx правильно, а не так, как я привык работать с Apache.
А также чтобы это потом пригодилось не только мне, но у другим... PHP-никам.

> Можно наблюдать Max Early Data: 16384

Благодарю, значит работает! :-)

>> Хотелось бы если не формул, то инструкций по тому как узнать что
>> процессов не хватает или их в избытке. Понимаю что эта тема
>> не Ваша, буду разбираться с этим дальше.
> Посмотрите для начала сколько у вас один процесс занимает памяти. Настраивать их
> количество больше, чем имеющейся свободной памяти на сервере - точно не
> стоит.

На сервере же не один PHP работает. Там и MariaDB ей тоже ОЗУ нужна под всякие индексы.
Redis обитает, кеширующий ответы от MariaDB, и тоже будет рад лишней ОЗУ.
Но с redis я понимаю и знаю как определять и контролировать его расход ОЗУ и выдаю ему столько, сколько нужно, но чтобы без переизбытка.
И у php-fpm, наверно есть какой-то разумный предел кол-ва процессов, больше которого ресурсы потребляет, но выигрыш в производительности не приносит.
Или ему нужно отдавать все свободные ресурсы сервера?

Ответить | Правка | Наверх | Cообщить модератору

97. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Michael Shigorinemail (ok), 23-Сен-19, 20:24 
> Но Игорь и так не работал над nginx ещё с 2012, а я с 2017,
> что не мешает nginx-у продолжать активно развиваться последние годы.

Всяко спасибо за труды!

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

88. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от zo0Memail (ok), 22-Сен-19, 08:25 
о чем речь, разработка этих продуктов ведется параллельно разными командами.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

29. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Аноним (29), 20-Сен-19, 12:27 
Анонистные эксперты, ответьте: всё, просто нгинкс можно выбрасывать?
Ответить | Правка | Наверх | Cообщить модератору

84. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от KonstantinB (ok), 22-Сен-19, 04:12 
Зависит от задач. Unit - это прежде всего web application server (ну, не совсем, но очень важный кусочек его). Но судя по тому, в какую сторону он развивается, Unit это и есть давно обещанный Nginx 2 :-)
Ответить | Правка | Наверх | Cообщить модератору

89. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от zo0Memail (ok), 22-Сен-19, 08:27 
нет, нельзя, это по-прежнему основной продукт компании.
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

30. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от Аноним (30), 20-Сен-19, 13:05 
Я так и не понял, а зачем он для го и джавы нужен?
Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск сервера приложений NGINX Unit 1.11.0"  +3 +/
Сообщение от ansible (?), 20-Сен-19, 13:24 
А тебе и не надо значит™
Ответить | Правка | Наверх | Cообщить модератору

90. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от zo0Memail (ok), 22-Сен-19, 08:28 
эмм... запуск приложений, оркестрация?
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

34. "Выпуск сервера приложений NGINX Unit 1.11.0"  +3 +/
Сообщение от eRIC (ok), 20-Сен-19, 14:04 
то что научили и статику отдавать, очень хорошо, +++
Ответить | Правка | Наверх | Cообщить модератору

91. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от zo0Memail (ok), 22-Сен-19, 08:29 
таки да, кошерненько
Ответить | Правка | Наверх | Cообщить модератору

41. "Выпуск сервера приложений NGINX Unit 1.11.0"  –1 +/
Сообщение от Аноним (41), 20-Сен-19, 15:42 
Всегда интересовался вопросом, что такое "релиз" а что такое "выпуск". Берем эту тему, тут "релиз". Берем соседнюю тему "https://www.opennet.dev/opennews/art.shtml?num=51522" в которой пишут что Выпуск Samba 4.11.0, но потом "Представлен релиз" Может кто внятно объяснить чем релиз лучше выпуска?

Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск сервера приложений NGINX Unit 1.11.0"  +1 +/
Сообщение от Аноним (44), 20-Сен-19, 17:25 
Это синонимы. А разные варианты в одной и той же новосте - это чтоб не повторяться.
Ответить | Правка | Наверх | Cообщить модератору

46. "Выпуск сервера приложений NGINX Unit 1.11.0"  –2 +/
Сообщение от Аноним (46), 20-Сен-19, 18:38 
Когда-то Сысоев говорил, что не будет писать "второй апач". По факту написали уже ДВА апача, всё с тем же вкомпиленными mod_perl, mod_lua, mod_чёрт-в-ступе.

<...>
libnginx-mod-http-geoip
libnginx-mod-http-image-filter
libnginx-mod-http-lua
libnginx-mod-http-ndk
libnginx-mod-http-perl
libnginx-mod-http-subs-filter
libnginx-mod-http-uploadprogress
libnginx-mod-http-upstream-fair
libnginx-mod-http-xslt-filter
<...>

Ждём добавления поддержки .htaccess.

Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Sw00p aka Jerom (?), 20-Сен-19, 21:04 
>что не будет писать "второй апач".

таки да :)

>Ждём добавления поддержки .htaccess.

а вот этого не видать категорически, ибо нджинкс - не апач

Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от пох. (?), 20-Сен-19, 21:40 
> Когда-то Сысоев говорил, что не будет писать "второй апач". По факту написали

ты его неправильно понял - это он говорил про .htaccess, человекопонимаемые вложенные уровни синтаксиса и прочее ненужное устаревшее ненужно.

> уже ДВА апача, всё с тем же вкомпиленными mod_perl, mod_lua, mod_чёрт-в-ступе.

это соверенно не противоречит генеральной линии (хотя unit ни разу и не апач...скорее уж - tomcat?)

> Ждём добавления поддержки .htaccess.

вот этого можете ждать пока рак на горе не свистнет.

А я уже не надеюсь дождаться хотя бы чего-нибудь похожего на апачевский status в бешплатной версии. Причем я бы купил платную - если бы ее цена была хоть как-то экономически обоснована.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

53. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Sw00p aka Jerom (?), 20-Сен-19, 22:39 
>похожего на апачевский status

идите к раку на горе ) ибо ждите когда сам спустится.

вот status page нджинкса это хороший пример "ху*к-ху*ка", легче было бы если тупо циферки через пробел в одну строку и в документации описание полей, чем то гамно которое лет 15 как не изменилось, регексом в одну строку не пропарсишь.

Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от пох. (?), 20-Сен-19, 22:49 
я надеюсь, вы уже открыли для себя mod_vts? (это ни разу, конечно, не нормальный статус, но, во всяком случае, он умеет модный json)

> регексом в одну строку не пропарсишь

мне бы ваши проблемы... было бы там, что парсить.

Ответить | Правка | Наверх | Cообщить модератору

57. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от Sw00p aka Jerom (?), 20-Сен-19, 23:03 
>вы уже открыли для себя mod_vts?

спасибо, лишний раз не хочется слышать от Дунина - "отрубите все сторонние модули"

> мне бы ваши проблемы... было бы там, что парсить.

про мултилайн регекс увы не читал, ну как всегда бывает. Вы лучше бы скинули бы свой регекс :)


Ответить | Правка | Наверх | Cообщить модератору

85. "Выпуск сервера приложений NGINX Unit 1.11.0"  +/
Сообщение от KonstantinB (ok), 22-Сен-19, 04:13 
Ну мало ли какие модули кто понаписал.

Половина перечисленного - сторонние модули.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

70. "Выпуск сервера приложений NGINX Unit 1.11.0"  +2 +/
Сообщение от vitalif (ok), 21-Сен-19, 17:49 
> Встроена возможность самостоятельной отдачи статического контента без обращения к внешнему http-серверу

Ну норм, осталось туда весь обычный nginx встроить и будет таки апач!))

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру