При включении gzip не работает chunk-encoding
Добрый день.
Версии: nginx - 1.2.1 + php-fpm
Нужен совет. При включении gzip-а перестает работать chunk-encoding. В
заголовке ответа chunked содержится, но по-факту с включенным gzip страница
не отдается частями.
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Mon, 04 Nov 2013 09:57:07 GMT
Server:nginx
Transfer-Encoding:chunked
Vary:Accept-Encoding
X-Powered-By:PHP/5.4.4-14+deb7u5
Конфиги:
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 5;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json
application/x-javascript text/xml application/xml application/xml+rss
text/javascript;
..
upstream * {
server unix:/var/run/***-fpm.sock weight=5;
server *.*.*.*:9010 weight=5;
keepalive 5;
}
.
server {
server_name www.***.ua;
return 301 $scheme://.ua$request_uri;
}
server {
server_name .ua;
root /home/*.ua/www;
chunkin on;
access_log /home/**.ua/logs/access.log;
error_log /home/***.ua/logs/error.log;
charset utf-8;
include /etc/nginx/access.rules;
error_page 411 = @my_411_error;
location @my_411_error {
chunkin_resume;
}
location / {
try_files $uri @yii;
}
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
log_not_found off;
access_log off;
}
location ~ \.php$ {
return 404;
}
location @yii {
include fastcgi_params;
set $memcached_key $uri;
#memcached_pass **.ua;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 600;
fastcgi_read_timeout 600;
fastcgi_pass 127.0.0.1:9000;
#proxy_buffering off;
fastcgi_keep_conn on;
chunkin_keepalive on;
proxy_http_version 1.1;
}
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,244400,244400#msg-244400
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: При включении gzip не работает chunk-encoding
Такое впечетление, что есть какой-то буфер 4096+, который нужно заполнить, иначе чанк просто не отдается даже при сбросе буффера в php. Может это какой-то буфер в пхп или нжинксе? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244400,244401#msg-244401 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
настройка nginx для чайника
Доброго времени. Просьба не кидаться тухлыми помидорами, гугл использовал, wiki читал - но мозаика так и не сложилась. Решил давеча переехать на буржуйский vps, т.к. наши шареды больно падучи или везло так, не суть. Стал читать как nginx + php5-fpm поставить и все вроде бы срослось. Осталось дело за малым, просто понять само устройство, вероятно это настолько очевидно, что нигде не пишут о нем в целом, а я что-то торможу по всей видимости. Итак: 1. Есть файл в папке /etc/nginx/nginx.conf. Этот файл для примера лежит, или используется или его надо переместить в какое-то специальное место? 2. Для чего нужны папки: - sites-available - здесь лежит некий конфиг default, с таким вот содержимым http://pastebin.com/MPX0ii0g, которое позволяет работать только сайту site1.ru, но вот при входе на сайт site2.ru, открывается первый. - Как сделать, чтобы для каждого сайта был свой конфиг? Куда его класть и где до него прописывать инклюд, в nginx.conf? - sites-enabled - симлинк default на sites-available/default. Что в этой папке должно быть, её назначение? - conf.d - пустая, что в ней должно быть и её назначение? Буду безмерно благодарен, если ответите или дадите ссылку на мануал и простите за нубство. -- Relax, take it easy! ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: настройка nginx для чайника
> 1. Есть файл в папке /etc/nginx/nginx.conf. Этот файл для примера лежит, или > используется или его надо переместить в какое-то специальное место? Используется. Для тривиального случая там сделаны подходящие настройки, для нетривиального - возможно, его прийдется править. Вообще - его имеет смысл почитать, особо обращая внимание на директивы include. Многое станет понятным :) > sites-available - здесь лежит некий конфиг default, с таким вот содержимым > http://pastebin.com/MPX0ii0g, которое позволяет работать только сайту > site1.ru, но вот при входе на сайт site2.ru, открывается первый. Это debian-way конфиги. В этой папке лежат собственно конфиги сайтов. Но к работающей конфигурации могут быть подключены совсем не все, лежащие здесь. > Как сделать, чтобы для каждого сайта был свой конфиг? Куда его класть и где > до него прописывать инклюд, в nginx.conf? Класть в sites-available, прописывать симлинк в sites-enabled. Все, что есть в sites-enabled, инклюдится автоматически (это в штатном /etc/nginx/nginx.conf прописано) в секцию http. > sites-enabled - симлинк default на sites-available/default. Что в этой папке > должно быть, её назначение? см. выше. > conf.d - пустая, что в ней должно быть и её назначение? Сюда класть дополнения к стандартной конфигурации, которые должны быть за пределами секции http. Почитайте, повторюсь, /etc/nginx/nginx.conf - станет яснее. Для тривиальной конфигурации сюда ничего класть не прийдется. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: настройка nginx для чайника
Daniel, благодарю, теперь логика понятна. 04.11.2013 16:16 пользователь "Daniel Podolsky" написал: > > 1. Есть файл в папке /etc/nginx/nginx.conf. Этот файл для примера лежит, > или > > используется или его надо переместить в какое-то специальное место? > Используется. Для тривиального случая там сделаны подходящие > настройки, для нетривиального - возможно, его прийдется править. > Вообще - его имеет смысл почитать, особо обращая внимание на директивы > include. Многое станет понятным :) > > > sites-available - здесь лежит некий конфиг default, с таким вот > содержимым > > http://pastebin.com/MPX0ii0g, которое позволяет работать только сайту > > site1.ru, но вот при входе на сайт site2.ru, открывается первый. > Это debian-way конфиги. В этой папке лежат собственно конфиги сайтов. > Но к работающей конфигурации могут быть подключены совсем не все, > лежащие здесь. > > > Как сделать, чтобы для каждого сайта был свой конфиг? Куда его класть и > где > > до него прописывать инклюд, в nginx.conf? > Класть в sites-available, прописывать симлинк в sites-enabled. Все, > что есть в sites-enabled, инклюдится автоматически (это в штатном > /etc/nginx/nginx.conf прописано) в секцию http. > > > sites-enabled - симлинк default на sites-available/default. Что в этой > папке > > должно быть, её назначение? > см. выше. > > > conf.d - пустая, что в ней должно быть и её назначение? > Сюда класть дополнения к стандартной конфигурации, которые должны быть > за пределами секции http. Почитайте, повторюсь, /etc/nginx/nginx.conf > - станет яснее. > Для тривиальной конфигурации сюда ничего класть не прийдется. > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проблема с загрузкой файлов на сервер
PHP через mod_fcgid? 4 ноября 2013 г., 1:48 пользователь atemirov написал: > Дано: > > 1. VPS-сервер > > 2. Настройки PHP > — max_execution_time = 600 > — max_input_time = 600 > — memory_limit = 256M > — post_max_size = 100M > — upload_max_filesize = 100M > — max_file_uploads = 40 > > 3. Настройки ngnix > — client_max_body_size 100M в настройках ngnix > > При загрузке любых файлов (минимальный объем — 354 КБ) на сервер происходит > следующее: > загружаются примерно до 30%, после этого состояние загрузки сбрасывается на > 0%, файл снова загружается примерно на 30% и браузер (Chrome) выдаёт > следующую ошибку: Ошибка 101 (net::ERR_CONNECTION_RESET): Соединение > сброшено. > > В других браузерах аналогичная ситуация. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,244391,244391#msg-244391 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С ув. М.А. Мохначевский Отдел системного администрирования ООО "Компания "СахаИнтернет НТ" к.т. (4112)219711 доб. 927 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Медленная отдача статики
On 30 Oct 2013, at 12:08, Maxim Dounin wrote:
> Hello!
>
> On Mon, Oct 28, 2013 at 12:34:33PM -0400, buddha wrote:
>
>> Привет всем.
>> Знаю что вопрос уже обсуждался - почитал, попробовал - не выходит.
>>
>> Есть проблема с медленной отдачей статики. Что это значит:
>>
>> Отдача файла(js) ~40kb за 300-400ms
>> на drive.ru или ya 40kb за 70-90ms
>>
>> Т.е. разница в разы. и она ощутима.
>>
>> ping до сервера ~70ms
>> до drive и ya ~ 20-30ms
>>
>> отдает Nginx, config:
>>
>> location / {
>> sendfile on;
>> access_log off;
>> expires 4M;
>>
>> root /var/www/static
>> }
>>
>> сервер находится у хетцнера.
>>
>> Подскажите как можно приблизить скорость отдачи к drive или ya.
>> Если сервер, диск(хотя iowait 0.01-0.05), то подскажите на что его можно
>> заменить
>
> Судя по цифрам, то, что у вас получается - это в первую очередь
> результат большого RTT + работы механизмов Congestion Control
> протокола TCP.
>
> Можно пытаться походить в сторону тюнинга initial congestion
> window size. Но, строго говоря, много это всё равно не даст -
> где-то пару round trip'ов можно сэкономить при использовании
> сейчас усиленно продвигаемого initial cwnd в 10 пакетов (и чем
> больше ответ - тем меньше разница). Ну и на всякий случай
> напомню, что с тюнингом таких вещей следует быть осторожным, т.к.
> подобные действия отражаются на всех в сети. Прежде, чем
> ковыряться - лучше как минимум ознакомиться с теоретической
> стороной вопроса.
Максим, разве Google не провел исследования, по результатам
которых они подняли icwnd до 10 на своих серверах?
В последних версиях Linux kernel icwnd уже 10 по умолчанию
и может дать обратный эффект только в очень редких случаях
на сегодняшний день.
TCP fast open в kernel 3.6+ следующей шаг, в который Google
вкладывает силы и деньги.
>
> Вообще, IMHO, в первую очередь имеет смысл смотреть за тем, чтобы
> с клиентами обеспечивались постоянные соединения. В nginx'е они
> по умолчанию включены, но лишний раз проверить не помешает. В
> частности - посмотреть на директиву keepalive_timeout и убедиться,
> что там никто не написал 0 в попытке поэкономить соединения.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Медленная отдача статики
On 04 Nov 2013, at 18:09, Anatoly Mikhailov wrote:
>
> On 30 Oct 2013, at 12:08, Maxim Dounin wrote:
>
>> Hello!
>>
>> On Mon, Oct 28, 2013 at 12:34:33PM -0400, buddha wrote:
>>
>>> Привет всем.
>>> Знаю что вопрос уже обсуждался - почитал, попробовал - не выходит.
>>>
>>> Есть проблема с медленной отдачей статики. Что это значит:
>>>
>>> Отдача файла(js) ~40kb за 300-400ms
>>> на drive.ru или ya 40kb за 70-90ms
>>>
>>> Т.е. разница в разы. и она ощутима.
>>>
>>> ping до сервера ~70ms
>>> до drive и ya ~ 20-30ms
>>>
>>> отдает Nginx, config:
>>>
>>> location / {
>>> sendfile on;
>>> access_log off;
>>> expires 4M;
>>>
>>> root /var/www/static
>>> }
>>>
>>> сервер находится у хетцнера.
>>>
>>> Подскажите как можно приблизить скорость отдачи к drive или ya.
>>> Если сервер, диск(хотя iowait 0.01-0.05), то подскажите на что его можно
>>> заменить
>>
>> Судя по цифрам, то, что у вас получается - это в первую очередь
>> результат большого RTT + работы механизмов Congestion Control
>> протокола TCP.
>>
>> Можно пытаться походить в сторону тюнинга initial congestion
>> window size. Но, строго говоря, много это всё равно не даст -
>> где-то пару round trip'ов можно сэкономить при использовании
>> сейчас усиленно продвигаемого initial cwnd в 10 пакетов (и чем
>> больше ответ - тем меньше разница). Ну и на всякий случай
>> напомню, что с тюнингом таких вещей следует быть осторожным, т.к.
>> подобные действия отражаются на всех в сети. Прежде, чем
>> ковыряться - лучше как минимум ознакомиться с теоретической
>> стороной вопроса.
>
> Максим, разве Google не провел исследования, по результатам
> которых они подняли icwnd до 10 на своих серверах?
>
> В последних версиях Linux kernel icwnd уже 10 по умолчанию
> и может дать обратный эффект только в очень редких случаях
> на сегодняшний день.
>
> TCP fast open в kernel 3.6+ следующей шаг, в который Google
> вкладывает силы и деньги.
Насколько мне известно, TCP Congestion window имеет смысл
при согласовании окон получателя и отправителя. ICWND 2/3 были
установлены по умолчанию много лет назад во времена dial-up.
TCP Slow Start обязательно иметь включенным, но start after idle
нет смысла оставлять 1 сек, как и размер окна 2/3.
Мы уделяли большое внимание оптимизации TCP/IP стэка, результаты
ниже. В течение длительного времени я не заметил побочных эффектов,
возможно они и есть. Ваше мнение?
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_sack = 0
net.ipv4.tcp_timestamps = 0
net.core.wmem_max = 256960
net.core.rmem_max = 256960
net.core.wmem_default = 256960
net.core.rmem_default = 256960
net.ipv4.tcp_wmem = 409687380 16777216
net.ipv4.tcp_rmem = 409687380 16777216
>
>>
>> Вообще, IMHO, в первую очередь имеет смысл смотреть за тем, чтобы
>> с клиентами обеспечивались постоянные соединения. В nginx'е они
>> по умолчанию включены, но лишний раз проверить не помешает. В
>> частности - посмотреть на директиву keepalive_timeout и убедиться,
>> что там никто не написал 0 в попытке поэкономить соединения.
>>
>> --
>> Maxim Dounin
>> http://nginx.org/en/donation.html
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Уточнение логики работы ngx_http_auth_request_module
Hello! On Sat, Nov 02, 2013 at 10:21:39PM +0400, Dzmitry Stremkouski wrote: > Я установил nginx и модуль Максима Дунина (ngx_http_auth_request_module) > Настройку этого модуля производил по README от модуля. > Сам вебсервер собрал с такими параметрами в дебиане: > > nginx version: nginx/1.3.14 Порекомендую начать с простого. Не надо использовать 1.3.14, это старая и неподдерживаемая версия. Надо взять 1.5.6, где соответствующий модуль в коробке. [...] > Я пытался делать без проксирования, указывая URI > auth_request http://192.168.125.35/auth/ > Но это не работало и я в логах nginx видел ошибку > 2013/11/01 23:31:51 [error] 10938#0: *245 "/usr/local/nginx/htmlhttp:// > 192.168.125.35/auth/index.html" is not found (2: No such file or > directory), client: 192.168.125.47, server: ssl.stremki.net, request: "GET > /mail/ HTTP/1.1", subrequest: "http://192.168.125.35/auth/";, host: " > ssl.stremki.net" > > Было бы здорово, если бы я смог работать без проксирования /auth/. > Просто, пока не понял, как прописать внутренний бекенд для обработки и > сейчас > пользуюсь локейшном /auth/ в режиме проксирования. Модуль auth_request не пытается реализовывать каких-либо протколов сам, он просто делает подзапрос. Точно так же, как это делает SSI или модуль addition. Настроить необходимую обработку для соответствующего URI, который вы используете в auth_request - ваша задача, будь то проксирование или что-либо ещё. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как установить модуль http gzip static module?
On 24 Oct 2013, at 18:43, Dmitry Ivanov wrote: > Здравствуйте, tfox. > > Вы писали 24 октября 2013 г., 21:38:10: > >> Здравствуйте. >> Мне необходимо установить модуль http_gzip_static_module >> FreeBSD 9.1 >> Nginx/1.4.2 > >> Как это сделать? Читал, что нужно как то пересобирать/перекомпилировать из >> портов, но не понял. Я новичок. Помогите пожалуйста. > > cd /usr/ports/www/nginx > make config (там всякие чекбокссы понажимать) > make > make deinstall && make reinstall && /usr/local/etc/rc.d/nginx restart не надо чекбоксы нажимать, собирайте с одноименными ключами, например: ./configure --with-http_gzip_static_module… чтобы совсем наглядно - немного устаревший пример, но суть та же: https://gist.github.com/mikhailov/3052776 > > > -- > С уважением, > Dmitry mailto:nginx...@sadok.spb.ru > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Медленная отдача статики
Hello! On Mon, Nov 04, 2013 at 06:09:57PM +, Anatoly Mikhailov wrote: [...] > > Судя по цифрам, то, что у вас получается - это в первую очередь > > результат большого RTT + работы механизмов Congestion Control > > протокола TCP. > > > > Можно пытаться походить в сторону тюнинга initial congestion > > window size. Но, строго говоря, много это всё равно не даст - > > где-то пару round trip'ов можно сэкономить при использовании > > сейчас усиленно продвигаемого initial cwnd в 10 пакетов (и чем > > больше ответ - тем меньше разница). Ну и на всякий случай > > напомню, что с тюнингом таких вещей следует быть осторожным, т.к. > > подобные действия отражаются на всех в сети. Прежде, чем > > ковыряться - лучше как минимум ознакомиться с теоретической > > стороной вопроса. > > Максим, разве Google не провел исследования, по результатам > которых они подняли icwnd до 10 на своих серверах? Исследования Google отличаются, к сожалению, несколько однобоким подходом к проблеме. Вот тут, например, не рекомендуют: http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00 Я, впрочем, ничего против icwnd 10 не имею. Но наблюдал людей, бездумно ставящих icwnd 10, и призываю думать, прежде чем лезть в подобные вещи грязными руками. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Медленная отдача статики
On 04 Nov 2013, at 21:52, Maxim Dounin wrote: > Hello! > > On Mon, Nov 04, 2013 at 06:09:57PM +, Anatoly Mikhailov wrote: > > [...] > >>> Судя по цифрам, то, что у вас получается - это в первую очередь >>> результат большого RTT + работы механизмов Congestion Control >>> протокола TCP. >>> >>> Можно пытаться походить в сторону тюнинга initial congestion >>> window size. Но, строго говоря, много это всё равно не даст - >>> где-то пару round trip'ов можно сэкономить при использовании >>> сейчас усиленно продвигаемого initial cwnd в 10 пакетов (и чем >>> больше ответ - тем меньше разница). Ну и на всякий случай >>> напомню, что с тюнингом таких вещей следует быть осторожным, т.к. >>> подобные действия отражаются на всех в сети. Прежде, чем >>> ковыряться - лучше как минимум ознакомиться с теоретической >>> стороной вопроса. >> >> Максим, разве Google не провел исследования, по результатам >> которых они подняли icwnd до 10 на своих серверах? > > Исследования Google отличаются, к сожалению, несколько однобоким > подходом к проблеме. Вот тут, например, не рекомендуют: > > http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00 > > Я, впрочем, ничего против icwnd 10 не имею. Но наблюдал людей, > бездумно ставящих icwnd 10, и призываю думать, прежде чем > лезть в подобные вещи грязными руками. Разумеется, значения окон icwnd/rwnd больше 10-16 редко имеют смысл, а 10 - так вообще глупо. Google разработали SPDY и установка размера окон - это одна из важных их рекомендаций к использованию SPDY на стороне сервера, ровно как и увеличение/отключение таймаута на сужение окна tcp_slow_start_after_idle: http://dev.chromium.org/spdy/spdy-best-practices > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
