sigmask — это вообще про обработчики сигналов. И единственное отличие pselect() от select() в наличии дополнительного аргумента, который позволяет переопределить обработку сигналов на время вызова select().
Опять же, обратимся к man:
sigmask is a pointer to a signal mask (see sigprocmask(2)); if it is not NULL, then pselect() first replaces the current signal mask by the one pointed to by sigmask, then does the "select" function, and then restores the original signal mask.
Ну и man signal процитирую:
Signal mask and pending signals
A signal may be blocked, which means that it will not be delivered until it is later unblocked. Between the time when it is generated and when it is delivered a signal is said to be pending.
Each thread in a process has an independent signal mask, which indicates the set of signals that the thread is currently blocking.
По маске пробегать относительно дешево, а написано другое, я же процитировал: нам приходится обрабатывать все наши коннекты и проверять их на получение данных, делая с них read
У select есть большой недостаток — мы не можем знать, какое именно событие произошло и с каким именно сокетом. Каждый раз, когда мы получаем процессорное время, нам приходится обрабатывать все наши коннекты и проверять их на получение данных, делая с них read. Если у нас будет 1000 соединений, а данные придут только по одному из них, то мы обработаем все 1000 соединений, чтобы найти нужный.
Тут написана неправда. Процитирую man: On exit, the sets are modified in place to indicate which file descriptors actually changed status.
Все родные модули написаны с учетом асинхронной архитектуры. С XSLT должно быть всё нормально, за исключением каких-то экстремальных случаев, когда у вас такой шаблон, что требует несколько секунд процессорного времени на обработку.
Просто многие авторы сторонних модулей не понимают как устроен nginx и в своих модулях могут блокировать обработку событий на долгое время (что недопустимо), например, подключаясь и запрашивая базу данных в блокирующем режиме.
На самом деле время обновляется каждую итерацию цикла обработки событий. В нормальной ситуации события обрабатываются мгновенно. Если у вас итерация обработки событий затянулась на секунды, то скорее всего это следствие кривого стороннего модуля, который заблокировал nginx или сервер уже не справляется с нагрузкой (рабочий процесс nginx оказался выгружен в своп, ему не дают процессорного времени или заблокирован на диске).
Стандарты пишутся точно такими же людьми. И помимо того, что людям в принципе свойственно ошибаться, авторы стандартов не всегда умнее разработчиков, которые по этим стандартам что-то реализовывают. Иногда, ради безопасности или эффективности, где-то приходится отступать от стандарта и думать своей головой.
Совсем недавно — это почти два года назад, начиная с nginx 1.9.0. =)
Исключить можно, для этого есть опция down у директивы server в блоке upstream. Не считая ряд сторонних модулей, есть статистика для бесплатной версии nginx в виде сервиса.
SSL или не SSL, а также детали соединения — не являются частью URI.
Типичный HTTP/1.1-запрос выглядит так:
GET /blog HTTP/1.1
Host: example.com
User-Agent: Mozilla...
Accept: text/html
и он так выглядит вне зависимости от того, по SSL/TLS он сделан или поверх голого TCP.
URI в данном случае /blog. POST-запросы с этой точки зрения выглядят точно также, только еще содержат тело. Так что ваша фраза:
На стороне nginx не реально воссоздать GET запрос и реальный IP-адрес клиента (какие данные точно не передаются сейчас не скажу). С телом POST и т. п. запросов проблем как раз не заметил
вообще лишена смысла.
Если вам обязательно знать, используется ли SSL/TLS или нет на соединении с клиентом с haproxy, так разнесите также эти соединения по разным портам. Пусть haproxy проксирует либо на один порт, либо на другой. В чем проблема?
Либо можно выкинуть haproxy, поставить nginx на его место — и тогда будет счастье. Всю информацию можно будет передавать в заголовках.
Я более-менее разбирал этот вопрос в статье.
sigmask — это вообще про обработчики сигналов. И единственное отличие pselect() от select() в наличии дополнительного аргумента, который позволяет переопределить обработку сигналов на время вызова select().
Опять же, обратимся к man:
sigmask is a pointer to a signal mask (see sigprocmask(2)); if it is not NULL, then pselect() first replaces the current signal mask by the one pointed to by sigmask, then does the "select" function, and then restores the original signal mask.Ну и man signal процитирую:
Signal mask and pending signalsA signal may be blocked, which means that it will not be delivered until it is later unblocked. Between the time when it is generated and when it is delivered a signal is said to be pending.Each thread in a process has an independent signal mask, which indicates the set of signals that the thread is currently blocking.Ок. Вы изменили комментарий. =)
Но замечу, что пробегать по всей маске не нужно. А только по дескрипторам, на которых мы ожидаем получение события.
А, пардон, код в примере маску всё же проверяет. Но комментарий опять же вводит в заблуждение:
//Читаем данные из каждого сокета, так как не знаем какие события заставил ОС дать нам CPUПо маске пробегать относительно дешево, а написано другое, я же процитировал: нам приходится обрабатывать все наши коннекты и проверять их на получение данных, делая с них read
И код в примере именно так и делает зачем-то.
Тут написана неправда. Процитирую man:
On exit, the sets are modified in place to indicate which file descriptors actually changed status.Все родные модули написаны с учетом асинхронной архитектуры. С XSLT должно быть всё нормально, за исключением каких-то экстремальных случаев, когда у вас такой шаблон, что требует несколько секунд процессорного времени на обработку.
Просто многие авторы сторонних модулей не понимают как устроен nginx и в своих модулях могут блокировать обработку событий на долгое время (что недопустимо), например, подключаясь и запрашивая базу данных в блокирующем режиме.
На самом деле время обновляется каждую итерацию цикла обработки событий. В нормальной ситуации события обрабатываются мгновенно. Если у вас итерация обработки событий затянулась на секунды, то скорее всего это следствие кривого стороннего модуля, который заблокировал nginx или сервер уже не справляется с нагрузкой (рабочий процесс nginx оказался выгружен в своп, ему не дают процессорного времени или заблокирован на диске).
Это что-то новенькое. Можно подробнее?
Стандарты пишутся точно такими же людьми. И помимо того, что людям в принципе свойственно ошибаться, авторы стандартов не всегда умнее разработчиков, которые по этим стандартам что-то реализовывают. Иногда, ради безопасности или эффективности, где-то приходится отступать от стандарта и думать своей головой.
Совсем недавно — это почти два года назад, начиная с nginx 1.9.0. =)
Исключить можно, для этого есть опция
downу директивыserverв блокеupstream. Не считая ряд сторонних модулей, есть статистика для бесплатной версии nginx в виде сервиса.Вот nginx умеет UDP. Какой-нибудь DNS прекрасно балансируется.
Он уже научился балансировать HTTP/2 и UDP? =)
Если nginx работает слишком быстро, то его можно конечно притормозить с помощью Varnish, но я бы не советовал. =)
Обращаю внимание на две бессмысленные директивы
fastcgi_split_path_infoиfastcgi_indexвlocation ~* \.php$. Это либо ошибка, либо копипаста.Самый ужасный браузер с точки зрения поддержки стандартов. Критические баги в реализации HTTP/2 годами не исправляют, зато "быстрее и комфортнее".
SSL или не SSL, а также детали соединения — не являются частью URI.
Типичный HTTP/1.1-запрос выглядит так:
и он так выглядит вне зависимости от того, по SSL/TLS он сделан или поверх голого TCP.
URI в данном случае
/blog. POST-запросы с этой точки зрения выглядят точно также, только еще содержат тело. Так что ваша фраза:вообще лишена смысла.
Если вам обязательно знать, используется ли SSL/TLS или нет на соединении с клиентом с haproxy, так разнесите также эти соединения по разным портам. Пусть haproxy проксирует либо на один порт, либо на другой. В чем проблема?
Либо можно выкинуть haproxy, поставить nginx на его место — и тогда будет счастье. Всю информацию можно будет передавать в заголовках.
URI никогда не передается по proxy protocol, это уже часть HTTP запроса, которых может быть много в одном соединении. Спецификация тут: http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt
Всё должно работать без проблем, если правильно настроить. Реальный IP передается через proxy protocol.
Нет, они такие же. Правки там сделаны только для того, чтобы оно собиралось правильно с новыми версиями.