Жуткие тормоза на новом VPS

1. ну вот - а апачи плодятся меньше из-за nginx'а как прокси.

отдача статики nginx'ом видимо вам мало помогла

2. наверно proxy_read_timeout 90;

Ну, как я уже писал, почему-то не вся статика, что точно должна была пройти проверку и выдаваться через nginx выдаётся им. Т.е. запрос долетает до апача. Но процессы плоятся сейчас в несколько раз меньше. И если раьше при максимальных 80 процессах (и соединениях соотв.) были тормоза и жалобы на "неоткрыване сайтов". То сейчас процессов в среднем 20, из них реально занято обычно около 1-5. Память экномится, цель достигнута :)

Да, я привёл часть ошбки из лога и по полной строке вдно что nginx не дождался от апача отдачи какого-нибудь файла типа script.js или style.css... Хотя нафига он к нему за этой ерундой полез, спрашивается. Увеличил до 120, посмотрю что даст.

Оказалось это я криворучко. nginx не принимает в RegExp у location значение переменной $blox а считает это как текст, и поэтому условие никогда не сходится. В итоге удовлетворяется семое первое правило 'location / {}' а по нему запрос должен быть передан в апач как есть.

Мучался долго. Реально можно только if запихнуть внутрь location (а если наоборот, то ругается) но это не выход. Ведь если запрос уже удовлетворяет location то оно и выполняется и отбросить изнутри никак нельзя. Поскольку proxy_pass для условия и/или location с использование RegExp недопустим также. Я в тупике :(

логика с выправлением канонического имени хоста в переменную $hostlt - вполне рабочая

а зачем вам остальное? - отдавайте просто по статическому регекспу статику

Всё так, но вопервых я прежде должен проверить наичие файла на диске. Почему?

1. не всегда сайт лежит как /var/www/$host/$uri бывает и что /var/www/domain.ru/$host/$uri

2. бывает что это хитрый реврайт. типа www.site.ru/news/2009/11/07/image.jpg который лежит на самом деле в www.site.ru/images/news/thnb/image.jpg

2. бывает, что обработчик 404 скриптом сайта перехвачивается и выдаёт какую-то "свою" страницу, либо вовсе подсовывает другой файл и меняет 404 на 200. и это должно работать как раньше.

поэтому в статике нужно отдавать только то, что сперва было проверено как -f а всё прочее скармливать уже апачу. вот на этом условии я и застрял в реализации. будь возможность вставить location внутрь if я уже всё давно сделал бы. Ну или как я сперва думал - подсунуть в переменной часть RegExp для location.

можно поробовать через обработчик 404 ошибки:

если файл (статика по расширению) не найден - проксируем запрос дальше на бакенд

Да, так я тоже попытался. Что-то вроде

error_page 404 = @apache2;

затем

location @apache2 {

proxy_pass http://localhost:8080/;

}

но такую конфигурацию он не принял, поскольку определение error_page стоит внутри той самой location для статики, которая RegExp и поэтому нельзя внутри неё использовать proxy_pass :) Не конфиг а скрипт прямо. Все вложения учлись.

Хотя сейчас я думаю что возможно определять error_page не обязательно внутри условия if или location а просто внутри server? Ведь в конечном счёте мне любые ошибки надо отсылать к апачу на обработку. Одно правда неудобство ещё остаётся:

есть location / {} который фактически все адреса и обрабатывает. И именно его я так понимаю надо преобразовываь в именованный location @apache2. Но как тогда сделать так, чтобы не писать этот location дважды - для / и для @apache2? Тут мыслей никаких. Впринципе это не особо важно, накрайняк можно вынести все настройки прокси в инклюд и подключать его внутри этих двух одинаковых по содержанию location. Более удачного варианта не придумалось.

думаю, что так

Попытка снова не удалась :) результат:

[emerg]: "proxy_pass" may not have URI part in location given by regular expression, or inside named location, or inside the "if" statement, or inside the "limit_except" block in /usr/local/nginx/conf/nginx.conf:136

configuration file /usr/local/nginx/conf/nginx.conf test failed

что там было:

error_page 404 = @apache2;

location @apache2 {

proxy_pass http://127.0.0.1:8080/;

...

}

где строка с proxy_pass и есть 136. Вот этого я откровенно не понял. В документации есть примеры использования именно proxy_pass внутри именованной локации. Причёи именно для error_page. Но у меня nginx 0.7.63 почему-то ругается.

Мануал читал тут http://wiki.nginx.org/NginxHttpCoreModule#error_page

там пример такой:

location / (

error_page 404 = @fallback;

)

location @fallback (

proxy_pass http://backend;

)

Есть идеи?

Всё решилось. Оказывается надо было писать не

proxy_pass http://127.0.0.1:8080/;

а

proxy_pass http://127.0.0.1:8080;

хотя принципиальной разницы не вижу если честно...

у меня работает и со слешом. например,

upstream backend {
    server 127.0.0.1:8080;
}
...
proxy_pass http://backend/;

версия 0.7.63