• Nginx cache: всё новое — хорошо забытое старое
    0
    Вы смешали действие директив proxy_ignore_headers и proxy_hide_header. Директива proxy_ignore_headers не уберет заголовок из ответа клиенту, а лишь предотвратит его влияние на кэшируемость ответа.

    Если вы хотити чтобы заголовок не передавался клиенту, то необходимо использовать директиву proxy_hide_header.
  • Nginx cache: всё новое — хорошо забытое старое
    0
    Да.
  • Newtoo — разработка полноценного браузерного движка с нуля в 2018?
    +3
    Установка соединения (SYN->ACK->ACK) с передачей cookies для каждого запроса дает лишнюю нагрузку на сервер и на канал. Для одного клиента она не существенна, но когда клиентов тысячи, она внезапно начинает играть свою роль. А если мы вспомним, что внутри у нас plain text, то становится еще грустнее.
    Нагрузка от TCP хэндшейка просто смешная по сравнению с дополнительной нагрузкой, которую дает реализация ещё одного пакетного слоя для мультиплексирования и ещё одного flow control внутри соединения. Для работы HTTP/2 требуется больше накладных расходов и больше пересылать TCP-пакетов, а также расходуется больше памяти и больше процессорных ресурсов. А внутри по сути такой же plain text, который также нужно парсить.

    Безусловно. Только сами cookies появилсь, чтобы сервер мог хоть как-то хранить на клиенской машине информацию и различать сессии между собой. Исторически, это был именно костыль.
    А как нужно их хранить и где по вашему? В чём же заключается «костыль» и кто мешает хранить простой ключ сессии, как в общем-то многие и делают?

    Но иногда требуется отбросить обратную совместимость и дать дорогу чему-то принципиально новому.
    Наверное такие решения должны прорабатываться, обсуждаться и приниматься с особой осторожностью, чтобы не сломать то, что работает годами, не сделать хуже. А сейчас мы видим то, что большие корпорации проталкивают свои протоколы в своих корыстных целях, при этом заставляя всех остальных страдать. Как в своё время было с Microsoft и IE, сейчас то же самое происходит, только в руках одной мегакорпорации оказались, как самые популярные браузеры так и самые посещаемые веб-ресурсы, а потому они в результате затачивают веб под себя, наплевав на остальных. Имея при этом большие маркетинговые ресурсы, они всё это подают под соусом улучшений и инноваций, легко одурачивая основную массу, которая плохо себе представляет работу сетевых протоколов и повторяет из статьи в статью одни и те же заблуждения касательно HTTP/1 vs 2.
  • Newtoo — разработка полноценного браузерного движка с нуля в 2018?
    0
    Учитывая, что все дистрибутивы потихоньку переползают на вейленд — странно писать о том, что он не взлетел.

    Не стоит путать легаси с надежным, проверенным временем решением. Должна происходить постепенная эволюция, а не революции с майданами. Когда горячие головы, терзаемые NIH-синдромом без десятков лет опыта за плечами, приходят с лозунгами: «а давайте всё перепишем!» — ничего хорошего на выходе не получается.

    Достаточно коротко и ясно происходящее описал легендарный Poul-Henning Kamp в своей заметке: queue.acm.org/detail.cfm?id=2716278
  • Newtoo — разработка полноценного браузерного движка с нуля в 2018?
    +7
    Однако, одно соединение на один запрос довольно избыточно.
    В чем заключается избыточность?
    В чем, по вашему, правильность данного метода?
    В том, что TCP это протокол транспортного уровня и проблемы транспортного уровня должны решаться на транспортном уровне. Один запрос — это один поток данных. Один поток данных — одно независимое TCP соединение. Это правильно, это позволяет применять flow control на уровне каждого потока, а также роутить эти запросы независимо друг от друга. Они могут обрабатываться разными серверами, они могут идти разными маршрутами. Всё это позволяет лучше масштабировать нагрузку и лучше справляться с ошибками.

    Даже для реализации «сессии» пришлось придумывать костыли.
    В чем заключаются костыли? HTTP — это stateless протокол, благодаря этому он очень хорошо масштабируется, с помощью него можно реализовать удобный и красивые RESTfull интерфейсы. Не будь он stateless, костыли бы пришлость расставлять повсюду.

    Теперь каждый второй сайт уведомляет о том, что он использует cookie и просит понять и простить. А все из-за того, что «это правильно, так и должно быть».
    Смешались в кучу кони, люди, мухи, котлеты… Каждый второй сайт уведомляет об использовании cookies согласно новому закону евросоюза. Это не имеет никакого отношения к протоколам, а является законодательным актом.

    Более того, работа с cookies и сессиями, как и вся остальная семантика HTTP — совершенно одинаковая, что в HTTP/1.1, что в HTTP/2 и SPDY.

    Работу с сессиями вероятно можно было бы улучшить, но это никак не связано с количеством TCP соединений, и ни HTTP/2, ни SPDY — вообще ничего в этом отношении не улучшают.
  • Newtoo — разработка полноценного браузерного движка с нуля в 2018?
    0
    HTTP/2 объективно очень плохой протокол и не является заменой HTTP/1.x. Нет у него будущего.
  • Newtoo — разработка полноценного браузерного движка с нуля в 2018?
    +4
    HTTP до сих пор использует отдельное TCP соединение для каждого нового запроса
    И это правильно, так и должно быть. А от того ужаса, который вышел в виде SPDY и HTTP/2 ещё долго придется плеваться. И да, в результате в SPDY и HTTP/2 гораздо больше накладных расходов.
  • Nginx-переменные с njs: просто, безболезненно и через JavaScript
    +2
    Это неправда — Perl отлично умеет обрабатывать ошибки, просто некоторые привыкли писать как модули так и приложения где предпочитают завершать процесс в случае ошибок (djb style).
    Я имел в виду как раз ошибки выделения памяти.

    Но если уж дошло до нехватки памяти, то вполне логично убить весь процесс — ибо ситуация уже нестабильна, и скорее всего любое другое действие тоже приведет к проблемам (или будет периодически приводить пока система балансирует на границе голодания).
    Это логично в рамках одноразового скрипта, но абсолютно неприемлемо для веб-сервера в высоконагруженных системах. В nginx для корректной и максимально гладкой обработки ошибок выделения памяти проделано много работы. Под пиковыми нагрузками система может упереться во что угодно, в том числе в нехватку памяти, дескрипторов, места на жестком диске и при этом сервер должен продолжать держать нагрузку, завершая с ошибкой лишь часть запросов, которые превышают возможности системы. Падение в такие момент недопустимо.

    Более того, ошибка выделения памяти может быть связана не с нехваткой памяти, а с ошибкой в коде или недостаточно качественной фильтрацией данных от пользователя. Как результат какой-то HTTP-запрос может приводить к попытке выделить гигантский объем памяти и это не должно ронять целиком сервер, а завершать ошибкой только один конкретный запрос.
  • Nginx-переменные с njs: просто, безболезненно и через JavaScript
    +3
    В конфигурации nginx все переменные работают и устанавливаются в рамках обработки запроса, а не при чтении конфигурации. Переменных на уровне конфигурации нет, она читается единожды на старте. И в этом смысле вообще никакой «асинхронный процессинг конфига» не требуется.

    Я вовсе не противник njs, но пока что он не предоставляет принципиальных преимуществ перед perl-модулем.
    Принципиальное приемущество в том, что njs — это решение пригодное для использования в продакшене под высокой нагрузкой, а Perl — нет. Когда интерпретатор Perl-а не может выделить себе память, он убивает весь nginx, поэтому использовать его можно только на свой страх и риск, в надежде, что памяти всегда хватит, особенно под высокой нагрузкой.
  • Nginx-переменные с njs: просто, безболезненно и через JavaScript
    +2
    Работа с файлами, базами, сетью на уровне конфига не предполагается.

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

    Но мой комментарий про неполноценность встраиваемости перла относился скорее к тому, что Perl не умеет нормально обрабатывать ошибки и при любом удобном случае просто завершает весь процесс, что неприемлемо в рамках асинхронного сервера, обрабатывающего тысячи запросов.
  • Nginx-переменные с njs: просто, безболезненно и через JavaScript
    +3
    Perl невозможно было полноценно встроить, поэтому он всегда был в состоянии экспериментального и не развивался. С JS-модулем совсем другая история, это уже полноценный скриптиг с растущими от релиза к релизу возможностями.
  • Красивый листинг файлов и директорий в nginx
    0
    Довольно странное решение, учитывая, что autoindex в nginx может выдавать данные в формате JSON или XML. Чтобы затем получить из этого красивую страничку, нужен либо xslt на стороне сервера, либо тот же JavaScript на стороне клиента.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Я правильно понял или пока нет разделения на route? Т.е. проксируется от корня и все подряд? И Server_name пока нигде не фиксируется.
    Да.
    Это будет в дальнейшем?
    Да.
  • Почему один процесс NGINX берёт на себя всю работу?
    +1

    По умолчанию он был выключен только относительно недавно, в последних версиях. До этого был по умолчанию включен. А ещё многие начитавшись всяких статеек любили добавлять accept_mutex on.


    Собственно одной из причин его выключить было, что нам надоели горе-бенчмаркеры, которые запускают nginx и после запуска, без нагрузки рабочие процессы отключают нотификацию о новых соединениях и уходят спать на accept_mutex_delay. После чего бенчмаркер запускает свой славный микробенчмарк и все соединения ловятся одним рабочим процессом, поскольку другие отключили нотификацию.

  • Почему один процесс NGINX берёт на себя всю работу?
    +1
    Почему один процесс NGINX берёт на себя всю работу?
    Потому что accept_mutex включен. Выключите и будет счастье.

    В случае epoll-and-accept алгоритм другой: Linux, кажется, выбирает процесс, который был добавлен в очередь ожидания новых соединений последним, т.е. LIFO.
    AFAIK, с флагом EPOLLEXCLUSIVE это не так и ждуны добавляются в конец очереди.
  • Инструкция как скомпилировать динамический модуль ngx_pagespeed для Nginx на Debian
    +1
    Люди, включающие pagespeed и удивляющиеся почему nginx на 10 rps начинает упираться в cpu, приходят периодически.
  • Инструкция как скомпилировать динамический модуль ngx_pagespeed для Nginx на Debian
    +2
    В попытках делать на лету то, что при грамотном подходе должно происходить единожды при развертывании новой версии сайта, может легко привести к крайне низкой производительности, высокому потреблению памяти и проблемам со стабильностью. Зато попугаи в неком сервисе будут радовать глаз и не важно, что сайт тормозит и ложиться под нагрузкой.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Сейчас Go планируется ставить из пакета, версия которого будет всегда совпадать с версией юнита в репозитории. В случае github разработчик будет вынужден сам следить за тем, чтобы клонировался нужный бранч. Неужели так удобнее? Пакетный менеджер придумали специально чтобы этим не заниматься.
  • Ожидание длиной в 15 лет. Nginx Application Server
    +1
    Пока никак. Планируется, приоритет высокий.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Конечно. Это вполне базовая функциональность сервера приложений, которая должна быть.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Ни кто не мешает указать вместо ip-адреса unix-сокет. =)
  • Ожидание длиной в 15 лет. Nginx Application Server
    +1
    Один нюанс, в дальнейшем большой nginx может стать совсем ненужным и данные будут передаваться прямо клиенту.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Это не CGI запускалка. У нас собственный SAPI модуль для php по типу как php-fpm, так что потенциально всё должно работать, включая opcache и кэш соединений. Сейчас opcache уникален для каждого процесса, позже научим юнит разделяемому между процессами кэшу.

    По поводу бенчмарков ответил выше.
  • Ожидание длиной в 15 лет. Nginx Application Server
    +1
    На данный момент там много всякого дебага и часть кода написана в стиле «proof-of-concept». Сейчас сравнивать производительность бессмысленно. Но архитектура спроектирована так, чтобы добавлять минимум накладных расходов и выжать максимум из приложений. К моменту выпуска первой стабильной версии доведем до ума и можно будет тестировать.
  • Ожидание длиной в 15 лет. Nginx Application Server
    +1
    Да, планируется поддержка расширение возможностей, как для самих запускаемых языков, так и обвязки в целом. Важность virtualenv прекрасно понимаю, всё будет.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Что должен делать auto в данном случае? Сколько процессов запускать?
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Такая возможность будет. Пока мы в стадии ранней беты, но планируем довести стабильность и функциональность до хорошего состояния и выпустить осмысленный релиз в начале 2018. Сейчас можно просто покрутить, поиграться, написать побольше фичреквестов.
  • Ожидание длиной в 15 лет. Nginx Application Server
    +2
    Сокеты это лишние накладные расходы. Там все сложнее. Он общается с процессами юнита посредством нашего RPC, который построен на разделяемой памяти. Модуль как раз подсоединяет приложение на Go к этому RPC, когда запускается процессом юнита.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Почему не будет? Кто помешает поставить его из репозитория, так же как и Go?
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Для разработки, почему нет. Не в систему же мне его после каждой правки кода ставить. =)

    ebuild конечно хорошо было бы сделать и положить в репозиторий дженту.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Application на python — это собственно сам набор python скриптов, их собирать не надо, они компилируются в опкод самим cpython. Для запуска ваших .py скриптов с нужной версией cpython необходимы лишь соответствующие модули для юнита собранные с соответствующими версиями cpython. Пакеты с модулями юнита можно установить из репозитория, либо собрать самостоятельно.

    Во многих дистрибутивах сейчас как минимум две версии cpython, ветки 2 и ветки 3. Соответственно и пакеты для них мы будем собирать сами, либо это будут делать майнтейнеры дистрибутива.

    А если вам нужен какой-то особенный cpython, которого нет в репозиториях, то вы же его собираете так или иначе. Просто соберите динамический модуль для юнита с ним и юнит сможет его загружать и использовать для запуска ваших приложений на пайтоне.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Например, как при помощи nginx application можно будет запустить проекты, которые требует разные версии одной библиотеки?
    В статье выше люди запускают две разных версии PHP, каждая использует свою собственную libphp.so (которые в свою очередь могли быть собраны со своими зависимостями). Я запускал одновременно приложения на 3-х разных версиях PHP, 2-х версиях Python и Go. Вообще это ни чем не ограничено.

    Магия и секретные технологии. =)
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
  • Ожидание длиной в 15 лет. Nginx Application Server
    0

    Пока что тут: http://unit.nginx.org/docs-installation.html#building-the-go-applications
    Документация будет улучшаться. Это пока первые эскизы.


    Если кратко, то вся модификация Go приложений для запуска в Unit сводится к добавлению модуля unit:


    import {
        "fmt"
        "net/http"
        "unit"
    }

    и замене обработчика
    http.ListenAndServe(":8080", nil)
    на
    unit.ListenAndServe(":8080", nil)
    при этом заданный порт имеет значение только при запуске вне юнита, в этом случае происходит фоллбек в http.ListenAndServe(). Юнит указанный порт игнорирует, слушающий сокет уже конфигурируется в самом юните.

  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Верно. Мы не проксируем на Go, мы заменяем его сетевую либу.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Unit уже опенсорс и бета-версию можно скачать и попробовать.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Приблизительно. Я лишь добавлю, что предполагается удобное и единообразное конфигурирование, так что будет проще использовать и без зоопарка, для своего личного блога, например.

    Обучить статике и редиректам — вопрос времени.
  • Ожидание длиной в 15 лет. Nginx Application Server
    0
    Ответил выше.
  • Ожидание длиной в 15 лет. Nginx Application Server
    +1
    Сегодня на конференции подходил человек из Microsoft, то же самое спрашивал. Возможно, надо смотреть.
  • Ожидание длиной в 15 лет. Nginx Application Server
    +4

    Я, например, вот так у себя в gentoo собираю три разных php-модуля для юнита:


    $ ./configure php --module=php56 --config=/usr/lib64/php5.6/bin/php-config --lib-path=/usr/lib64/php5.6/lib64
    
    $ ./configure php --module=php70 --config=/usr/lib64/php7.0/bin/php-config --lib-path=/usr/lib64/php7.0/lib64
    
    $ ./configure php --module=php71 --config=/usr/lib64/php7.1/bin/php-config --lib-path=/usr/lib64/php7.1/lib64```