MD> Совсем правильный ответ - перепроектировать систему так,
MD> чтобы location'ы с регулярными выражениями в конфиге отсутствовали.
потому что сопоставление запроса и регулярного выражения в location ~ \.php$
занимает слишком много ресурсов процессора, или почему такая рекомендация?
MD> Потому что они все проверяются для каждого запроса последовательно, внося
MD> оверхед пропроциональный количеству описанных location'ов с regexp'ами.
MD> Соответственно - такой подход не масштабируется.
Ok. а если location`ы сделать вложенными, [
]
IS> http {
IS> server {
IS> location / {
IS> location /a/ {
IS> location ~ \.php$ {
...
location /b/ {
location ~ \.phtml$ {
...
то при запросе файла /b/2.phtml будет проверяться только один regexp. (?)
Принципиально это, вообще говоря, ситуацию не меняет. Но позволяет
избавиться от лишнего оверхеда там, где он гарантированно не нужен, да.
от location'ов с регулярными выражениями можно избавиться только
двумя способами - вынесением статики в отдельные server/location
и с помощью location @fallback (но здесь будут "лишние" syscalls) (?)
Как вариант - явным прописыванием location'ов, которые нужно проксировать.
Я лично предпочитаю разносить статику и динамику по разным location'ам,
при этом всю динамику прописывать явно.
MD> Ну и по тем же причинам, о которых уже сказал Игорь - они вносят
MD> необходимость мучительно искать "а какая же конфигурация сработала".
MD> Собственно, раз в неделю возникающие вопросы "а почему у меня не
MD> включается авторизация на index.php" - это оно и есть.
причем в 99.99% случаев они хотят закрыть ip-фильтром/паролем admin-панель
сайта.
многие сайты, написанные на php, так просто на статику и динамику - не
разделить.
Понятно, что для произвольного содержимого, в котором нет ни времени ни
желания разбираться (а тем паче для случая хостинга) - "совсем правильно"
не сделаешь. Что не мешает стремиться к прекрасному.
