Re: Релиз Unit 1.10.0

2019-08-26 Пенетрантность S.A.N
> Единственный правильный способ тестирования - тестирование на реальных
> нагрузках со своими собственными приложениями и задачами.

Согласен, но это делают потом, на ранней стадии тестят синтетикой, просто
чтобы примерно оценить оверхед, когда они увидят 6х замедления, это может
отбить желания тестить реально.
Меня смутил такой большой оверхед, я потом вместо Unit поставил Nginx,
получил результат в ~2x лучше по сравнению с Unit.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285390,285404#msg-285404

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Релиз Unit 1.10.0

2019-08-25 Пенетрантность S.A.N
Сделал простой бенчмарк (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: 112328

Я это пишу не ради тролинга и понимаю что тесты Hello World мало что
говорят, но не нашел ваших сравнительных тестов с конкурентами.
Но ваши конкуренты тесты проводят и делают себе релкаму:
https://github.com/uNetworking/uWebSockets/tree/master/benchmarks
Я думаю вам нужно проф тесты провести и выложить результаты.

Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285390,285400#msg-285400

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Релиз Unit 1.9.0

2019-08-13 Пенетрантность S.A.N
> Есть сервис Pusher, который позволяет раздавать потоки по WebSocket. 
> Никакой инфраструктуры не нужно. Подозреваю там есть прямые и обратные

Так мы тоже самое получаем безплатно и без сторонних сервисов, простой
надстройкой nchan + uWebSockets.js

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284362,285260#msg-285260

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Релиз Unit 1.9.0

2019-08-13 Пенетрантность S.A.N
> Что мешает реализовать данную функциональность в приложении?
> Например, используя тот же упомянутый uWebSockets.js?

Нам мешают те же причины что у вас, бизнесу выгодно чтобы мы писали больше
бизнес логики и меньше писали инфрастуктурного кода.
Да, можно сделать распределеную систему на Pub/Sub от Redis и uWebSockets.js
будет раздавать клиентам сообщения, но это медленей и в лучшем случаи мы
сделаем тоже что уже написано в nchan.
 
> Дело в том, что задача достаточно узкоспециализированная

Не уверен, из своего опыта даже сложно вспомнить какие задачи помещались в
рамки связи один к одному, обычно один ко многим.
Даже если у нас один сервер, у него будет множество процессов, два клиента
WebSocket законектися к разным процессам, вот уже связь один ко многим.

Киллер фича Unit, которой нет в nchan, заключается в том что Unit знает про
все application и умеет с ними общатся без сети, это большой потенциал, я бы
очень хотел чтобы мои процессы внутри сервера могли общатся через Unit без
сети.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284362,285258#msg-285258

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Битые файлы в кеше при gzip ответах

2019-08-13 Пенетрантность S.A.N
> кеше битые обрезанные файлы, при использовании на бэкенде gzip, тот же
> баг

Попробуйте выключить настройку в конфигt Nginx
sendfile off;
Нам это помогло.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285250,285255#msg-285255

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Релиз Unit 1.9.0

2019-08-13 Пенетрантность S.A.N
> Пока не планируем.

Ясно, но тогда вот что выходит, тем кому нужен WebSocket, как правило нужен
broadcast и возможностость подписать одного клиента к множеству каналов.
Эти задачи уже успешно решены в nchan (модуль Nginx) и для Node.js есть
uWebSockets.js (сишный модуль) к сожалению это означает что Unit в этом
стеке технологий не нужен.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284362,285254#msg-285254

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx-1.17.3

2019-08-13 Пенетрантность S.A.N
> для мобильных клиентов есть (уже)  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?21,285238,285251#msg-285251

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Релиз Unit 1.9.0

2019-08-13 Пенетрантность S.A.N
Возможно я не нашел, но в данной версии нет возможности broadcast каналов?
Когда одно сообщения передается множеству WebSocket клиентов и как одного
клиента подписать на множество каналов?
Этого нет в текущей версии или вы не планируете этого делать и данный
функционал нужно будет писать самому на Node.js?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284362,285246#msg-285246

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx-1.17.3

2019-08-13 Пенетрантность S.A.N
В вашей дорожней карте, для ветки 1,17 есть в планах имплементация QUIC
(HTTP/3), какие ваши оценки по времени это будет готово в этом году.
И если не сложно скажите как вам QUIC там реально много профита для мобил
клиентов, у нас очень много мобил HTTP клиентов и нам эта тема очень
интересна.
Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285238,285245#msg-285245

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Релиз Unit 1.9.0

2019-06-16 Пенетрантность S.A.N
> Тем временем, мы продолжаем трудиться над поддержкой WebSocket для
> модулей
> Node.js и Java.  Все почти готово; шансы на то, что это войдет в
> следующий
> выпуск - очень велики.

Возможно уже есть документация и открытое бета тестирования для Node.js?

> Напоминаю, что мы непрерывно находимся в поиске талантливых
> разработчиков,
> желающих присоединиться к нашей команде.  Вакансии в Москве и других
> локациях

Мы уже давно для WebSocket, используем Nginx модуль nchan, его разрабатывает
один парень `Leo`
https://github.com/slact
Возможно в составе вашей команды, он бы сделал еще больше.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284362,284549#msg-284549

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: epoll_ctl: file exists ?

2019-05-04 Пенетрантность S.A.N
> RFC 8441, Но 
> это, скажем так, выглядит как хак, при этом малосовместимый с 
> существующей логикой работы через Upgrade, и имеет мало шансов 
> быть поддержанным.)

Есть реализация (клиент и сервер)
https://github.com/warmcat/libwebsockets

В Chrome тоже давно работает.
https://www.chromestatus.com/feature/6251293127475200

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,283982,284028#msg-284028

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: fastcgi keep conn on и fastcgi finish request() в PHP

2019-01-19 Пенетрантность S.A.N
> Я не слежу за разработкой PHP, но если вы по прежнему наблюдаете 
> проблему - можно предположить, что баг в PHP так и не поправили, и 
> fastcgi_finish_request() пользоваться не стоит.

Да, у нас это была одна из причин, уйти от FPM, и перейти на Swoole
https://www.swoole.co.uk/docs/
Потом на самописный наш app server

В FPM более 100 багов которым 2-5 лет, FPM не развивается и там уже ищут
нового мейтейнера
https://externals.io/message/101893

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,247596,282751#msg-282751

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Релиз Unit 1.4

2018-09-22 Пенетрантность S.A.N
> Я заметил, что вы много всего просите, а могли бы стать нашим
> крупнейшим
> клиентом и тем самым влиять на ход разработки тех или иных
> возможностей,
> как в nginx, так и в Unit.  Разработка обходится совсем не бесплатно и
> потому получают приоритет в первую очередь те вещи, которые позволяют
> продолжать совершенствовать наши продукты, в том числе open-source.


К сожалению, финансовые вопросы я не решаю, но во всех наших проектах я
всегда лобирую ваши техн продукты, скажу честно ваши платные продукты мне
сложней лобировать.
Но я согласен, что бизнес должен делится прибылью с разработчиками
бесплатного софта.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,281345,281359#msg-281359

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Релиз Unit 1.4

2018-09-21 Пенетрантность S.A.N
> поддержкой WebSockets, гибкой
маршрутизацией запросов и выдачей статического контента.

Этого действительно не хватает в Unit.
НТТР кеширования, как в Nginx, тоже уже в разработке?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,281345,281350#msg-281350

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: WebSockets over HTTP/2

2018-03-02 Пенетрантность S.A.N
> Но к вебсокетам все это никакого отношения не имеет, не так ли?

Да, вы правы, мой ответ был в контексте НТТР запросов.

Польза для WebSocket использовать сокет Н2, в том что он будет держать
открытым сокет, который использует ajax запросы.
У нас может быть 20-30 ajax потом минут 15 тишина, юзер переключился на
другую вкладку и наш Н2 сокет через 10 минут браузер закрывает, юзер
возвращается и нам нужно открывать новый Н2 сокет для ajax запросов.

Так же у меня есть мысль, сделать идентификацию юзера по ключу
$server_id$nginx_worker$connection_id, эти значения юзер подделать не может,
их будет передавать на бекенд Nginx в кастом заголовке.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,278858,278893#msg-278893

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: WebSockets over HTTP/2

2018-03-02 Пенетрантность S.A.N
> От самого мультиплексирования на уровне приложения приемуществ особых
> нет,
> больше недостатков.

Судите сами, на уровне приложения (браузера) сейчас есть два варианта:

НТТР 1х - лимит 8 открытых сокетов на 1 хост, все запросы становятся в эти 8
очередей.
НТТР 2   - в 1 сокет отправляются все запросы, получения ответов асинхроное,
лимитов на кол-во запросов почти нет, очередей почти нет.

У нас клиент веб приложения, занимается агрегированием данных полученных из
многих ajax запросов на один хост.
Часто нужно сделать 20-30 параллельных НТТР GET запросов, чтобы собрать все
нужные данные, без Н2 мы становились в последовательную очередь, потому что
в 8 сокетов столько запросов не влазит, в Н2 такой проблемы нет, для нас это
важно потому что многие GET ответы кешируются на уровне Nginx и нам не
выгодно стоять в очереди чтобы получить ответ из Nginx кеша.

P.S.
Нам кстати это (много параллельных GET запросов) нужно делать и на бекенде,
между бекенд приложениями, я написал issue для Unit Nginx
https://github.com/nginx/unit/issues/81
Есть реальные шансы что это когда-то будет реализовано?

Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,278858,278891#msg-278891

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: WebSockets over HTTP/2

2018-03-02 Пенетрантность S.A.N
> А  в  чём  преимущества  HTTP2  для  Вас?  Вы пробовали делать замеры,
> сравнивающие HTTP2 с HTTP1.1?

Для нас преимущество только в мультиплексировании, других преимуществ нет, у
нас просто много параллельных ajax запросов, НТТР 2 push не использовали,
возможно тоже полезная штука, но практики не было.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,278858,278884#msg-278884

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: WebSockets over HTTP/2

2018-03-01 Пенетрантность S.A.N
> Если/когда появится стандарт 
> и реализации в браузерах - посмотрим.

Это уже работает в Chrome 66 (Canary) и Firefox разрабатывает реализацию,
судя по всему браузеры пришли к консенсусу в этом вопросе.

> Хотя вот лично мне - усиленно кажется, что конкретный драфт - суть 
> достаточно вялая и наверное даже вредная попытка исправить косяк, 
> заложенный в HTTP/2, и запрещающий Upgrade.  Правильнее было бы 
> признать проблему, и начать работать над тем, чтобы максимально 
> отвязать HTTP/2 от собственно HTTP, оставив его отдельным уровнем 
> мультиплексирования.

Представили Nginx, принимают какое-то участия в обсуждении новых фишек в
НТТР протоколе?
Я думаю это было бы полезно, для всех.

Но я как прикладной разработчик, вижу пользу в том чтобы Websocket
соединения юзал тот же клиентский сокет что и HTTP2 соединения.
Сейчас браузер открывает два разных сокета, один для HTTP2 второй для
Websocket, так более накладно и нет гарантии что два этих соединения придут
на тот же прокси сервер, по этому ajax запросы и Websocket могут общатся с
разными прокси, это не удобно и накладно.

Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,278858,278866#msg-278866

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

WebSockets over HTTP/2

2018-03-01 Пенетрантность S.A.N
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,278858,278858#msg-278858

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вопросы по http2 push

2018-02-28 Пенетрантность S.A.N
> Push cache очищается при закрытии 
> соединения, но все элементы при первом использовании браузером будут 
> помещены в http cache, так что всё нормально.
> Подробнее здесь: 
> https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/

Если ресурс отданный push ответом, используется на странице и в ответе были
заголовки НТТР кеширование, браузер этот ресурс перемещает в НТТР кеш?
Когда я экспериментировал с push ответами, браузеры не перемещал push
ресурсы в НТТР кеш, вы тестировали только в новом Chrome, как обстоят дела в
других браузерах?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,278784,278824#msg-278824

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вопросы по http2 push

2018-02-28 Пенетрантность S.A.N
> Не совсем понял ваши слова про "не кешируемый контент".

По спецификации НТТР 2, браузер push ответы могут кешировать только в
отдельном кеше соединенния (смотрите на connection_id в devtools), после
закрытия соединения кеш очищается.
Или я не прав, браузеры сохранят push ответы в общем кеше и потом можно их
использовать в разных connection и ревалидировать?
 
> А use case простой: замена inline CSS, который блокирует отрисовку 
> страницы. А также любые ресурсы из критического пути рендеринга
> страницы.

Для этих целей лучше использовать отдельные запросы, с заголовками НТТР
кешированием на год и инвалидировать этот кеш только по изменению юрл.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,278784,278821#msg-278821

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вопросы по http2 push

2018-02-27 Пенетрантность S.A.N
Я не вижу большой пользы от push, очень редкий случай когда нужно отправить
дополнительный  не кешируемый контент без запросов, или я ошибаюсь, вы
можете перечислить свои use case?

Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,278784,278816#msg-278816

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.3 beta

2017-12-30 Пенетрантность S.A.N
> Иными словами сервис - это более узкий термин, определяющий выполняемую
приложением роль.
> Возможно он идеально подходит для systemd, но я бы не стал называть
большинство веб-приложений сервисами.

Я абсолютно согласен с этим определением.
Но хочу обратить внимание что основная цель Systemd в том чтобы сделать из
любого Линукс приложения, работающий Линукс сервис.
Возможно я ошибаюсь, но основная цель Nginx.Unit - сделать из любого бекенд
приложения, работающий веб-сервис, или нет?

Давайте посмотрим что предпологаеться указывать в разделе "applications"

"applications":
{
"blogs": {блог это же веб-сервис},
"wiki": {тоже больше похоже на веб-сервис},
"shopping_cart": {это важный веб-сервис, который можно разбить на
микросервисы},
"chat": {100% веб-сервис}
}

Я как бекенд разработчик мыслю так, я разрабатываю бекенд приложения и мне
нужен Nginx.Unit чтобы сделать из моего бекенд приложения, работающий веб
сервис.

> текущая терминология устраивает в том числе американскую часть компании,
для которой это родной язык, поэтому вероятность одобрения не велика.

Просто им нужно предложить более короткое название Services, которое более
точно отражает основную миссию Nginx.Unit - создавать веб-сервисы из
бекенд-приложений.

В любом случаи, с наступающим НГ!

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,277933,277947#msg-277947

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.3 beta

2017-12-29 Пенетрантность S.A.N
> Как по вашему, firefox - это сервис или приложение?  Можете обосновать
> почему?

Я же не ради холивара это писал :)
Клиентские GUI приложения сервисами сложно назвать, но для меня:
PHP-FPM - это сервис
Node.js - это сервис
Python WSGI - это сервис
Go Server - это сервис

Возможно у меня systemd головного мозга, но в вашем конфиге, раздел
"listeners" я понимаю как директивы для systemd.socket и соответственно
"applications" у меня ассоциируется с директивами для systemd.service, мне
так проще унифицировать свои знание и ваше название Unit очень помогает
сделать связь с unit от systemd.

В идеале мне (думаю и многим тоже) будет удобно если все аналогичные
директивы из unit.nginx и systemd будут иметь одинаковые название.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,277933,277944#msg-277944

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.3 beta

2017-12-29 Пенетрантность S.A.N
Всех с наступающим НГ.

Много раз себя ловил на мысли когда смотрел на JSON конфиг Unit, почему вы
решили сервисы называть application?

Я понимаю что NGINX Unit - это Application Server, но уже устоялись такие
понятия как microservice, которые часто настраиваются как отдельные Unit для
systemd.service + systemd.socket, там application называются service.

Это конечно не критично, но согласитесь что будет всем удобно использовать
одну терминологию.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,277933,277942#msg-277942

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

2017-11-23 Пенетрантность S.A.N
> С точки зрения практики - паттерн "daemon(); write_pidfile();" 
> используется чуть менее, чем везде, вплоть до соответствующих 
> библиотечных функций.  Так что инициатива выглядит, скажем так, 
> сомнительной.
> 
> Проще всего, IMHO, это было бы заткнуть на уровне systemd, 
> дожидаясь появления pid-файла при необходимости.

Возможно я чего-то не понимаю, но для Systemd лучше вообще не указывать pid
файл, вместо Type=fork использовать Type=notify, это более гибкий вариант
сообщить Systemd что процесс готов к работе.

Вот подробней, кстати PostgreSQL и PHP-FPM уже перешли на него.
https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type=

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,277438,277473#msg-277473

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: gzip filter failed to use preallocated memory

2017-11-21 Пенетрантность S.A.N
> Возможно.  Я отправил его коллегам на 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/mailman/listinfo/nginx-ru

Re: gzip filter failed to use preallocated memory

2017-11-15 Пенетрантность S.A.N
Maxim Dounin Wrote:
---
> Патч ниже по первой ошибке преаллокации пытается предполагать, что 
> мы работаем с jtk zlib, и работает соответственно.  Если и это не 
> помогло - тогда уже начинает писать в лог alert'ы.

Сработало, спасибо!
В логе сообщений уже нет, других изменений в поведении Nginx не заметил,
этот патч войдет в следующую версию Nginx?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276955,277335#msg-277335

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: gzip filter failed to use preallocated memory

2017-11-11 Пенетрантность S.A.N
Maxim Dounin Wrote:
---
> Я, впрочем, подозреваю, что на самом деле там не это, а то, что 
> лежит по адресу https://github.com/jtkukunas/zlib.  Название и 
> содержимое пакета как бы намекает:
> 
> https://download.clearlinux.org/current/source/SRPMS/zlib-1.2.8.jtkv4-
> 40.src.rpm

Вы правы, в OS ClearLinux библеотека zlib из этого пакета и там нет
константы Z_IPP_FAST_COMPRESSION.
Я написал им issue, чтобы они добавили константу, но сомневаюсь что в
ближайшем будущем они что-то сделают, хотя.

Может быть сделать спец флаг компиляции Nginx ./configure --with-ipp-zlib
Как уже предлагали в этой ветке
https://forum.nginx.org/read.php?2,252113,252114#msg-252114 

Тогда мейнтейнеры смогут создавать свои сборки Nginx с 3rd party zlib.
Этот вариант для вас приемлем?

> Уровень логгирования alert означает ситуацию, которая не должна 
> возникать при нормальной работе, и означает ошибку где-то.  В 
> данном случае мы знаем причину - библиотека от Интел нарушает 
> документированный интерфейс zlib в части требований к памяти - и 
> этого достаточно для того, чтобы игнорировать и/или понизить 
> уровень ошибки до менее значительного в случае использования 
> этой библиотеки.  Однако я бы предпочёл не трогать уровень 
> логгирования для всех остальных случаев.

Я согласен с вашими словами, но я ничего не понял что нужно мне сделать,
чтобы в логах не было этой ошибки?
В конфиге отключить логирование этого alert можно только если указать
уровень логирование emerge
error_log log/error.log emerge;
Но это не хорошо, мягко говоря, или вы имели виду чтобы я сделал свой патч и
изменил в коде Nginx уровень логирование?

Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276955,277289#msg-277289

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: gzip filter failed to use preallocated memory

2017-11-10 Пенетрантность S.A.N
> Есть смысл разобраться, что у вас используется вместо 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 (0x7ffed8d7c000)
libc.so.6 => /usr/lib64/haswell/libc.so.6 (0x7fe455d53000)
/usr/lib64/ld-linux-x86-64.so.2 (0x7fe455f8b000)


>  как  это что-то детектировать и аллоцировать под него память, и 
> прислать патч.

Мне сложно сказать как правильно детектировать эту библиотеку, и патч
написать я тоже не смогу (я не Си разработчик) но могу тестировать.
Intel, сделали хорошую работу, их gzip работает почти в 2 раза быстрей, не
хочется возвращаться на стандартную zlib.

Возможно будет достаточно если Nginx изменит уровень ошибки, сейчас уровень
этой ошибки Alert, но это не правильно, потому что Nginx не падает и все
работает, я думаю правильно выдавать Notice, тогда можно не логировать
Notice уведомления и все будет норм?

Спасабо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276955,277278#msg-277278

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: gzip filter failed to use preallocated memory

2017-11-10 Пенетрантность S.A.N
Есть смысл мне писать в 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/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность S.A.N
Я уже подымал эту тему на Github
https://github.com/nginx/unit/issues/6

Будет хорошо создать здесь отдельные maillist для Unit.

Я согласен с теми кто считает что Unit сложно будет конкурировать с
PHP-FPM.

1. Простота в настройке и запуске разных версий РНР - это совсем не сложно,
есть пакеты Remi разных РНР версий, подключаешь их все как хочешь, проблем
нет, но с каждым годом потребности в РНР 5 будет все меньше, все переходят
на РНР 7+.

2. Производительность, пока что говорить рано, но уже понятно что для
статики и кеширование пока что нужен Nginx, значит Unit нужно проксировать,
это означает дополнительный сокет рассходы, Browse -> Nginx -> Unit это тоже
самое как сейчас Browse -> Nginx -> FPM, когда Unit научитися отдавать
статику и кешировать ответы тогда вопрос кто будет заниматься балансировкой,
сейчас это делается в Nginx указываются пулы upstream к удаленным FPM
бекендам, это значит что Unit тоже придется проксировать если нужна
балансировка нагрузки.


Но, я вижу свободную и перспективную нишу для Unit, дело в том что PHP-FPM
нужен только тем РНР скриптам которые "умирают" после каждого запроса. Мы
уже три года в продакшене используюм РНР скрипты которые запускаются через
PHP-cli с модулем libuv он нужен для evetloop и асинхрого I/O, на РНР
написан НТТР сервер который асинхорно обрабатывает все НТТР запросы от
Nginx. Это работает на 40% быстрей чем Node.js и 200% чем PHP-FPM и дает
много возможностей websocket и много другое.

Короче говоря в РНР нет промышленного App Server, как в Node.js, ваш Unit
отличный претендент на роль True App Server для PHP, то что сейчас в Unit
пулы отдельных РНР процессов которые очищают состояния скрипта после каждого
запроса, это не круто, и для этого уже есть хорошее решения - PHP-FPM.

Мне от Unit, нужны только три event в userland моего скрипта, причем очень
правильно если бы Unit умел не только НТТР но и Websocket, вот event которые
универсальны для НТТР и для Websocket, бекенд будет полностью абстрагирован
от протокола клиента.

onOpen - новое соединения
onMessage  - новое сообщения или новый запрос если это НТТР протокол
onError - ошибка.
onClose - коректное завершения соединения.

РНР скрипт не блокироваться и Unit может вызывать эти евенты не дожидаясь
ответа на предыдущий, это очень эффективно и быстро.
Если вам интересно я могу детально обсуждать.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276967,277004#msg-277004

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

gzip filter failed to use preallocated memory

2017-10-18 Пенетрантность S.A.N
Здравствуйте.

Мы начали использовать OS ClearLinux for Intel® Architecture, (отличная
производительность)
Все работает хорошо, но в логах Nginx мы постоянно видим

[alert] 31591#31591: *1 gzip filter failed to use preallocated memory: 65536
of 16368

Таких записей очень много, не смотря на их уровень важности [alert] все
работает нормально и Nginx отдает правильно упакованые gzip ответы.
Я так понимаю, Nginx просто сообщает что у нас не стандартная gzip
библиотека, но зачем [alert] и зачем так засорять лог, может стоит
адаптировать код Nginx для работы с такими gzip библиотеками, или может мы
можем скомпилить Nginx с спец опцией?

Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276955,276955#msg-276955

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: HTTP/2 + ALPN в Debian 8 Jessie

2017-08-11 Пенетрантность S.A.N
> > Для Fedora 25-26 (Open SSL 1.1) будет сборка?
> Таких планов нет, т.к. популярность этих дистрибутивов на сервере,
> кажется, невелика.

Да, Fedora не популярна в продакшине, у неё своя ниша, она хорошо для тестов
будущих версий RHEL.

Уже вышла RedHat 7.4 у неё openssl 1.0.2k, скоро выйдет CentOS 7.4, ждем
ваших новых сборок с поддержкой ALPN для RHEL.

Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,275648,276027#msg-276027

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: HTTP/2 + ALPN в Debian 8 Jessie

2017-07-25 Пенетрантность S.A.N
Для 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

Re: client_body_temp_path - permissions

2017-06-03 Пенетрантность S.A.N
> В таком виде, конечно, не закоммитят. Я тут нагло воспользовался
> существованием внутреннего флага, который по факту используется для
> webdav-модуля, и "вытащил" его в конфигурацию, потому патч и такой
> простой. Если уж делать по-человечески - то делать нормальную
> конфигурацию по аналогии с proxy_store_access. Но это немного сложнее,
> и такой патч, вероятно, уже не будет так легко накладываться на
> практически любую версию.

Спасибо за патч, но мы не можем прописывать в требования нашего ПО,
установку патча для Nginx, клиенты этого не поймут.

Сейчас мы запускаем бекенд под пользователем Nginx, чтобы иметь доступ к
файлам 0600, но это тоже не очень хорошо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,274059,274633#msg-274633

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: client_body_temp_path - permissions

2017-06-02 Пенетрантность S.A.N
> Т.е. директиву client_body_in_file_only и переменную
> $request_body_file добавили, а
> прав на файлы - добавить забыли.

Да, в интернете многие задаются вопросом почему сделано это так, похоже что
просто забыли учитывать client_body_in_file_only.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,274059,274620#msg-274620

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: client_body_temp_path - permissions

2017-06-02 Пенетрантность S.A.N
Я уточню чтобы меня понимали.

Мы используем директиву - client_body_in_file_only clean; для получения
файлов от клиента при аплодинге, указываем директорию в директиве
client_body_temp_path, все работает хорошо, только пермишены файлов в этой
папке 0600.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,274059,274616#msg-274616

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: client_body_temp_path - permissions

2017-06-02 Пенетрантность S.A.N
> Это временный файл процесса nginx, и, насколько я понимаю, никакая
> обработка в
> других процессах не предусматривается. В силу этого же права
> выставлены в 0600 и
> другого быть не может.

Временный файлы процесса Nginx, создаются без директивы
client_body_temp_path.

Вот директива client_body_temp_path для того и придумана, чтобы бекенд мог
получить тело запроса в уканом файле, этот файл Nginx не удаляет пока бекенд
не ответит на запрос, т.е. файл создается для обработки его в бекенде.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,274059,274614#msg-274614

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: client_body_temp_path - permissions

2017-06-02 Пенетрантность S.A.N
Konstantin Baryshnikov Wrote:
---
> > 
> > On May 31, 2017, at 12:35 AM, S.A.N <nginx-fo...@forum.nginx.org>
> wrote:
> > 
> > Я конечно извиняюсь, за настойчивость, но неужели пермишен 0600, на
> файл
> > который должен быть обработан в другом процессе, это нормально и это
> никак
> > нельзя настроить в конфиге Nginx?
> 
> Нельзя.
> 
> Я по большой нужде обходился вот таким патчем:
> 

Спасибо, но проблема ручных патчей в будущей поддержке, нужно не забывать
всегда патчить новые версии Nginx, и потом тестировать...
Будет очень хорошо если его закомитят и будет работать из коробки.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,274059,274602#msg-274602

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: client_body_temp_path - permissions

2017-05-30 Пенетрантность S.A.N
Я конечно извиняюсь, за настойчивость, но неужели пермишен 0600, на файл
который должен быть обработан в другом процессе, это нормально и это никак
нельзя настроить в конфиге Nginx?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,274059,274538#msg-274538

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Следование по редиректам вместо ответа браузеру.

2017-05-21 Пенетрантность S.A.N
> В первом сообщении указана ссылка на php-скрипт, где и используется
> x-accel-redirect. Задача: сделать, чтобы nginx, приняв url, ещё и
> переходил по редиректам, а не завершал обработку при получении первого
> редиректа.

Nginx, браузеру заголовок X-Accel-Redirect никогда не отдает, т.е. браузер
не может сам ходить по этим редиректам, по ним может ходить только Nginx, вы
даже можете в именованые локейшины ходить.

header('X-Accel-Redirect: @named_location');

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,274346,274356#msg-274356

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Следование по редиректам вместо ответа браузеру.

2017-05-20 Пенетрантность S.A.N
> В идеале - хотелось бы решения чисто на 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 mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: fastcgi cache background update ssi подзапросов

2017-05-10 Пенетрантность S.A.N
Офтоп - мы делаем по другому, части контента загружаем аяксом на клиенте и
строим страницу на клиенте, есть и сервер рендер, который по сути является
агрегатором, РНР делает НТТР запросы к другим РНР скриптам, те отдают JSON,
и собираем страницу на сервере и отдаем готовый НТМЛ, в плане кеширование
работает проще и гибче.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,274136,274143#msg-274143

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Best practices - url versioning static cache

2017-05-09 Пенетрантность S.A.N
> Но это требует 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

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: try files - принудительно "перейти" к следующему варианту

2017-05-03 Пенетрантность S.A.N
Дмитрий Герасимов Wrote:
---
> Вообщем всем спасибо. Сегодня узнал о существовании incron (век живи,
> век учись), при помощи онного и решил проблему

Есть аналог API в systemd
https://www.freedesktop.org/software/systemd/man/systemd.path.html

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,274006,274062#msg-274062

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

client_body_temp_path - permissions

2017-05-03 Пенетрантность S.A.N
Здравствуйте.

Сейчас файлы создаются с правами 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#msg-274059

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: listen unix socket - после перезагрузки Nginx - failed (98: Address already in use)

2017-04-17 Пенетрантность S.A.N
Возможно по этой же причине Nginx иногда не удалял файлы, по директиве

client_body_in_file_only clean;
client_body_temp_path - на локал файл системе

Наверно, в момент получения QUIT сигнала, процес Nginx завершался и файлы не
удалялись.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,273687,273692#msg-273692

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: listen unix socket - после перезагрузки Nginx - failed (98: Address already in use)

2017-04-17 Пенетрантность S.A.N
Maxim Dounin Wrote:
> Но в целом идея, что для остановки nginx'а системными скриптами 
> надо использовать QUIT - она, скажем так, странная.

Да, странно зачем в дистрибутиве от Nginx, в файле nginx.service указан QUIT
сигнал

ExecStop=/bin/kill -s QUIT $MAINPID

Если удалить эту строчку, Systemd при остановке и перезагрузки сервиса,
отправляет TERM сигнал.
Спасибо!

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,273687,273691#msg-273691

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

listen unix socket - после перезагрузки Nginx - failed (98: Address already in use)

2017-04-17 Пенетрантность S.A.N
Может я что-то не так делаю, в конфиге указываю:

server
{
listen unix:/var/run/www/test.sock;

}

Nginx создает файл сокета при старте, но после перезагрузки systemctl
restart nginx, файл не удаляется и Nginx не может к нему забиндится, в логе
выдает ошибку 
[emerg] bind() to unix:/var/run/www/test.sock failed (98: Address already in
use)

Что делать?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,273687,273687#msg-273687

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Cache TTL = 0

2017-03-30 Пенетрантность S.A.N
Проще всего сделать как в 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

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Cache TTL = 0

2017-03-30 Пенетрантность S.A.N
Здравствуйте.

Я уже когда-то писал, что некоторые запросы бекенды должны всегда
ревалидировать, в спецификации это документировано в трех параметрах
заголовка Cache-Control.

max-age=0 - кешировать если есть валидатор (ETag или Last-Modified)
no-cache - не использовать кеш без ревалидации
must-revalidate - нужна ревалидация

Есть тикеты в багтрекере
https://trac.nginx.org/nginx/ticket/1182

Amazon CloudFront, уже это потдерживает в своих патчах Nginx
http://stackoverflow.com/questions/10621099/what-is-a-ttl-0-in-cloudfront-useful-for

Я провел маленькое исследования, многие веб фреймворки используют параметр
no-cache чтобы отключить кеширование, реже для этого используют max-age=0,
но никто не использует для отключения кеширования параметр must-revalidate.

Чтобы не нарушить обратную совместимость со многими фрейворками, безопасней
всего научить Nginx понимать параметр must-revalidate.

Если не указаны no-store, no-cache, max-age=0 но указан must-revalidate и
бекенд отдал валидаторы ETag или Last-Modified, тогда Nginx сохраняет ответ
в свой кеш и при запросах всегда проводит ревалидацию.

Это потребность из реальных кейсов, спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,273298,273298#msg-273298

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx-1.11.10

2017-02-16 Пенетрантность S.A.N
> 2) и что, всю толпу заголовков перечислять в ignore, если вдруг
> хочется чтобы 
> всё происходило ровно так, как описано в конфиге? :)

Нет, достаточно указать ignore Cache-Control и бекенд не сможет рулить
кешированием, но вообще заголовки от бекенда, появляются не от сырости, их
там разработчики специально, в коде запрограммировали, чтобы управлять
кешированием :)

Да, кстати на заголовок Cache-Control: max-age=1 stale-if-error=100
stale-while-revalidate=100 уже реагирует Хром, он может в офлайне работать с
этим кешем.

Но вы так же должны знать, что даже в онлайне когда на сервере уже есть
новый кеш, браузер всегда будет загружать из своего локал кеша старый кеш
(не старше значения из stale-while-revalidate) и только в фоновом режиме
отправит запрос на сервер, но на странице будет старый контент.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272411,272472#msg-272472

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx-1.11.10

2017-02-16 Пенетрантность S.A.N
> 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-revalidate?
Приоритеты директивы proxy_cache_valid и заголовка Cache-Control: max-age,
полностью на оборот.

Если в конфиге прописать
proxy_cache_use_stale error updating;

И в закешированом ответе есть заголовок
Cache-Control: max-age=1 stale-if-error=0 stale-while-revalidate=0

Nginx будет использовать устаревший ответ?

И на оборот, если в конфиге, указать
proxy_cache_use_stale off;

И в закешированом ответе есть заголовок
Cache-Control: max-age=1 stale-if-error=100 stale-while-revalidate=100

Nginx будет использовать устаревший ответ?

На практике более гибко и удобно чтобы приоритеты НТТР заголовков были
всегда выше, директив из конфига, есть proxy_ignore_headers если нужно
обратное.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272411,272470#msg-272470

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx-1.11.10

2017-02-14 Пенетрантность S.A.N
За поддержку заголовков stale-* отдельное спасибо.
Когда появится в документации описания новой директивы -
proxy_cache_background_update?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272411,272413#msg-272413

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Cache: Invalidation After Updates or Deletions (RFC 2616)

2017-02-13 Пенетрантность S.A.N
Илья Шипицин Wrote:
---
> 13 февраля 2017 г., 18:01 пользователь S.A.N
> <nginx-fo...@forum.nginx.org>
> написал:
> 
> > Здравствуйте.
> >
> > Есть потребность в реализации вот такого поведения:
> >
> 
> 
> а если у вас несколько экземпляров nginx ? (варианты - из простых dns
> round
> robin)
> т.е. инвалидируете вы только на одной реплике

Это уже другая зона ответственности, сейчас речь не об этом, но если в двух
словах - все что можно сделать на одной ноде, можно горизонтально
маштабирвать на другие, но общего решения на все случаи нет.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272373,272375#msg-272375

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Cache: Invalidation After Updates or Deletions (RFC 2616)

2017-02-13 Пенетрантность 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 present). These methods are:
 - PUT
 - DELETE
 - POST

Это нужно вот для чего, есть Nginx кеш динамических ответов от бекенда, его
TTL 3 days, URI: /news/top/
Авторизованный пользователь добавляет новую новость, методом POST на URI:
/news/top/
Бекенд сохраняет этот контент и отдает клиенту НТТР статус 200.

В соответствии с RFC 2616, хотелось бы чтобы Nginx, очистил кеш URI:
/news/top/ потому что на этот URI пришел запрос методом POST и бекенд
ответил 200 ОК, что означает что все нормально контент изменился и кеш этого
URI надо инвалидировать.

Тоже самое с методом DELETE.

Вот с методом PUT и заголовком Content-Location можно делать ещё более
крутые штуки, например авторизованный пользователь отправляет PUT запрос на
URI: /news/rest.php?id=150
Бекенд сохраняет этот контент и отдает клиенту НТТР статус 200 с заголовком
Content-Location /news/150/ и в теле ответа уже новый контент который нужно
сохранить в кеше использую как URI значения заголовка Content-Location
/news/150/ т.е. Nginx должен инвалидировать кеш в ключе которого
использовался URI /news/150/.

Это очень удобный функционал, и он описан в спецификации, его можно
реализоваь в Nginx?
Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272373,272373#msg-272373

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Cache-Control: immutable

2017-01-29 Пенетрантность S.A.N
> К сожалению, это все равно не панацея
> Firefox почему-то смотрит на этот параметр только для https
> соединений, а для якобы устаревших http игнорирует его.. Хотя казалось
> бы зачем это вообще разделять...

У вас юзера часто руками обновляют страницу, или это делает js, если js,
тогда вместо location.reload() вызывайте location.replace(location.href),
страница перезагрузится, но валидный кеш будет загружен из диска, без
запросов к серверу.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272176,272184#msg-272184

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Cache-Control: immutable

2017-01-29 Пенетрантность S.A.N
> Да, поставь ты expires и max-age хоть на сто лет вперед, любое F5 у
> Firefox вызовет запрос на сервер. Да, в ответ пойдет 304, но сам
> запрос то никак не отменить (кроме как этим флагом)

Да, я уже понял и написал ниже: +1 за Cache-Control: immutable

На сегодня immutable реализован только в Firefox, а Chrome просто изменили
поведения и теперь при F5 статика отдается из клиент кеша, без запроса к
серверу.

Я поддерживаю авто добавления параметра immutable, в заголовок Cache-Control
когда в конфиге Nginx включена директива expires max.

Кстати, сейчас expires max, выдает значения 10 лет, но гугл рекомендует так
не делать и устанавливать значения не больше 1 года.
Вот цитата:
Не устанавливайте срок больше одного года: это является нарушением правил
RFC.
https://developers.google.com/speed/docs/insights/LeverageBrowserCaching?hl=ru

Возможно есть смысл не только добавить immutable, но и цифры в max-age
установить равным 1 году.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272176,272181#msg-272181

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Cache-Control: immutable

2017-01-29 Пенетрантность S.A.N
> вот тут подробности:
> 
> http://www.opennet.ru/opennews/art.shtml?num=45934
> 27.01.2017 23:49 Firefox и Chrome провели работу по увеличению
> скорости 
> повторной загрузки страниц

Спасибо, да метод POST и поведение кнопки "перезагрузить страницу", вызывает
условный запрос.

+1, за Cache-Control: immutable.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272176,272179#msg-272179

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Cache-Control: immutable

2017-01-29 Пенетрантность S.A.N
Почитал спеку, но так и не понял, что нового дает immutable, если установить
expires max, клиент раз в год будет делать условный запрос, если установить
immutable, клиент никогда не будет делать условных запросов, т.е. это все
ради того чтобы клиент не делал запрос раз в год?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272176,272177#msg-272177

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Best practices - url versioning static cache

2017-01-22 Пенетрантность S.A.N
Anton Bessonov Wrote:
---
> А что, если перенести это на уровень бильд-процесса? Успешно использую
> с 
> мэйвеном (подсчёт версии, копирование файлов в /static/${number} и 
> замена переменных в ресурсаx), вэбджар и ocLazyLoad.
> 
> На уровне энджина просто добавлаю кэш-форева для /static и /webjar.
> 

Да, так можно, но есть проекты где нет умного билдера статики, он там просто
избыточен, мне интересно как сделать версионирования силами одного Nginx.

Если уже использовать бильд-процесс, тогда лучше чтобы он работал как
веб-сервер, а Nginx его проксировал и кешировал, тогда билдер сможет
отдавать скомпилированные бандлы с нужными HTTP заголовками, например при
запросе к /xxx/app.js он отдаст:
Link: ; rel=preload; as=script

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272099,272102#msg-272102

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Best practices - url versioning static cache

2017-01-22 Пенетрантность S.A.N
Здравствуйте.

Для статичных файлов, есть старая добрая практика, добавлять в url, некий
номер версии этого файла, клиентам отдавать в заготовках максимальное время
кеширования, как-то так:

expires max;


Re: патч для отключения заголовков "Connection: keep-alive" (еще раз)

2016-12-19 Пенетрантность S.A.N
Одно из достоинств 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/mailman/listinfo/nginx-ru

Re: nginx socket fastcgi_params

2016-12-16 Пенетрантность S.A.N
> GEOIP-* - обязательно. remote_user особо не важен.

Дело в том, что $remote_user не может открыть соединения по локальному
unix-сокету из другого города или страны.
У вас наверно есть внешний прокси для этого, если да, тогда все эти
параметры должен передать внешний прокси (например в НТТР заголовках) вы
должны взять эти параметры из переменных HTTP_*

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,271610,271617#msg-271617

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy_store - HTTP headers

2016-12-13 Пенетрантность S.A.N
> Что, впрочем, не мешает автору треда взять прокси-модуль, немного
> изменить код 
> и радоваться жизни :)

Нет, все таки придется юзать proxy_cache :)

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,271460,271464#msg-271464

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

proxy_store - HTTP headers

2016-12-13 Пенетрантность S.A.N
Здравствуйте.

Есть ли возможность в proxy_store сохранять не только тело ответа, но и все
НТТР заговоки?

Для нашей задачи proxy_store подходит на 99%, не хватает только сохранения
заголовков, использовать proxy_cache нельзя, потому что нам нужно чтобы
имена кеш файлов соответствовали uri, это нужно чтобы другие процессы могли
работать с этими статик файлами.

P.S.
Кстати может в proxy_cache_* есть директива которая позволит именовать файлы
кеша как в proxy_store?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,271460,271460#msg-271460

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Возможно баг? Отказывается кешировать для одного из нескольких server name

2016-11-20 Пенетрантность S.A.N
Nginx, таким образом, за Сloudflare.
> И если обращаться к серверу напрямую по имени domain.ltd, то кэш
> успешно создается. Если же обычным путем (через Cloudflare), то при
> обращении именно на определенный домен кэш не создается. С чем это
> может быть связано?

Возможно Cloudflare не отправляет запрос к Nginx и выдает ответ из своего
кеша, или отправляет запрос к вашему Nginx, но в запросе есть какие то
параметры которые не позволяют Nginx создавать кеш.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,271056,271061#msg-271061

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: настройка systemd в centos 7

2016-10-24 Пенетрантность S.A.N
> Потому что PrivateTmp=true, процес бекенда как правило работает под
> другим юзером и получить доступ к временной папке процесса Nginx
> сможет.

Конечно, НЕ сможет, получить доступ к файлу, моя опечатка )

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,270488,270531#msg-270531

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: настройка systemd в centos 7

2016-10-24 Пенетрантность S.A.N
Мне ещё не нравится, из официального репозитория, вот эта директива:

[Service]
PrivateTmp=true

Огромный подводный камень, например вот это из коробки работать не будет
client_body_temp_path  /tmp/;
client_body_in_file_only on;

Потому что PrivateTmp=true, процес бекенда как правило работает под другим
юзером и получить доступ к временной папке процесса Nginx сможет.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,270488,270530#msg-270530

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Странные текст и ключи в cache nginx

2016-09-09 Пенетрантность S.A.N
Kira_Belka Wrote:
---
> чем тогда является данный текст?!
> Он не является ни заголовком ни каким либо параметром передаваемым в
> POST/GET 
> 
> там первая строчка с посыпавшейся кодировкой и это не кажется
> валидным.
> ??Wo
> KEY:
> 
> что выглядит весьма и весьма странным

Все нормально, так и должно быть, это бинарные мета данные, они нужны только
для Nginx, клиенту эта строка не отправляется.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,269427,269448#msg-269448

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: client_body_in_file_only

2016-08-05 Пенетрантность S.A.N
Проявилась одна фича (или баг?)

В официальном 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_set_header x-file-path $request_body_file;

На бекенд придет заголовок "x-file-path: /tmp/01"
Но в "/tmp" папке нет файла "01" потому что Systemd для процесса
Nginx, указывает другую временную папку, в которую Nginx записывает файл
"01", а бекенду передается не правильный путь "/tmp/01"

В логах Nginx все будет чисто, потому что ошибок нет, а бекенд разаработчики
долго будут думать в чем проблема.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,268350,268787#msg-268787

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: client_body_in_file_only

2016-08-03 Пенетрантность S.A.N
Maxim Dounin Wrote:
---
> Самбу/NFS?  Боюсь, что если так, то на этом 
> пути вас ждёт множество неприятных открытий.
> 

Да, вы правы, на dev сервере Самба/NFS, проблема именно в этом.
Спасибо!

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,268350,268747#msg-268747

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: client_body_in_file_only

2016-08-02 Пенетрантность S.A.N
Ещё вопросы по временным файлам

1. Если клиент закрыл соединения до отправки всего тела запроса, временный
файл остается в папке, Nginx этот файл не удаляет, запрос на бекенд
отправлен не будет. Я так понимаю подразумевалось что ОС должна чистить
папку temp, но может лучше чтобы Nginx сам за собой подчистил?

2. После получения ответа от бекенда, временный файл ещё какое-то время
(~100ms) остается заблокированным процессом Nginx, бекенду после отправки
ответа ещё приходится ждать когда файл освободится на запись.

В конфигах указана директива: client_body_in_file_only clean;

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,268350,268692#msg-268692

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

client_body_in_file_only

2016-07-19 Пенетрантность S.A.N
client_body_in_file_only - работает отлично :)

Но нам нужно провести аутентификацию юзера перед тем как Nginx прочитает все
тело клиентского запроса и сохранит его в файл.
Я знаю про ngx_http_auth_request_module, но это отдельный запрос на бекенд,
хотелось бы сделать проще.

Вот как - Nginx отправляет на бекенд все клиентские заголовки, если бекенд
ответил 100 Continue, тогда Nginx продолжает читать все тело клиентского
запроса, сохраняет его в файл и отправляет на бекенд остававшийся HTTP
заголовки (proxy_set_header x-body-file $request_body_file;).

Такое сделать можно?
Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,268350,268350#msg-268350

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: время ответа

2016-07-18 Пенетрантность S.A.N
> tcp_nodelay и tcp_nopush включал - эффекта никакого. Может это быть
> из-за
> айпитеблсов? Из-за какогонибудь коннтрека или еще чего

Если есть возможность, попробуйте перейти на локальные UNIX сокеты.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,268323,268343#msg-268343

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: когда лучше использовать multi accept on

2016-06-10 Пенетрантность S.A.N
> Я не понимаю что мы выигрываем от принятия сразу нескольких
> соединений за одну итерацию event loop'а.

Я в таких случаях провожу нагрузочные эксперименты, чтобы понять что мы
выигрываем, в данном случаи разница будет на уровне погрешности, но возможно
вам стоит попробовать чтобы знать точно.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,267183,267528#msg-267528

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Есть ли смысл использовать что-то кроме http/1.1, при соединении с бэкэндом?

2016-06-04 Пенетрантность S.A.N
> Можете расшифровать выражение "сокет не простаивал в пустую"?  Чем
> грозит
> сокет, который простаивает впустую?  Что по вашему такой сокет
> потребляет:
> ресурсы процессора, электричество, солярку, деньги?

Сокет который простаивает в пустую (ждет ответа на запрос) потребляет память
приложения, мы используем libev.
Один сокет требует, создания одного WatcherObject и одного HandlerMethod,
это не много, но они 70% времени ничего не делают, потому что время
выполнения запроса в десятки раз превышает время передачи данных по
локальному сокету.

Это не важно когда запросов не много, но когда частота запросов высокая,
открывать новые соединения, на каждый запрос это расточительно и глупо.

Зачем открывать новое соединения, если в бекенд приложении уже и так есть
100 busy сокетов, которые ничего не делают, потому что ждут ответа на
предыдущий запрос, это по сути blocking mode сокета, но созданный на уровне
HTTP/1.х, хотя сокет non-blocking mode.

Мультиплексирование убирает понятие socket busy, бекенд приложению будет
достаточно иметь в десятки раз меньше открытых сокетов (в десятки раз меньше
WatcherObject и HandlerMethod), я уже приводил пример в другой теме, повторю
его снова:

1 запрос выполняется за 100ms 

Если послать 30 последовательных запросов в 1 соединение мы получим 30
ответов за 3000ms 
Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за
100ms 
Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за
100ms 

В первом варианте, 1 сокет находится в режиме busy 3000ms 
В втором варианте, 30 сокетов находится в режиме busy 100ms 
В третьем варианте, 1 сокет находится в режиме busy ~0ms 

Вопрос какой из трех вариантов более эффективно использует ресурсы?

Мультиплексирование - нужно всем бекенд приложениям, у которых есть
временное окно между запросом и ответом, чем больше это временное окно, тем
больше позитив эффекта от мультиплексирование.

Сокеты - это как нефть, её много, но ресурс ограничен
Мультиплексирование - это как сланцевая нефть, она дает возможность
использовать ту нефть, которая ранее считались не пригодная к использованию.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,267298,267369#msg-267369

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Есть ли смысл использовать что-то кроме http/1.1, при соединении с бэкэндом?

2016-06-03 Пенетрантность S.A.N
> Везде SSL. Сейчас с SPDY (еще пока используем nginx-1.8.1). Возможно
> SPDY\http2 
> лишний и стоит его отключить везде, кроме связки клиент->эдж? 

Для видеостриминга, лучше использовать много соединений, HTPP/1.1 хорошо
подходит и ничего более ненужно.

Мультиплексирования, полезно там где между запросом и ответом есть временные
простои, которые занимают больше времени чем получение и передача данных по
сокету, чтобы сокет не простаивал в пустую, протоколы с мультиплексированием
загружают сокет другими запросами, в результате сокет постоянно передает
запросы и получает ответы, в произвольном порядке.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,267298,267303#msg-267303

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-30 Пенетрантность S.A.N
> Возможно, эффективным решением для соединения бэкэндов было бы
> фиксированное количество соединений, бесконечный keepalive и
> pipelining

Да, мы сделали свой pool keepalive сокетов, это действительно помогает.
pipelining мы хотели сделать, но Nginx его не поддерживает, мы гоняем
запросы между бекендами через Nginx, потому что нужен кеш Nginx и
балансировка запросов между бекендами.

Для наших задач (возможно и не только для наших) подходит memcache протокол,
он очень простой, ответы имеют id - это uri запроса, мультиплицировать его
очень просто.
Я поискал сторонние модули, но они не умеет принимать входящие memcache
запросы.

Было бы очень круто, если бы в Nginx была возможность что-то вроде этого

location /
{
   proxy_cache_pass localhost:11211; # address memcached server socket
}


Тогда клиентcий код станет гениально простым :)

memcached->connect("localhost:11211") 
создания соединения с Nginx для общения по протоколу memcached

memcached->get($uri) 
запрос принимает Nginx, ищет ответ в своем кеше, ключ запроса равен ключу
кеша, если в кеше ответа нет, этот запрос отправляется на бекенд,
проксирования на бекенд такое же если бы этот запрос пришел от браузера по
НТТР, т.е GET uri HTTP/1.1

Я понимаю, что это похоже на извращения, но поверьте разработчики бекендов
оценят это и очень быстро и появится много статей как использовать Nginx
вместо Memcache.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266693,267228#msg-267228

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-30 Пенетрантность S.A.N
> Если сокет "простаивает без трафика", то железо отнюдь не простаивает,
> а выполняет работу по тем сокетам, которые не простаивают.
> 
> К тому же при однородной нагрузке количество требуемых содинений с
> бэкэндами должно быть стабильно во времени

Если 30 запросов отправить в 30 разных соединениях, тогда конечно EventLoop
будет все 30 обрабатывать, но тратить на один запрос целое соединения это
слишком расточительно, попробую объяснить на цифрах.

1 запрос выполняется за 100ms

Если послать 30 последовательных запросов в 1 соединение мы получим 30
ответов за 3000ms
Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за
100ms
Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за
100ms

В первом варианте, 1 сокет находится в режиме busy ~3000ms
В втором варианте, 30 сокетов находится в режиме busy ~100ms
В третьем варианте, 1 сокет находится в режиме busy ~100ms

Вопрос какой из трех вариантов более эффективно использует ресурсы?

Если HTPP/2 создает оверхед, ок, есть мультиплексирование в FastCGI, но я
так понял что проблема не в протоколах, проблема в том что логика upstrem в
Nginx ничего не знает про мультиплексирование запросов и заточена на новые
соединения.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266693,267225#msg-267225

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-30 Пенетрантность S.A.N
>  Интересно, сколько нужно открыть fd чтобы ощутить их дефицит в
> системе?

Это зависит от установленого лимита в ОС, по умолчанию 1024, я кстати всегда
хотел узнать, зачем линукс по умолчанию ставит такой низкий лимит?


>  Если у клиента такая логика, что он делает 30 запросов json
> одновременно,
>  может быть, стоит подумать о пересмотре модели работы клиента? Так ли
> уж
>  там нужна параллельная обработка этих 30 запросов?

Я всегда стремлюсь максимально эффективно использовать свободные ресурсы
сервера.
Если запросы обрабатывать последовательно в одном соединение, сокет будет
простаивать без трафика, процес будет простаивать в ожидании получения новых
задач, в общем железо будет простаивать, в результате конечный клиент будет
ждать дольше.

Если все запросы отправлять в новых соединениях, тогда придется за это
платить, для бекендов которые написана на высокоуровневых технологиях, новые
соединения это совсем не zero cost.

Я не против новых соединений, я пытался найти возможности повысить КПД этих
соединений, мультиплексирования в H2 и FastCGI для этого и созданы.

Это важно не только между браузером и серверов, например тот же GRPC
использует HTTP/2 для мультиплексирования.
У нас REST API с HTTP кешированием, но к сожалению мультиплексирования
запросов в upstream соединениях Nginx не поддерживает.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266693,267223#msg-267223

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-27 Пенетрантность S.A.N
Илья Шипицин Wrote:
---
> а как вы понимаете, простаивают они или нет ?

Очень просто, мы на бекенде замеряли сколько соединений открывает Nginx,
днем 200-300, ночью намного меньше, мы установили 250, по таймауту
закрываются лишние.

Кстати когда замеряли, заметили Nginx часто открывал кратковременные
соединения, потом их закрывал и сразу открывал новые, не понятно зачем он
закрывает соединения чтобы потом сразу открыть новые в том же кол-ве которые
сам закрыл (в логах ошибок небыло), лучше бы Nginx повторно их использовал,
в общем установили keepalive 250 и Nginx перестал постоянно открывать и
закрывать соединения.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266693,267196#msg-267196

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-27 Пенетрантность S.A.N
> > Кстати почему по дефолту keepalive_requests имеет такое маленькое
> значения -
> > 100?
> 
> Это опция относится только к клиентскому соединению.

Наши бекенды открывают клиентские соединения к другим нашим бекендам, по
этому пришлось значительно увеличить keepalive_requests.

Я хотел узнать, если по умолчанию 100, возможно на это есть какие-то
низкоуровневые причины и наше увеличения до 10 000, может негативно
сказаться, на практике проблем не заметил.

Или keepalive_requests это просто историческая дань проблемам Apache?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266693,267194#msg-267194

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-27 Пенетрантность S.A.N
> зачем огромные ?
> 
> значение keepalive - это "запас", соединения, которые держатся
> подгретыми
> на всякий случай.
> если у вас нагрузка носит однородный характер, то они будут
> простаивать

У нас 250 keepalive на upstream, начинали с 8, потом имперически
увеличивали, обычно они не простаивают.

Кстати почему по дефолту keepalive_requests имеет такое маленькое значения -
100?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266693,267191#msg-267191

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-26 Пенетрантность S.A.N
Илья Шипицин Wrote:
---
> а вы настройте keepalive между nginx и бекендами.

Да, этим и спасаемся, у нас огромные значения keepalive в upstream :)

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266693,267180#msg-267180

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-26 Пенетрантность S.A.N
>  Конечно, мультиплексирование в FastCGI будет легче чем в HTTP/2.
> 
>  Но само по себе мультиплексирование не является самоцелью, оно может
>  быть уместно в каких-то вычурных ситуациях (вроде исчерпания
> сокетов),
>  которые на самом деле разруливаются другими методами.

Подскажите где почитать про другие эффективные методы решения дефицита
свободных fd в линуксе?

Сейчас fd улетают как горячие пирожки, реал юзкейс

Nginx, получает соединения от клиента, открывает соединения к бекенду, а
бекенд открывает 30 соединений к Nginx для получения 30 JSON ответов от
других бекендов, нам же приходится каждый запрос делать в отдельном
соединение чтобы Nginx и бекенды могли параллельно их обрабатывать, вот для
этой пустяковой задачи мы уже потратили 93 fd.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266693,267166#msg-267166

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-24 Пенетрантность S.A.N
> > Nginx никогда не посылает запрос в то же соединение, пока не
> получит
> > ответ
> > и соединение освободиться.  Т.н. pipelining он не умеет и не
> > использует.
> > 
> > Если бы следующий запрос пришел до того, как на первый был получен
> > ответ,
> > то он бы был отправлен на бекенд в другом соединении.
> > 
> > Т.е. никакой проблемы между nginx и бекендом нет.
> 
> Да, конечно Nginx не пошлет второй и третий запрос на бекенд, пока
> первый не ответит, в этом и проблема, потому что он ждет ответа на
> первый запрос, я бы ещё понял если бы Nginx не ждал ответа на первый
> запрос и отправил второй и третий запрос в другом свободном конекте
> или открыл новый конект, но Nginx эти запросы будет держать в очереди
> и это очень плохо.
> Могу выслать код теста.
> 

Я ещё раз проверил, Nginx разносит три запроса из одного клиенского
соеденения, по разным соединениям бекенда только если клиент сделал запросы
по протоколу HTTP/2, если клиент сделает эти три запроса по протоколу
HTTP/1.1, тогда Nginx никогда не разносит запросы из одного клиентского
соединения по разным соединениям бекенда.

Проверил на Nginx/1.9.15 без стороних модулей.
Я здесь выложу исходники тест скриптов, они не большие и результат, я
тестировал в nc чтобы убедится что все три запроса отправляются в одном
соединение.

В роли бекенда может быть все что угодно, главное чтобы бекенд умел
принимать и паралейно выполнять новые соеденения, даже FPM с тремя воркерами
подойдет.

Три РНР скрипта:

-- 1.php
--
https://forum.nginx.org/read.php?21,266693,267096#msg-267096

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-24 Пенетрантность S.A.N
> Вы просто перенесете то, что реализовано в ядре операционной системы
> внутрь приложения.  В случае HTTP/2 у вас будет на каждый отдельный
> запрос свой внутренний идентификатор со своими накладными расходами,
> который точно также будет "простаивать" пока запрос обрабатывается.
> 
> У вас уже есть мультиплексирование на уровне TCP/IP.
> 
> HTTP/2 - это коробочка в коробочке.


Провел простые тесты, получил интересные результаты.

Браузер делает три аякс запроса

GET /one HTTP/1.1
GET /two HTTP/1.1
GET /three HTTP/1.1

Протокол клиента HTTP/1.1 все три запроса браузер отправляет в одном
конекте.
Nginx отправляет все эти три запроса в одном конекте на бекенд.

Теперь смотрим как все плохо в HTTP/1.1 когда в одном конекте приходит
очередь HTTP запросов, допустим время ответа у нас такое:

GET /one HTTP/1.1 -- 500ms
GET /two HTTP/1.1 -- 20ms
GET /three HTTP/1.1 -- 10ms

Бекенд многопоточный, он бы мог принять и обработать второй и третий запрос,
не дожидаясь обработки первого медленного запроса.

Есть три варианта как это сделать:

1. Бекенд читает все запросы из сокета и обрабатывает асинхроно, ответы
буферизирует чтобы отправить в том же порядки как пришли запросы.

2. Перейти на НТТР/2 для работы бекенда с Nginx, но этого нет в планах
Nginx

3. Если сделать свой велосипед, использовать $request_id для связи ответов и
запросов, тогда бекенд сможет отвечать асинхроно, будет в зоголовке
указывать $request_id запроса на который он отвечает, Nginx клиенту отправит
ответы в той же последовательности как клиент прислал запросы.


Я не люблю велосипеды ($request_id) но если Nginx не планирует
мультиплескирования (НТТР/2 или FastCGI) в апстримах, возможно это неплохой
компромис, как вы считаете?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266693,267088#msg-267088

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-10 Пенетрантность S.A.N
> Откуда такая арифметика?

Цифры условные - допустим многопоточный бекенд, имеет 10 потоков, каждый
поток может работать со скоростью 1к RPS.
Задача получить от одного бекенда 10к RPS
На НТТР1.1 нужно как минимум открыть 10 конектов, тогда бекенду очень просто
привязать каждый конект к своему отдельному потоку.
На НТТР2.0 нужно как минимум открыть 1 конект, но бекенду придется
самостоятельно распределять каждый запрос между внутренним пулом потоков.

Да, вы меня переубедили, мне уже больше нравится НТТР1.1, без
мультиплексирования :)

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266737,266770#msg-266770

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-10 Пенетрантность S.A.N
> Также как и h2 внутри датацентра не нужен.  Это протокол заточенный
> под общение
> браузера с веб-сервером ради экономии на TLS-хэндшейках по сетям с
> относительно
> высокой задержкой и в условиях крайне ограниченного количества
> параллельных
> соединений.
> 
> Не стоит забивать микроскопы гвоздями.

Если я правильно вас понял, вы считаете что H2 мультиплексирование запросов
даст меньший прирост скорсти, из-за суммарного оверхеда самого протокола H2?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266737,266746#msg-266746

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-07 Пенетрантность S.A.N
Наш бекенд работает на HTTP/1.1 в режиме Keep-Alive, но в пикоквые нагрузки,
нам приходится держать много открытых конектов.

Демон асинхронный, но если один запрос выполняется дольше обычного конект
параллельно использовать для других запросов уже не выйдет он просто ждет,
хотелось бы попробовать H2 мультиплексирования, но без SSL он не нужен
внутри датацентра.

Имплементация H2 без SSL, для проксирования бекендов, есть в планах Nginx?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266693,266693#msg-266693

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ревалидация кеша fastcgi

2016-05-04 Пенетрантность S.A.N
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;
> >
> > У вас в конфиге написано: установить заголовки If-None-Match и
> > If-Modified-Since в запросах к бекенду в полученные от клиента
> > значения.  Ревалидация кеша в таких условиях работать не может по
> > очевидным причинам.
> 
> убрал эти строки. удалил кеш. ристартанул nginx
> первая загрузка X-My-Cache: MISS (страницы нет в кеше)
> вторая загрузка X-My-Cache: HIT (есть в кеше, получаю закешированную
> версию)
> жду 10 секунд
> третья загрузка X-My-Cache: EXPIRED
> 
> (а я ожидаю X-My-Cache: REVALIDATED )
> 

Вы изначально в ответе отдавали заголовки валидаторы (ETag и/ил
Last-Modified)?
Посмотрите на содержимое в папке кеша Nginx, есть ли там заголовки ETag и/ил
Last-Modified, без них ревалидация кеша невозможно.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266607,266612#msg-266612

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: ревалидация кеша fastcgi

2016-05-04 Пенетрантность S.A.N
Судя по конфигу, у вас проблема с куками, если браузер присылает куки
сессии, кеш не работает, curl куки не присылает, ответ отдается из кеша.

Убери из конфига
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; 
Они не нужны

На бекенде в РНР, отвечайте http_response_code(304); вместо header('HTTP/1.0
304 
Not Modified'); так быстрей и правильней.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266607,266608#msg-266608

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Reuse cache Nginx, for any microservices

2016-04-29 Пенетрантность S.A.N
Здравствуйте.

Мы все больше используем микросервисы, они имеют уникальные uri, выполняют
атомарные операции и отдают JSON ответы, их проксирует и кеширует Nginx.

В этих бекенд микросервисах, часто появляются задачи для решения которых
нужны ответы от других бекенд микросервисов, приходится внутри одного бекенд
микросервиса делать http запросы к другим бекенд микросервисам, через Nginx,
он нужен для балансировки и кеша, это все хорошо, но относительно медленно,
несмотря на то что ответы получаем как правило из кеша Nginx.

Я думаю как это дело можно оптимизировать, первое что приходит в голову
сделать в Nginx ещё один виртуал сервер, который будет использовать те же
upstream и туже кеш зону, но без SSL, и других лишних опций, этот вирт
сервер будет слушать юникс сокет, каждый микросервис (они все демоны) будет
держать постоянный открытый конект к этому юникс сокету, и HTTP методом GET
получать нужные кеши от других микросервисов.

Не уверен что этот велосипед оптимальный, возможно есть лучшие варианты?
Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266537,266537#msg-266537

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Slice cache

2016-04-19 Пенетрантность S.A.N
Maxim Dounin Wrote:
---
> Hello!
> 
> On Tue, Apr 19, 2016 at 03:24:37AM -0400, S.A.N wrote:
> 
> > > По умолчанию range-запросы из кеша работают только в том случае, 
> > > если в ответе бекенда был заголовок Accept-Ranges и должна быть 
> > > явно указана длина ответа.
> > 
> > Супер, спасибо, отдали Accept-Ranges все работает.
> > 
> > Кстати есть ли смысл бекенду сжимать (gzip) свой ответ, если клиенты
> > запрашивают кеш частично (Range)?
> > Я так понимаю что в этом случаи Nginx каждый раз надо разжимать
> большой
> > ответ, потом сжимать часть которые запросил клиент.
> 
> Я бы не стал.
> 
> Сжатие на лету исключает возможность использования range-запросов, 
> т.к. сжимается весь ответ целиком и результат сжатия может быть 
> разный в зависимости от временных факторов, а range-запросы должны 
> применяться к уже сжатому ответу.  Для range-запросов могло бы 
> работать сжатие на уровне передачи по http ("Transfer-Encoding: 
> gzip"), но оно практически нигде не поддерживается.
> 
> Можно пытаться детерминировано сжимать на бекенде, и 
> соответственно потом из кеша nginx будет раздавать сжатый файл с 
> учётом range-запросов, но разжимать это nginx не сможет, либо же 
> пропадёт возможность использовать range-запросы для расжатого 
> ответа (потому что нужна явно заданная длина, см. предыдущий 
> ответ, а длина при расжатии заранее неизвестна).
> 

Понял, спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266232,266257#msg-266257

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Slice cache

2016-04-19 Пенетрантность S.A.N
> По умолчанию range-запросы из кеша работают только в том случае, 
> если в ответе бекенда был заголовок Accept-Ranges и должна быть 
> явно указана длина ответа.

Супер, спасибо, отдали Accept-Ranges все работает.

Кстати есть ли смысл бекенду сжимать (gzip) свой ответ, если клиенты
запрашивают кеш частично (Range)?
Я так понимаю что в этом случаи Nginx каждый раз надо разжимать большой
ответ, потом сжимать часть которые запросил клиент.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266232,266247#msg-266247

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Slice cache

2016-04-18 Пенетрантность S.A.N
Здравствуйте.

Я хотел бы узнать, Nginx умеет отдавать клиентам из своего кеша, ответы
частями?
Корректный заголовок Range: bytes... клиент отправляет, но Nginx из кеша
отдает весь ответ статус - 200, вместо частичного ответа со статусом 206.

По сути нужен функционал обратный модулю Slice.

Наш use case:
Бекенд отдает, большой ресурсоемкий ответ (аналитик отчет - это результат
многих сложных SQL) разным клиентам в разное время нужны только части этого
отчета и иногда весь целиком. Модуль Slice только усложнит ситуацию, потому
что он сгенерирует много подзапросов на бекенд, вот именно этого и нужно
избежать, чтобы бекенд не генерировал куски отчета много раз, а один раз
сделал полный отчет и отдал в кеш Nginx.

Надеюсь это можно сделать.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266232,266232#msg-266232

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Acept systemd.socket

2016-03-19 Пенетрантность S.A.N
>  И более правильным, потому что независимо от чей-то любви к
> systemd.socket
>  в данном случае он поставленную задачу НЕ решает. Всяко лучше
> устранить
>  проблему полностью, чем уменьшить её вероятность на несколько
> процентов.

systemd.socket задачу решает, тесты показали что он заметно раньше готов
принимать конекты, потом Nginx их принимает, проверил через прокси
/usr/lib/systemd/systemd-socket-proxyd 0.0.0.0:80

Я не большой специалист в сетевых интерфейсах, если не сложно объясните мне
простыми словами, почему systemd.socket не решает мои задачи?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,265330,265394#msg-265394

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Acept systemd.socket

2016-03-19 Пенетрантность S.A.N
Валентин Бартенев Wrote:
---
> Это довольно странное желание - чтобы машина, которая по сути ещё не
> готова
> к работе, частично делала вид, что она готова принимать трафик.  Что
> вы будете
> делать если nginx так и не заработает через 700 мс, а балансировщик
> уже
> радостно нальет на неё трафик?
> 
> Почему вы считаете, что эти 700 мс куда-то теряются, хотя тем временем
> они
> могли бы быть обслужены живой машиной за меньшее время?
> 
> А сколько секунд теряется на биос и загрузку ядра?  В чем разница?
> 
> Т.н. HA обеспечивается вовсе не такими методами.  Больше похоже на
> способ
> тщательно разложить самому себе грабли у входа.

Вы правы, это желания появилось, после нашей реализации активаций бекендов
по systemd.socket, мне это так понравилось что захотел все перевести на
systemd.socket, Nginx в том числе, но согласен практического смысла в этом
мало.

Вот как выкручиваются те кому это действительно надо
https://developer.atlassian.com/blog/2015/03/docker-systemd-socket-activation/

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,265330,265496#msg-265496

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

  1   2   3   >