Стоит ли пытаться оптимизировать регулярные выражения Nginx?

Question

В виртуальном хосте Nginx, я добавил эти места, два из которых используют регулярные выражения:

location ~ /-/pubsub/subscribe/(.*)$ { 
     # subscribe to websocket 
    } 
    location ~ /-/pubsub/publish/(.*)$ { 
     # websocket publish endpoint 
    } 
    location/{ 
     # reverse proxy to the application server 
    } 

Но вместо этого я могу сделать что-то вроде этого, чтобы «скрыть» регулярные выражения?

location /-/pubsub/ {  <-- can be tested without any regex matching 
     location ~ subscribe/(.*)$ { ... } 
     location ~ publish/(.*)$ { ... } 
    } 

    location/{ 
     # reverse proxy 
    } 

Мне кажется, что это позволило бы избежать разбора каких-либо регулярных выражений для запроса сопоставления location /, потому что они будут сравниваться с location /-/pubsub/ (без регулярных выражений) вместо location ~ /-/pubsub/whatever/(.*)$ (с регулярным выражением), не так ли?

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

location /-/uploads/public/video/ { 
    location ~ \.(mp4|m4v|m4a)$ { <-- regex matching for videos only 
     mp4; 
    } 
    } 

    location /-/uploads/public/ { 
    # all other files: no regex matching needed 
    } 

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

Answer 1

Я провел несколько быстрых тестов с ab (https://httpd.apache.org/docs/2.4/programs/ab.html), и я не вижу разницы в производительности с простым регулярным выражением ниже, а не без.

Я испытал это:

location /-/uploads/public/ { 
    access_log off; 
    alias /opt/debiki/uploads/public/; <-- serving one 1.4 kb avatar image from here 
    autoindex off; 
    sendfile on; 
    sendfile_max_chunk 2m; 
    tcp_nopush on; 
    expires 31d; # later: expires 365d; 

    location ~ \.(mp4|m4v|m4a)$ { <-- regex 
    mp4; 
    } 
} 

Комментирование регулярное выражение не делать вещи быстрее, таким образом, что я заметил. (например, 5 или 10 образцов с регулярным выражением и 5 или 10 без, ab -n50000 -c10 каждый образец. Результаты были между 14500 и 15500 req/seq, довольно случайным образом, как с регулярным выражением, так и без него).

Таким образом, мой вывод состоит в том, location regex можно избежать бесплатно, тогда да. Но если избегать простого регулярное выражение, например, location ~ \.(mp4|m4v|m4a)$, это немного сложно, например, перемещение определенных файлов в другой каталог, а затем нет, не делайте этого. Это не стоит. (Более сложные регулярные выражения? Тогда я не знаю.)

Answer 2

Это зависит от вашего прецедента. Поскольку nginx использует pcre, в конечном счете вы спрашиваете: «Использует ли процессор pcre», что является очевидным да. Однако, если большая часть работы nginx делает, обслуживает файловые объекты и управляет удаленными сокетами tcp, то вы не увидите влияния. Если вы делаете чрезвычайно прокси-работу с nginx (думаю, 50k + соединения), то я уверен, что вы будете испытывать значительное влияние производительности при оптимизации регулярных выражений.

Чтобы точно знать, что такое узкое место, вам нужно использовать инструмент как tcpdump и искать байт по времени. Кроме того, скамья apache является однопоточной и, следовательно, очень ограничена в использовании для высокопроизводительных веб-серверов. Если вам нужно использовать этот инструмент, я рекомендую создать кластер из экземпляров ab и добавить результаты вверх;)