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