Возможно у вас в DevTools браузера, стоит галочка "Disabled Cache"
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,291736,291745#msg-291745
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
> Решение о push'е принимается при генерации HTML-ответа за запрос к
> странице.
> В этот момент доступны If-None-Match и/или If-Modified-Since только
> самой страницы и странно ориентироваться на них, так как они ничего не
> говорят о наличии в кэше клиента тех ресурсов, которые мы планируем
> про
> В крайнем случае несложно пометить клиента стандартным способом через
> cookie.
Советую смотреть не на куки, а на наличия клиенских заголовков -
If-None-Match и/или If-Modified-Since, только при отсутствии или не
валидности данных заголовков делать push.
Из нашего опыта - push полезен только для
> Единственный правильный способ тестирования - тестирование на реальных
> нагрузках со своими собственными приложениями и задачами.
Согласен, но это делают потом, на ранней стадии тестят синтетикой, просто
чтобы примерно оценить оверхед, когда они увидят 6х замедления, это может
отбить желания те
Сделал простой бенчмарк (wrk -c 50 -d 30s -t 50 http://127.0.0.1) вашего
Hello World примера
https://www.nginx.com/blog/nginx-unit-1-5-available-now/#go-node-js-applications
И сравнил с HTTP сервером что мы юзаем (uWebSockets)
Результаты:
Unit - Requests/sec: 17384
uWebSockets - Requests/sec: 11
> Есть сервис Pusher, который позволяет раздавать потоки по WebSocket.
> Никакой инфраструктуры не нужно. Подозреваю там есть прямые и обратные
Так мы тоже самое получаем безплатно и без сторонних сервисов, простой
надстройкой nchan + uWebSockets.js
Posted at Nginx Forum:
https://forum.nginx.or
> Что мешает реализовать данную функциональность в приложении?
> Например, используя тот же упомянутый uWebSockets.js?
Нам мешают те же причины что у вас, бизнесу выгодно чтобы мы писали больше
бизнес логики и меньше писали инфрастуктурного кода.
Да, можно сделать распределеную систему на Pub/Sub
> кеше битые обрезанные файлы, при использовании на бэкенде gzip, тот же
> баг
Попробуйте выключить настройку в конфигt Nginx
sendfile off;
Нам это помогло.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,285250,285255#msg-285255
___
nginx-
> Пока не планируем.
Ясно, но тогда вот что выходит, тем кому нужен WebSocket, как правило нужен
broadcast и возможностость подписать одного клиента к множеству каналов.
Эти задачи уже успешно решены в nchan (модуль Nginx) и для Node.js есть
uWebSockets.js (сишный модуль) к сожалению это означает
> для мобильных клиентов есть (уже) TLS1.3 + early data, TFO (tcp fast
> open).
> пользуетесь ?
TLS1.3 - да
early data, TFO - нет, у нас проблема с частыми обрывами конекта в
WebSocket, мобил клиенты этому сильно подвержены, из-за TCP...
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2
Возможно я не нашел, но в данной версии нет возможности broadcast каналов?
Когда одно сообщения передается множеству WebSocket клиентов и как одного
клиента подписать на множество каналов?
Этого нет в текущей версии или вы не планируете этого делать и данный
функционал нужно будет писать самому на
В вашей дорожней карте, для ветки 1,17 есть в планах имплементация QUIC
(HTTP/3), какие ваши оценки по времени это будет готово в этом году.
И если не сложно скажите как вам QUIC там реально много профита для мобил
клиентов, у нас очень много мобил HTTP клиентов и нам эта тема очень
интересна.
Спас
> Тем временем, мы продолжаем трудиться над поддержкой WebSocket для
> модулей
> Node.js и Java. Все почти готово; шансы на то, что это войдет в
> следующий
> выпуск - очень велики.
Возможно уже есть документация и открытое бета тестирования для Node.js?
> Напоминаю, что мы непрерывно находимся
> RFC 8441, Но
> это, скажем так, выглядит как хак, при этом малосовместимый с
> существующей логикой работы через Upgrade, и имеет мало шансов
> быть поддержанным.)
Есть реализация (клиент и сервер)
https://github.com/warmcat/libwebsockets
В Chrome тоже давно работает.
https://www.chromestatu
> Я не слежу за разработкой PHP, но если вы по прежнему наблюдаете
> проблему - можно предположить, что баг в PHP так и не поправили, и
> fastcgi_finish_request() пользоваться не стоит.
Да, у нас это была одна из причин, уйти от FPM, и перейти на Swoole
https://www.swoole.co.uk/docs/
Потом на са
> Я заметил, что вы много всего просите, а могли бы стать нашим
> крупнейшим
> клиентом и тем самым влиять на ход разработки тех или иных
> возможностей,
> как в nginx, так и в Unit. Разработка обходится совсем не бесплатно и
> потому получают приоритет в первую очередь те вещи, которые позволяют
> поддержкой WebSockets, гибкой
маршрутизацией запросов и выдачей статического контента.
Этого действительно не хватает в Unit.
НТТР кеширования, как в Nginx, тоже уже в разработке?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,281345,281350#msg-281350
_
> Но к вебсокетам все это никакого отношения не имеет, не так ли?
Да, вы правы, мой ответ был в контексте НТТР запросов.
Польза для WebSocket использовать сокет Н2, в том что он будет держать
открытым сокет, который использует ajax запросы.
У нас может быть 20-30 ajax потом минут 15 тишина, юзер
> От самого мультиплексирования на уровне приложения приемуществ особых
> нет,
> больше недостатков.
Судите сами, на уровне приложения (браузера) сейчас есть два варианта:
НТТР 1х - лимит 8 открытых сокетов на 1 хост, все запросы становятся в эти 8
очередей.
НТТР 2 - в 1 сокет отправляются все
> А в чём преимущества HTTP2 для Вас? Вы пробовали делать замеры,
> сравнивающие HTTP2 с HTTP1.1?
Для нас преимущество только в мультиплексировании, других преимуществ нет, у
нас просто много параллельных ajax запросов, НТТР 2 push не использовали,
возможно тоже полезная штука, но практики
> Если/когда появится стандарт
> и реализации в браузерах - посмотрим.
Это уже работает в Chrome 66 (Canary) и Firefox разрабатывает реализацию,
судя по всему браузеры пришли к консенсусу в этом вопросе.
> Хотя вот лично мне - усиленно кажется, что конкретный драфт - суть
> достаточно вялая и н
Chrome, реализовал WebSockets поверх HTTP/2
https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-00
https://www.chromestatus.com/feature/6251293127475200
Есть в планах Nginx, реализации проксирование WebSockets поверх HTTP/2?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,
> Push cache очищается при закрытии
> соединения, но все элементы при первом использовании браузером будут
> помещены в http cache, так что всё нормально.
> Подробнее здесь:
> https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/
Если ресурс отданный push ответом, используется на стран
> Не совсем понял ваши слова про "не кешируемый контент".
По спецификации НТТР 2, браузер push ответы могут кешировать только в
отдельном кеше соединенния (смотрите на connection_id в devtools), после
закрытия соединения кеш очищается.
Или я не прав, браузеры сохранят push ответы в общем кеше и по
Я не вижу большой пользы от push, очень редкий случай когда нужно отправить
дополнительный не кешируемый контент без запросов, или я ошибаюсь, вы
можете перечислить свои use case?
Спасибо.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,278784,278816#msg-278816
_
> Иными словами сервис - это более узкий термин, определяющий выполняемую
приложением роль.
> Возможно он идеально подходит для systemd, но я бы не стал называть
большинство веб-приложений сервисами.
Я абсолютно согласен с этим определением.
Но хочу обратить внимание что основная цель Systemd в то
> Как по вашему, firefox - это сервис или приложение? Можете обосновать
> почему?
Я же не ради холивара это писал :)
Клиентские GUI приложения сервисами сложно назвать, но для меня:
PHP-FPM - это сервис
Node.js - это сервис
Python WSGI - это сервис
Go Server - это сервис
Возможно у меня systemd
Всех с наступающим НГ.
Много раз себя ловил на мысли когда смотрел на JSON конфиг Unit, почему вы
решили сервисы называть application?
Я понимаю что NGINX Unit - это Application Server, но уже устоялись такие
понятия как microservice, которые часто настраиваются как отдельные Unit для
systemd.ser
> С точки зрения практики - паттерн "daemon(); write_pidfile();"
> используется чуть менее, чем везде, вплоть до соответствующих
> библиотечных функций. Так что инициатива выглядит, скажем так,
> сомнительной.
>
> Проще всего, IMHO, это было бы заткнуть на уровне systemd,
> дожидаясь появлени
> Возможно. Я отправил его коллегам на review, если возражений не
> будет - закоммичу.
Спасибо!
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,276955,277433#msg-277433
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org
Maxim Dounin Wrote:
---
> Патч ниже по первой ошибке преаллокации пытается предполагать, что
> мы работаем с jtk zlib, и работает соответственно. Если и это не
> помогло - тогда уже начинает писать в лог alert'ы.
Сработало, спасибо!
В логе соо
Maxim Dounin Wrote:
---
> Я, впрочем, подозреваю, что на самом деле там не это, а то, что
> лежит по адресу https://github.com/jtkukunas/zlib. Название и
> содержимое пакета как бы намекает:
>
> https://download.clearlinux.org/current/source/S
> Есть смысл разобраться, что у вас используется вместо zlib,
Из коробки в ОС установлена пропатченная Intel библиотека zlib
https://software.intel.com/en-us/articles/how-to-use-zlib-with-intel-ipp-opertimization
Вот что у нас выдает ldd
ldd /usr/lib64/libz.so
linux-vdso.so.1 (0x7ffe
Есть смысл мне писать в bug report, по этой проблеме, или шансы на
исправление близки к нулю?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,276955,277266#msg-277266
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mail
Я уже подымал эту тему на Github
https://github.com/nginx/unit/issues/6
Будет хорошо создать здесь отдельные maillist для Unit.
Я согласен с теми кто считает что Unit сложно будет конкурировать с
PHP-FPM.
1. Простота в настройке и запуске разных версий РНР - это совсем не сложно,
есть пакеты Rem
Здравствуйте.
Мы начали использовать OS ClearLinux for Intel® Architecture, (отличная
производительность)
Все работает хорошо, но в логах Nginx мы постоянно видим
[alert] 31591#31591: *1 gzip filter failed to use preallocated memory: 65536
of 16368
Таких записей очень много, не смотря на их уров
> > Для Fedora 25-26 (Open SSL 1.1) будет сборка?
> Таких планов нет, т.к. популярность этих дистрибутивов на сервере,
> кажется, невелика.
Да, Fedora не популярна в продакшине, у неё своя ниша, она хорошо для тестов
будущих версий RHEL.
Уже вышла RedHat 7.4 у неё openssl 1.0.2k, скоро выйдет Cen
Для Fedora 25-26 (Open SSL 1.1) будет сборка?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,275648,275652#msg-275652
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
> В таком виде, конечно, не закоммитят. Я тут нагло воспользовался
> существованием внутреннего флага, который по факту используется для
> webdav-модуля, и "вытащил" его в конфигурацию, потому патч и такой
> простой. Если уж делать по-человечески - то делать нормальную
> конфигурацию по аналогии с
> Т.е. директиву client_body_in_file_only и переменную
> $request_body_file добавили, а
> прав на файлы - добавить забыли.
Да, в интернете многие задаются вопросом почему сделано это так, похоже что
просто забыли учитывать client_body_in_file_only.
Posted at Nginx Forum:
https://forum.nginx.org/
Я уточню чтобы меня понимали.
Мы используем директиву - client_body_in_file_only clean; для получения
файлов от клиента при аплодинге, указываем директорию в директиве
client_body_temp_path, все работает хорошо, только пермишены файлов в этой
папке 0600.
Posted at Nginx Forum:
https://forum.ngin
> Это временный файл процесса nginx, и, насколько я понимаю, никакая
> обработка в
> других процессах не предусматривается. В силу этого же права
> выставлены в 0600 и
> другого быть не может.
Временный файлы процесса Nginx, создаются без директивы
client_body_temp_path.
Вот директива client_body
Konstantin Baryshnikov Wrote:
---
> >
> > On May 31, 2017, at 12:35 AM, S.A.N
> wrote:
> >
> > Я конечно извиняюсь, за настойчивость, но неужели пермишен 0600, на
> файл
> > который должен быть обработан в
Я конечно извиняюсь, за настойчивость, но неужели пермишен 0600, на файл
который должен быть обработан в другом процессе, это нормально и это никак
нельзя настроить в конфиге Nginx?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,274059,274538#msg-274538
__
> В первом сообщении указана ссылка на php-скрипт, где и используется
> x-accel-redirect. Задача: сделать, чтобы nginx, приняв url, ещё и
> переходил по редиректам, а не завершал обработку при получении первого
> редиректа.
Nginx, браузеру заголовок X-Accel-Redirect никогда не отдает, т.е. браузер
> В идеале - хотелось бы решения чисто на nginx.
x-accel-redirect
https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/#x-accel-redirect
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,274346,274349#msg-274349
___
nginx-ru mai
Офтоп - мы делаем по другому, части контента загружаем аяксом на клиенте и
строим страницу на клиенте, есть и сервер рендер, который по сути является
агрегатором, РНР делает НТТР запросы к другим РНР скриптам, те отдают JSON,
и собираем страницу на сервере и отдаем готовый НТМЛ, в плане кеширование
> Но это требует rewrite директив, в конфиге Nginx, мне это не очень
> нравится.
Можно без rewrite директив, просто alias
location ~ ^/[0-9]+/(.+)$
{
alias /var/www/dir/$1;
}
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,272099,274108#msg-274108
___
Дмитрий Герасимов Wrote:
---
> Вообщем всем спасибо. Сегодня узнал о существовании incron (век живи,
> век учись), при помощи онного и решил проблему
Есть аналог API в systemd
https://www.freedesktop.org/software/systemd/man/systemd.path.html
Po
Здравствуйте.
Сейчас файлы создаются с правами 0600 нужно хотя бы 0660, в документации
нашел только настройку прав для store
proxy_store_access user:rw group:rw all:r;
Есть аналогичная настройка для client_body_temp_path?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,274059,274059#
Возможно по этой же причине Nginx иногда не удалял файлы, по директиве
client_body_in_file_only clean;
client_body_temp_path - на локал файл системе
Наверно, в момент получения QUIT сигнала, процес Nginx завершался и файлы не
удалялись.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21
Maxim Dounin Wrote:
> Но в целом идея, что для остановки nginx'а системными скриптами
> надо использовать QUIT - она, скажем так, странная.
Да, странно зачем в дистрибутиве от Nginx, в файле nginx.service указан QUIT
сигнал
ExecStop=/bin/kill -s QUIT $MAINPID
Если удалить эту строчку, Systemd п
Может я что-то не так делаю, в конфиге указываю:
server
{
listen unix:/var/run/www/test.sock;
}
Nginx создает файл сокета при старте, но после перезагрузки systemctl
restart nginx, файл не удаляется и Nginx не может к нему забиндится, в логе
выдает ошибку
[emerg] bind() to unix:/var
Проще всего сделать как в Amazon CloudFront, если бекенд отдал
Cache-Control: max-age=0, кешировать эти ответы, если в заголовках ответа
есть валидаторы ETag или Last-Modified.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,273298,273299#msg-273299
___
Здравствуйте.
Я уже когда-то писал, что некоторые запросы бекенды должны всегда
ревалидировать, в спецификации это документировано в трех параметрах
заголовка Cache-Control.
max-age=0 - кешировать если есть валидатор (ETag или Last-Modified)
no-cache - не использовать кеш без ревалидации
must-rev
> 2) и что, всю толпу заголовков перечислять в ignore, если вдруг
> хочется чтобы
> всё происходило ровно так, как описано в конфиге? :)
Нет, достаточно указать ignore Cache-Control и бекенд не сможет рулить
кешированием, но вообще заголовки от бекенда, появляются не от сырости, их
там разработчи
> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_b
> ackground_update
> http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_b
> ackground_update
Да, спасибо.
Почему значения директивы proxy_cache_use_stale более приоритетно чем
заголовок stale-while-revalidat
За поддержку заголовков stale-* отдельное спасибо.
Когда появится в документации описания новой директивы -
proxy_cache_background_update?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,272411,272413#msg-272413
___
nginx-ru mailing list
ngi
Илья Шипицин Wrote:
---
> 13 февраля 2017 г., 18:01 пользователь S.A.N
>
> написал:
>
> > Здравствуйте.
> >
> > Есть потребность в реализации вот такого поведения:
> >
>
>
> а если у вас несколь
Здравствуйте.
Есть потребность в реализации вот такого поведения:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html
Some HTTP methods MUST cause a cache to invalidate an entity. This is either
the entity referred to by the Request-URI, or by the Location or
Content-Location headers (if pre
> К сожалению, это все равно не панацея
> Firefox почему-то смотрит на этот параметр только для https
> соединений, а для якобы устаревших http игнорирует его.. Хотя казалось
> бы зачем это вообще разделять...
У вас юзера часто руками обновляют страницу, или это делает js, если js,
тогда вместо lo
> Да, поставь ты expires и max-age хоть на сто лет вперед, любое F5 у
> Firefox вызовет запрос на сервер. Да, в ответ пойдет 304, но сам
> запрос то никак не отменить (кроме как этим флагом)
Да, я уже понял и написал ниже: +1 за Cache-Control: immutable
На сегодня immutable реализован только в Fi
> вот тут подробности:
>
> http://www.opennet.ru/opennews/art.shtml?num=45934
> 27.01.2017 23:49 Firefox и Chrome провели работу по увеличению
> скорости
> повторной загрузки страниц
Спасибо, да метод POST и поведение кнопки "перезагрузить страницу", вызывает
условный запрос.
+1, за Cache-Contr
Почитал спеку, но так и не понял, что нового дает immutable, если установить
expires max, клиент раз в год будет делать условный запрос, если установить
immutable, клиент никогда не будет делать условных запросов, т.е. это все
ради того чтобы клиент не делал запрос раз в год?
Posted at Nginx Forum
Anton Bessonov Wrote:
---
> А что, если перенести это на уровень бильд-процесса? Успешно использую
> с
> мэйвеном (подсчёт версии, копирование файлов в /static/${number} и
> замена переменных в ресурсаx), вэбджар и ocLazyLoad.
>
> На уровне энд
Здравствуйте.
Для статичных файлов, есть старая добрая практика, добавлять в url, некий
номер версии этого файла, клиентам отдавать в заготовках максимальное время
кеширования, как-то так:
expires max;
Одно из достоинств HTTP 2, там Nginx (пока что) не добавляет заголовок
Connection: keep-alive.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,245378,271652#msg-271652
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mai
> GEOIP-* - обязательно. remote_user особо не важен.
Дело в том, что $remote_user не может открыть соединения по локальному
unix-сокету из другого города или страны.
У вас наверно есть внешний прокси для этого, если да, тогда все эти
параметры должен передать внешний прокси (например в НТТР заголо
> Что, впрочем, не мешает автору треда взять прокси-модуль, немного
> изменить код
> и радоваться жизни :)
Нет, все таки придется юзать proxy_cache :)
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,271460,271464#msg-271464
___
nginx-ru ma
Здравствуйте.
Есть ли возможность в proxy_store сохранять не только тело ответа, но и все
НТТР заговоки?
Для нашей задачи proxy_store подходит на 99%, не хватает только сохранения
заголовков, использовать proxy_cache нельзя, потому что нам нужно чтобы
имена кеш файлов соответствовали uri, это нуж
Nginx, таким образом, за Сloudflare.
> И если обращаться к серверу напрямую по имени domain.ltd, то кэш
> успешно создается. Если же обычным путем (через Cloudflare), то при
> обращении именно на определенный домен кэш не создается. С чем это
> может быть связано?
Возможно Cloudflare не отправляет
> Потому что PrivateTmp=true, процес бекенда как правило работает под
> другим юзером и получить доступ к временной папке процесса Nginx
> сможет.
Конечно, НЕ сможет, получить доступ к файлу, моя опечатка )
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,270488,270531#msg-270531
Мне ещё не нравится, из официального репозитория, вот эта директива:
[Service]
PrivateTmp=true
Огромный подводный камень, например вот это из коробки работать не будет
client_body_temp_path /tmp/;
client_body_in_file_only on;
Потому что PrivateTmp=true, процес бекенда как правило работает под д
Kira_Belka Wrote:
---
> чем тогда является данный текст?!
> Он не является ни заголовком ни каким либо параметром передаваемым в
> POST/GET
>
> там первая строчка с посыпавшейся кодировкой и это не кажется
> валидным.
> ??Wo
> KEY:
>
Проявилась одна фича (или баг?)
В официальном Nginx репозитории для CentOS 7, в Systemd юните -
nginx.services, указанна директива PrivateTmp = yes
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp=
Если в конфиге Nginx, указать
client_body_temp_path/tmp;
proxy_se
Maxim Dounin Wrote:
---
> Самбу/NFS? Боюсь, что если так, то на этом
> пути вас ждёт множество неприятных открытий.
>
Да, вы правы, на dev сервере Самба/NFS, проблема именно в этом.
Спасибо!
Posted at Nginx Forum:
https://forum.nginx.org/rea
Ещё вопросы по временным файлам
1. Если клиент закрыл соединения до отправки всего тела запроса, временный
файл остается в папке, Nginx этот файл не удаляет, запрос на бекенд
отправлен не будет. Я так понимаю подразумевалось что ОС должна чистить
папку temp, но может лучше чтобы Nginx сам за собой
client_body_in_file_only - работает отлично :)
Но нам нужно провести аутентификацию юзера перед тем как Nginx прочитает все
тело клиентского запроса и сохранит его в файл.
Я знаю про ngx_http_auth_request_module, но это отдельный запрос на бекенд,
хотелось бы сделать проще.
Вот как - Nginx отправ
> tcp_nodelay и tcp_nopush включал - эффекта никакого. Может это быть
> из-за
> айпитеблсов? Из-за какогонибудь коннтрека или еще чего
Если есть возможность, попробуйте перейти на локальные UNIX сокеты.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,268323,268343#msg-268343
> Я не понимаю что мы выигрываем от принятия сразу нескольких
> соединений за одну итерацию event loop'а.
Я в таких случаях провожу нагрузочные эксперименты, чтобы понять что мы
выигрываем, в данном случаи разница будет на уровне погрешности, но возможно
вам стоит попробовать чтобы знать точно.
P
> > 1 запрос выполняется за 100ms
> >
> > Если послать 30 последовательных запросов в 1 соединение мы получим
> 30
> > ответов за 3000ms
> > Если послать 30 запросов в 30 разных соединениях мы получим 30
> ответов за
> > 100ms
> > Если послать 30 асинхронных запросов в 1 соединение мы получим 3
> Хэндлер должен быть один для всех однотипных операций
Да, это детали конкретной реализации, там нужно контекст передать, по этому
создается новый интсанст хендлера.
Если перечислять все кроме WatcherObject и HandlerMethod, тогда нужно
начинать с того что accept socket создает новый fd в процессе
> Можете расшифровать выражение "сокет не простаивал в пустую"? Чем
> грозит
> сокет, который простаивает впустую? Что по вашему такой сокет
> потребляет:
> ресурсы процессора, электричество, солярку, деньги?
Сокет который простаивает в пустую (ждет ответа на запрос) потребляет память
приложения
> Везде SSL. Сейчас с SPDY (еще пока используем nginx-1.8.1). Возможно
> SPDY\http2
> лишний и стоит его отключить везде, кроме связки клиент->эдж?
Для видеостриминга, лучше использовать много соединений, HTPP/1.1 хорошо
подходит и ничего более ненужно.
Мультиплексирования, полезно там где межд
> Если я правильно понял этот набор слов, предлагается вместо кэша
> nginx
> использовать кэш memcached'а, почему эта связка должна быть
> эффективнее
> чем один кэш nginx'a?
Нет, будет использоваться только кеш Nginx, но бекенды получат возможность
получать по ключу, тело (body) кеша Nginx, по
> Возможно, эффективным решением для соединения бэкэндов было бы
> фиксированное количество соединений, бесконечный keepalive и
> pipelining
Да, мы сделали свой pool keepalive сокетов, это действительно помогает.
pipelining мы хотели сделать, но Nginx его не поддерживает, мы гоняем
запросы между б
> Если сокет "простаивает без трафика", то железо отнюдь не простаивает,
> а выполняет работу по тем сокетам, которые не простаивают.
>
> К тому же при однородной нагрузке количество требуемых содинений с
> бэкэндами должно быть стабильно во времени
Если 30 запросов отправить в 30 разных соединен
> Интересно, сколько нужно открыть fd чтобы ощутить их дефицит в
> системе?
Это зависит от установленого лимита в ОС, по умолчанию 1024, я кстати всегда
хотел узнать, зачем линукс по умолчанию ставит такой низкий лимит?
> Если у клиента такая логика, что он делает 30 запросов json
> одновремен
Илья Шипицин Wrote:
---
> а как вы понимаете, простаивают они или нет ?
Очень просто, мы на бекенде замеряли сколько соединений открывает Nginx,
днем 200-300, ночью намного меньше, мы установили 250, по таймауту
закрываются лишние.
Кстати когда
> > Кстати почему по дефолту keepalive_requests имеет такое маленькое
> значения -
> > 100?
>
> Это опция относится только к клиентскому соединению.
Наши бекенды открывают клиентские соединения к другим нашим бекендам, по
этому пришлось значительно увеличить keepalive_requests.
Я хотел узнать, е
> зачем огромные ?
>
> значение keepalive - это "запас", соединения, которые держатся
> подгретыми
> на всякий случай.
> если у вас нагрузка носит однородный характер, то они будут
> простаивать
У нас 250 keepalive на upstream, начинали с 8, потом имперически
увеличивали, обычно они не простаиваю
Илья Шипицин Wrote:
---
> а вы настройте keepalive между nginx и бекендами.
Да, этим и спасаемся, у нас огромные значения keepalive в upstream :)
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,266693,267180#msg-267180
_
> Конечно, мультиплексирование в FastCGI будет легче чем в HTTP/2.
>
> Но само по себе мультиплексирование не является самоцелью, оно может
> быть уместно в каких-то вычурных ситуациях (вроде исчерпания
> сокетов),
> которые на самом деле разруливаются другими методами.
Подскажите где почитат
> Если необходимо вытащить множество разных данных одним запросом, то
> для
> этого есть SSI. Причем разные части будут доставаться параллельно и
> складываться в один большой ответ достаточно эффективно.
SSI здесь не поможет, нам надо чтобы бекенд получил данные из другого
бекенда, обработал их
Валентин Бартенев Wrote:
> Какой браузер отправляет в одном HTTP/1.1 соединении следующий запрос
> не
> дожидаясь ответа на предыдущий?
Вы правы, я наконец то понял, браузеры отправляют в одном соединении запросы
последовательно, всегда дожидаясь ответа на предыдущий, т.е. очередь
запросов в соеди
> >
> > Даже в РНР появляются новые асинхронные фрейворки, не говоря уже про
> > Node.js, Go, etc..
> > Возможно уже пришло время, переосмыслить и переписать логику работы
> upstream
> > в Nginx?
> > Тогда асинхронные бекенды смогут эффективней работать.
> >
>
> Асинхронный nginx прекрасно работ
> Всё верно, потому что запросы в одном соединении по протоколу HTTP/1.1
> обрабатываются последовательно.
>
> Если вы хотите сделать три параллельных запроса в HTTP/1.1, то для
> этого
> нужно отрыть 3 соединения и в каждом делать по запросу.
В этом то и проблема, браузеры на НТТР/1.1 часто экон
> > Nginx никогда не посылает запрос в то же соединение, пока не
> получит
> > ответ
> > и соединение освободиться. Т.н. pipelining он не умеет и не
> > использует.
> >
> > Если бы следующий запрос пришел до того, как на первый был получен
> > ответ,
> > то он бы был отправлен на бекенд в другом
> Nginx никогда не посылает запрос в то же соединение, пока не получит
> ответ
> и соединение освободиться. Т.н. pipelining он не умеет и не
> использует.
>
> Если бы следующий запрос пришел до того, как на первый был получен
> ответ,
> то он бы был отправлен на бекенд в другом соединении.
>
> Т
> Вы просто перенесете то, что реализовано в ядре операционной системы
> внутрь приложения. В случае HTTP/2 у вас будет на каждый отдельный
> запрос свой внутренний идентификатор со своими накладными расходами,
> который точно также будет "простаивать" пока запрос обрабатывается.
>
> У вас уже ес
Результаты 1 - 100 из 288 matches
Mail list logo
