Re: nginx и post-запросы
Dmitry E. Oboukhov un...@debian.org wrote: [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 132 строк --] ну сейчас она итак отдается nginx'ом с фронтенда. сервакам сильно полегчало. AM Подозрительно всё это. apache отдает статику неплохо сам по себе. плохо он отдает статику. по сравнению с nginx во всяком случае AM Тюнить пробовалось? если бы очевидное решение перед носом не валялось попробовалось бы. а кстати, какие предложения в описанном ниже случае? AM Написал же внизу. thttpd + включить в нем sendfile. Или lighttpd + sendfile. нет. ты говорил апач хорошо умеет статику, вопрос был именно в этом контексте. Еще раз: ставь thread model. модель один процесс - один коннект у тебя не тянет. Можно с EnableSendfile On. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/s10sv7-l8l@kenga.kmv.ru
Re: nginx и post-запросы
Dmitry E. Oboukhov un...@debian.org wrote: AM Эээ, может правильней писать - корявые скрипты, авторы которых не асилили AM правильно выдать имя файла? Или у вас документально завялена поддержка AM Misaic и HTTP/0.9 до скончания веков задарма? есть проблема в IE версии 6. на нем еще сколько-то корпоративных клиентов сидит а у него с русскими символами в имени файла еще туго. вот пока этот хак и вертится... местами. AM Это проблема клиентов. Есть куча вменяемых браузеров, а не это AM неподдерживаемое M$ решето с кучкой кривых эктив-иксов. клиенты приносят бабло. соответственно им можно выдать рекомендацию, но ... не неработающий сервис :) Вы не умеете лечить совковый синдром клиент с баблом - всегда прав? Если клиент хочет сидеть на своем ишаке - то велкам (за отдельные деньги, более другие, можно даже на порядок больше чем для всех) на отдельный сервер для любимых клиентов с ишаком. И тут у клиента сразу появяться технические возможности поставить современный браузер... но вопрос собственно не об этом так вот, location'ов на все такие места прописывать слишком много (надо разгребать что там пользователи в подкаталогах с .htaccess намутили), а можно ли nginx заставить всегда проксировать POST-запросы? AM Заставить то можно, только внимание вопрос - а нафига в этой схеме nginx? AM Нонче круто всё делать чрез nginx? статика там - 2/3 нагрузки. соответственно nginx ее берет на себя, а динамику на бакенде апач... AM Вынести статику на отдельный домен, и отдавать её nginx'ом. ну сейчас она итак отдается nginx'ом с фронтенда. сервакам сильно полегчало. Подозрительно всё это. apache отдает статику неплохо сам по себе. Если верить сильно полегчало - значит проблема просто замаскирована установкой nginx. но для этого пришлось слезть с стейбла в тестинг, ибо стейбловский nginx try_files еще не поддерживал, но... не очень нравится мне это AM ой, шо ви говорите. У нас stable == протухло до момента релиза stable. AM Можно было и не слезать в тестиг - просто пересобрать пакет для lenny, благо AM развесистых зависиомстей оно не тянет. Так-же, можно еще обнаружить, что AM libapache2-mod-rpaf у нас, , даже не третей, пятой свежести. ну свежесть она становится необходима только когда утыкаешься во что-то неработающее :) Ага, об try_files в протухшем nginx ты сам стукнулся, об нерабочем rpaf (не понимает X-Real-Ip заголовок) - значит еще нет. Или у тебя апач все реквесты от 127.0.0.1 видит? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/rq2uu7-57f@kenga.kmv.ru
Re: nginx и post-запросы
Dmitry E. Oboukhov un...@debian.org wrote: [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 102 строк --] ну сейчас она итак отдается nginx'ом с фронтенда. сервакам сильно полегчало. AM Подозрительно всё это. apache отдает статику неплохо сам по себе. плохо он отдает статику. по сравнению с nginx во всяком случае Тюнить пробовалось? вот домашний говносервер (P3-700) с апачем. апач на нем стоит (стоял) года три: жена кладет в директорию фотографии (и прочий мусор) когда хочет чтобы кто-то их скачал. воркер настроен по дефолту (на максимум 150 клиентов ЕМНИП (да много для такого, понимаю)), никаких CGI/mod_хрень 150 коннетов на воркер - это чтоб вечно текущие php скрипты всю память не сожрали. не было (не нужно ей это ничего: ей надо файл положить и дать ссылку кому-то). на nginx перелез когда этот сервак лег: она имела несоторожность пару фоток какого-то нового изделия выложить на посещаемый форум: сколько-то человек просто посмотрело страничку про вязание и не увидело фотографию, поскольку на предыдущих человеках сервак уже лежал. Ну тут думать надо, прежде чем выкладывать. Для выкладки картинок в нагруженые форумы есть более подходящие методы - выложить скажем в coral cdn. читать - тут http://habrahabr.ru/blogs/i_recommend/82739/ поставил nginx не думая о тюнинге и попросил ее для теста там же выложить еще пяток фоток. поглядел что все ок и забыл о проблеме. Логично, nginx помог только тем, что у него нету модели апачи: один воркер - один клиент. Или ставить второй апач с thread моделью воркера или вобще какой thttpd. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/papuu7-sjm@kenga.kmv.ru
Re: nginx и post-запросы
Dmitry E. Oboukhov un...@debian.org wrote: [-- text/plain, кодировка quoted-printable, кодировка: utf-8, 140 строк --] ну сейчас она итак отдается nginx'ом с фронтенда. сервакам сильно полегчало. AM Подозрительно всё это. apache отдает статику неплохо сам по себе. плохо он отдает статику. по сравнению с nginx во всяком случае AM Тюнить пробовалось? если бы очевидное решение перед носом не валялось попробовалось бы. а кстати, какие предложения в описанном ниже случае? Написал же внизу. thttpd + включить в нем sendfile. Или lighttpd + sendfile. [...] поставил nginx не думая о тюнинге и попросил ее для теста там же выложить еще пяток фоток. поглядел что все ок и забыл о проблеме. AM Логично, nginx помог только тем, что у него нету модели апачи: AM один воркер - один клиент. AM Или ставить второй апач с thread моделью воркера или вобще какой thttpd. а треды - те же процессы только облегченные. то бишь проблема не решается, а ослабляется. Ну так и nginx с его FSM моделью - тож её ослабляет. Следующим узким местом станет или канал или скорость отдачи с диска. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/khuuu7-iss@kenga.kmv.ru
Re: nginx и post-запросы
Dmitry E. Oboukhov un...@debian.org wrote: есть такая задача нечто вроде того что делаем POST http://url/имя.файла.txt, а на деле вызывается CGI который отдает содержимое файла. Эта фигня используется чтобы обмануть старые браузеры и заставить их скачивать корректные имена файлов. Эээ, может правильней писать - корявые скрипты, авторы которых не асилили правильно выдать имя файла? Или у вас документально завялена поддержка Misaic и HTTP/0.9 до скончания веков задарма? так вот, location'ов на все такие места прописывать слишком много (надо разгребать что там пользователи в подкаталогах с .htaccess намутили), а можно ли nginx заставить всегда проксировать POST-запросы? Заставить то можно, только внимание вопрос - а нафига в этой схеме nginx? Нонче круто всё делать чрез nginx? PS: Предвидя праведные вопли если вам нефиг сказать - чо лезем, отвечаю - если бы чукча умел читать документацию и не был бы забанен на гугле - то найти кусок конфига с использованием try_files (http://forum.nginx.org/read.php?2,4893,4924) смог бы сам, но - увы. PPS: Да, идея отдавать через cgi то, что можно отдать nginx'ом через X-Accel-Redirect - ущербна еще более... Впрочем - поддержка cgi в наше вермя вобще смахивает на бред сумашедшего. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0o1su7-eev@kenga.kmv.ru
Re: nginx и post-запросы
Dmitry E. Oboukhov un...@debian.org wrote:
[-- text/plain, кодировка quoted-printable, кодировка: utf-8, 188 строк --]
нечто вроде того что делаем POST http://url/имя.файла.txt, а на деле
вызывается CGI который отдает содержимое файла. Эта фигня используется
чтобы обмануть старые браузеры и заставить их скачивать корректные
имена файлов.
AM Эээ, может правильней писать - корявые скрипты, авторы которых не асилили
AM правильно выдать имя файла? Или у вас документально завялена поддержка
AM Misaic и HTTP/0.9 до скончания веков задарма?
есть проблема в IE версии 6. на нем еще сколько-то корпоративных
клиентов сидит а у него с русскими символами в имени файла еще туго.
вот пока этот хак и вертится... местами.
Это проблема клиентов. Есть куча вменяемых браузеров, а не это
неподдерживаемое M$ решето с кучкой кривых эктив-иксов.
но вопрос собственно не об этом
так вот, location'ов на все такие места прописывать слишком много
(надо разгребать что там пользователи в подкаталогах с .htaccess
намутили), а можно ли nginx заставить всегда проксировать POST-запросы?
AM Заставить то можно, только внимание вопрос - а нафига в этой схеме nginx?
AM Нонче круто всё делать чрез nginx?
статика там - 2/3 нагрузки. соответственно nginx ее берет на себя, а
динамику на бакенде апач...
Вынести статику на отдельный домен, и отдавать её nginx'ом.
я пока извернулся следующим образом:
location / {
root /path/to;
try_files $uri @post;
}
location @post {
proxy_pass http://localhost:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
но для этого пришлось слезть с стейбла в тестинг, ибо стейбловский
nginx try_files еще не поддерживал, но... не очень нравится мне это
ой, шо ви говорите. У нас stable == протухло до момента релиза stable.
Можно было и не слезать в тестиг - просто пересобрать пакет для lenny, благо
развесистых зависиомстей оно не тянет. Так-же, можно еще обнаружить, что
libapache2-mod-rpaf у нас, , даже не третей, пятой свежести.
AM PS: Предвидя праведные вопли если вам нефиг сказать - чо лезем,
я сам очень люблю влезть в таком стиле, так что спокойно отношусь к
аналогичным влазиньям :)
если бы на письмо никто не ответил совсем было бы грусно :)
AM отвечаю -
AM если бы чукча умел читать документацию и не был бы забанен на гугле - то
найти
AM кусок конфига с использованием try_files
(http://forum.nginx.org/read.php?2,4893,4924)
AM смог бы сам, но - увы.
да, это-то я сразу нашел. но тут не очень хорошо что получается все
что он не найдет пройдет через бакенд. а это нехорошо. большинство
запросов - GET. если бы была возможность форварднуть только POST, то
все (большинство) 404/403 что возможны остались бы на nginx
Ну ведь чукча не читатель, да? Если бы чукча был читатаель, он бы заметил,
что POST в статику вызывает 405 ошибку, которую через error_page 405 можно
куда засунуть? Правильно - в именованый location с набором proxy_pass co.
AM PPS: Да, идея отдавать через cgi то, что можно отдать nginx'ом через
AM X-Accel-Redirect - ущербна еще более... Впрочем - поддержка cgi в наше
вермя
AM вобще смахивает на бред сумашедшего.
cgi там вещь историческая, а X-Accel-Redirect не подходит, там файло
Историческим вещам место в музее...
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4i1tu7-s1b@kenga.kmv.ru
Re: nginx и post-запросы
В Срд, 29/12/2010 в 23:09 +0300, Dmitry E. Oboukhov пишет:
нечто вроде того что делаем POST http://url/имя.файла.txt, а на деле
вызывается CGI который отдает содержимое файла. Эта фигня используется
чтобы обмануть старые браузеры и заставить их скачивать корректные
имена файлов.
AM Эээ, может правильней писать - корявые скрипты, авторы которых не асилили
AM правильно выдать имя файла? Или у вас документально завялена поддержка
AM Misaic и HTTP/0.9 до скончания веков задарма?
есть проблема в IE версии 6. на нем еще сколько-то корпоративных
клиентов сидит а у него с русскими символами в имени файла еще туго.
вот пока этот хак и вертится... местами.
но вопрос собственно не об этом
так вот, location'ов на все такие места прописывать слишком много
(надо разгребать что там пользователи в подкаталогах с .htaccess
намутили), а можно ли nginx заставить всегда проксировать POST-запросы?
AM Заставить то можно, только внимание вопрос - а нафига в этой схеме nginx?
AM Нонче круто всё делать чрез nginx?
статика там - 2/3 нагрузки. соответственно nginx ее берет на себя, а
динамику на бакенде апач...
я пока извернулся следующим образом:
location / {
root /path/to;
try_files $uri @post;
}
location @post {
proxy_pass http://localhost:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
но для этого пришлось слезть с стейбла в тестинг, ибо стейбловский
nginx try_files еще не поддерживал, но... не очень нравится мне это
ну и зря не нравится. это - правильный сопосб
а rewrite тормозит
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1293688961.29036.26.ca...@localhost.localdomain
