Возможно у вас в 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
> В крайнем случае несложно пометить клиента стандартным способом через
> 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:
> Есть сервис Pusher, который позволяет раздавать потоки по WebSocket.
> Никакой инфраструктуры не нужно. Подозреваю там есть прямые и обратные
Так мы тоже самое получаем безплатно и без сторонних сервисов, простой
надстройкой nchan + uWebSockets.js
Posted at Nginx Forum:
> Что мешает реализовать данную функциональность в приложении?
> Например, используя тот же упомянутый uWebSockets.js?
Нам мешают те же причины что у вас, бизнесу выгодно чтобы мы писали больше
бизнес логики и меньше писали инфрастуктурного кода.
Да, можно сделать распределеную систему на Pub/Sub
> кеше битые обрезанные файлы, при использовании на бэкенде gzip, тот же
> баг
Попробуйте выключить настройку в конфигt Nginx
sendfile off;
Нам это помогло.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,285250,285255#msg-285255
___
> Пока не планируем.
Ясно, но тогда вот что выходит, тем кому нужен 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:
Возможно я не нашел, но в данной версии нет возможности broadcast каналов?
Когда одно сообщения передается множеству WebSocket клиентов и как одного
клиента подписать на множество каналов?
Этого нет в текущей версии или вы не планируете этого делать и данный
функционал нужно будет писать самому на
В вашей дорожней карте, для ветки 1,17 есть в планах имплементация QUIC
(HTTP/3), какие ваши оценки по времени это будет готово в этом году.
И если не сложно скажите как вам QUIC там реально много профита для мобил
клиентов, у нас очень много мобил HTTP клиентов и нам эта тема очень
интересна.
> Тем временем, мы продолжаем трудиться над поддержкой WebSocket для
> модулей
> Node.js и Java. Все почти готово; шансы на то, что это войдет в
> следующий
> выпуск - очень велики.
Возможно уже есть документация и открытое бета тестирования для Node.js?
> Напоминаю, что мы непрерывно находимся
> RFC 8441, Но
> это, скажем так, выглядит как хак, при этом малосовместимый с
> существующей логикой работы через Upgrade, и имеет мало шансов
> быть поддержанным.)
Есть реализация (клиент и сервер)
https://github.com/warmcat/libwebsockets
В Chrome тоже давно работает.
> Я не слежу за разработкой 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:
> 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 для
> С точки зрения практики - паттерн "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
Maxim Dounin Wrote:
---
> Патч ниже по первой ошибке преаллокации пытается предполагать, что
> мы работаем с jtk zlib, и работает соответственно. Если и это не
> помогло - тогда уже начинает писать в лог alert'ы.
Сработало, спасибо!
В логе
Maxim Dounin Wrote:
---
> Я, впрочем, подозреваю, что на самом деле там не это, а то, что
> лежит по адресу https://github.com/jtkukunas/zlib. Название и
> содержимое пакета как бы намекает:
>
>
> Есть смысл разобраться, что у вас используется вместо 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
Есть смысл мне писать в 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
Я уже подымал эту тему на Github
https://github.com/nginx/unit/issues/6
Будет хорошо создать здесь отдельные maillist для Unit.
Я согласен с теми кто считает что Unit сложно будет конкурировать с
PHP-FPM.
1. Простота в настройке и запуске разных версий РНР - это совсем не сложно,
есть пакеты
Здравствуйте.
Мы начали использовать 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, скоро выйдет
Для 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
I advise you implementing - direct file upload.
Read more:
https://stackoverflow.com/questions/44371643/nginx-php-failing-with-large-file-uploads-over-6-gb/44751210#44751210
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,275567,275602#msg-275602
> В таком виде, конечно, не закоммитят. Я тут нагло воспользовался
> существованием внутреннего флага, который по факту используется для
> webdav-модуля, и "вытащил" его в конфигурацию, потому патч и такой
> простой. Если уж делать по-человечески - то делать нормальную
> конфигурацию по аналогии с
> Т.е. директиву client_body_in_file_only и переменную
> $request_body_file добавили, а
> прав на файлы - добавить забыли.
Да, в интернете многие задаются вопросом почему сделано это так, похоже что
просто забыли учитывать client_body_in_file_only.
Posted at Nginx Forum:
Я уточню чтобы меня понимали.
Мы используем директиву - client_body_in_file_only clean; для получения
файлов от клиента при аплодинге, указываем директорию в директиве
client_body_temp_path, все работает хорошо, только пермишены файлов в этой
папке 0600.
Posted at Nginx Forum:
> Это временный файл процесса nginx, и, насколько я понимаю, никакая
> обработка в
> других процессах не предусматривается. В силу этого же права
> выставлены в 0600 и
> другого быть не может.
Временный файлы процесса Nginx, создаются без директивы
client_body_temp_path.
Вот директива
Konstantin Baryshnikov Wrote:
---
> >
> > On May 31, 2017, at 12:35 AM, S.A.N <nginx-fo...@forum.nginx.org>
> 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
Офтоп - мы делаем по другому, части контента загружаем аяксом на клиенте и
строим страницу на клиенте, есть и сервер рендер, который по сути является
агрегатором, РНР делает НТТР запросы к другим РНР скриптам, те отдают 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
Michael Salmon Wrote:
---
> I started testing using a Unix domain socket so that I could a way to
> send a message when my site was down for maintenance but I ran into a
> problem. When I restarted nginx it complained that the sockets already
>
Дмитрий Герасимов Wrote:
---
> Вообщем всем спасибо. Сегодня узнал о существовании incron (век живи,
> век учись), при помощи онного и решил проблему
Есть аналог API в systemd
https://www.freedesktop.org/software/systemd/man/systemd.path.html
Здравствуйте.
Сейчас файлы создаются с правами 0600 нужно хотя бы 0660, в документации
нашел только настройку прав для store
proxy_store_access user:rw group:rw all:r;
Есть аналогичная настройка для client_body_temp_path?
Posted at Nginx Forum:
Возможно по этой же причине Nginx иногда не удалял файлы, по директиве
client_body_in_file_only clean;
client_body_temp_path - на локал файл системе
Наверно, в момент получения QUIT сигнала, процес Nginx завершался и файлы не
удалялись.
Posted at Nginx Forum:
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
Проще всего сделать как в 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 - не использовать кеш без ревалидации
> 2) и что, всю толпу заголовков перечислять в ignore, если вдруг
> хочется чтобы
> всё происходило ровно так, как описано в конфиге? :)
Нет, достаточно указать ignore Cache-Control и бекенд не сможет рулить
кешированием, но вообще заголовки от бекенда, появляются не от сырости, их
там
За поддержку заголовков stale-* отдельное спасибо.
Когда появится в документации описания новой директивы -
proxy_cache_background_update?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,272411,272413#msg-272413
___
nginx-ru mailing list
Илья Шипицин Wrote:
---
> 13 февраля 2017 г., 18:01 пользователь S.A.N
> <nginx-fo...@forum.nginx.org>
> написал:
>
> > Здравствуйте.
> >
> > Есть потребность в реализации вот такого поведения:
> >
Здравствуйте.
Есть потребность в реализации вот такого поведения:
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
> К сожалению, это все равно не панацея
> Firefox почему-то смотрит на этот параметр только для https
> соединений, а для якобы устаревших http игнорирует его.. Хотя казалось
> бы зачем это вообще разделять...
У вас юзера часто руками обновляют страницу, или это делает js, если js,
тогда вместо
> Да, поставь ты expires и max-age хоть на сто лет вперед, любое F5 у
> Firefox вызовет запрос на сервер. Да, в ответ пойдет 304, но сам
> запрос то никак не отменить (кроме как этим флагом)
Да, я уже понял и написал ниже: +1 за Cache-Control: immutable
На сегодня immutable реализован только в
> вот тут подробности:
>
> http://www.opennet.ru/opennews/art.shtml?num=45934
> 27.01.2017 23:49 Firefox и Chrome провели работу по увеличению
> скорости
> повторной загрузки страниц
Спасибо, да метод POST и поведение кнопки "перезагрузить страницу", вызывает
условный запрос.
+1, за
Почитал спеку, но так и не понял, что нового дает immutable, если установить
expires max, клиент раз в год будет делать условный запрос, если установить
immutable, клиент никогда не будет делать условных запросов, т.е. это все
ради того чтобы клиент не делал запрос раз в год?
Posted at Nginx
Anton Bessonov Wrote:
---
> А что, если перенести это на уровень бильд-процесса? Успешно использую
> с
> мэйвеном (подсчёт версии, копирование файлов в /static/${number} и
> замена переменных в ресурсаx), вэбджар и ocLazyLoad.
>
> На уровне
Одно из достоинств 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
> 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
Здравствуйте.
Есть ли возможность в proxy_store сохранять не только тело ответа, но и все
НТТР заговоки?
Для нашей задачи proxy_store подходит на 99%, не хватает только сохранения
заголовков, использовать proxy_cache нельзя, потому что нам нужно чтобы
имена кеш файлов соответствовали uri, это
Nginx, таким образом, за Сloudflare.
> И если обращаться к серверу напрямую по имени domain.ltd, то кэш
> успешно создается. Если же обычным путем (через Cloudflare), то при
> обращении именно на определенный домен кэш не создается. С чем это
> может быть связано?
Возможно Cloudflare не
Мне ещё не нравится, из официального репозитория, вот эта директива:
[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;
Maxim Dounin Wrote:
---
> Самбу/NFS? Боюсь, что если так, то на этом
> пути вас ждёт множество неприятных открытий.
>
Да, вы правы, на dev сервере Самба/NFS, проблема именно в этом.
Спасибо!
Posted at Nginx Forum:
Ещё вопросы по временным файлам
1. Если клиент закрыл соединения до отправки всего тела запроса, временный
файл остается в папке, Nginx этот файл не удаляет, запрос на бекенд
отправлен не будет. Я так понимаю подразумевалось что ОС должна чистить
папку temp, но может лучше чтобы Nginx сам за
> tcp_nodelay и tcp_nopush включал - эффекта никакого. Может это быть
> из-за
> айпитеблсов? Из-за какогонибудь коннтрека или еще чего
Если есть возможность, попробуйте перейти на локальные UNIX сокеты.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,268323,268343#msg-268343
> Я не понимаю что мы выигрываем от принятия сразу нескольких
> соединений за одну итерацию event loop'а.
Я в таких случаях провожу нагрузочные эксперименты, чтобы понять что мы
выигрываем, в данном случаи разница будет на уровне погрешности, но возможно
вам стоит попробовать чтобы знать точно.
> Можете расшифровать выражение "сокет не простаивал в пустую"? Чем
> грозит
> сокет, который простаивает впустую? Что по вашему такой сокет
> потребляет:
> ресурсы процессора, электричество, солярку, деньги?
Сокет который простаивает в пустую (ждет ответа на запрос) потребляет память
> Везде SSL. Сейчас с SPDY (еще пока используем nginx-1.8.1). Возможно
> SPDY\http2
> лишний и стоит его отключить везде, кроме связки клиент->эдж?
Для видеостриминга, лучше использовать много соединений, HTPP/1.1 хорошо
подходит и ничего более ненужно.
Мультиплексирования, полезно там где
> Возможно, эффективным решением для соединения бэкэндов было бы
> фиксированное количество соединений, бесконечный 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.
>
> Но само по себе мультиплексирование не является самоцелью, оно может
> быть уместно в каких-то вычурных ситуациях (вроде исчерпания
> сокетов),
> которые на самом деле разруливаются другими методами.
Подскажите где
> > Nginx никогда не посылает запрос в то же соединение, пока не
> получит
> > ответ
> > и соединение освободиться. Т.н. pipelining он не умеет и не
> > использует.
> >
> > Если бы следующий запрос пришел до того, как на первый был получен
> > ответ,
> > то он бы был отправлен на бекенд в другом
> Вы просто перенесете то, что реализовано в ядре операционной системы
> внутрь приложения. В случае HTTP/2 у вас будет на каждый отдельный
> запрос свой внутренний идентификатор со своими накладными расходами,
> который точно также будет "простаивать" пока запрос обрабатывается.
>
> У вас уже
> Откуда такая арифметика?
Цифры условные - допустим многопоточный бекенд, имеет 10 потоков, каждый
поток может работать со скоростью 1к RPS.
Задача получить от одного бекенда 10к RPS
На НТТР1.1 нужно как минимум открыть 10 конектов, тогда бекенду очень просто
привязать каждый конект к своему
> Также как и h2 внутри датацентра не нужен. Это протокол заточенный
> под общение
> браузера с веб-сервером ради экономии на TLS-хэндшейках по сетям с
> относительно
> высокой задержкой и в условиях крайне ограниченного количества
> параллельных
> соединений.
>
> Не стоит забивать микроскопы
Наш бекенд работает на HTTP/1.1 в режиме Keep-Alive, но в пикоквые нагрузки,
нам приходится держать много открытых конектов.
Демон асинхронный, но если один запрос выполняется дольше обычного конект
параллельно использовать для других запросов уже не выйдет он просто ждет,
хотелось бы попробовать
VovansystemS Wrote:
---
> >> fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match
> if_not_empty;
> >> fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since
> if_not_empty;
> >
> > У вас в конфиге написано: установить заголовки
Судя по конфигу, у вас проблема с куками, если браузер присылает куки
сессии, кеш не работает, curl куки не присылает, ответ отдается из кеша.
Убери из конфига
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since
Здравствуйте.
Мы все больше используем микросервисы, они имеют уникальные uri, выполняют
атомарные операции и отдают JSON ответы, их проксирует и кеширует Nginx.
В этих бекенд микросервисах, часто появляются задачи для решения которых
нужны ответы от других бекенд микросервисов, приходится
Maxim Dounin Wrote:
---
> Hello!
>
> On Tue, Apr 19, 2016 at 03:24:37AM -0400, S.A.N wrote:
>
> > > По умолчанию range-запросы из кеша работают только в том случае,
> > > если в ответе бекенда был заголов
> По умолчанию range-запросы из кеша работают только в том случае,
> если в ответе бекенда был заголовок Accept-Ranges и должна быть
> явно указана длина ответа.
Супер, спасибо, отдали Accept-Ranges все работает.
Кстати есть ли смысл бекенду сжимать (gzip) свой ответ, если клиенты
запрашивают
Здравствуйте.
Я хотел бы узнать, Nginx умеет отдавать клиентам из своего кеша, ответы
частями?
Корректный заголовок Range: bytes... клиент отправляет, но Nginx из кеша
отдает весь ответ статус - 200, вместо частичного ответа со статусом 206.
По сути нужен функционал обратный модулю Slice.
Наш
> И более правильным, потому что независимо от чей-то любви к
> systemd.socket
> в данном случае он поставленную задачу НЕ решает. Всяко лучше
> устранить
> проблему полностью, чем уменьшить её вероятность на несколько
> процентов.
systemd.socket задачу решает, тесты показали что он заметно
Валентин Бартенев Wrote:
---
> Это довольно странное желание - чтобы машина, которая по сути ещё не
> готова
> к работе, частично делала вид, что она готова принимать трафик. Что
> вы будете
> делать если nginx так и не заработает через 700 мс,
1 - 100 of 237 matches
Mail list logo
