Представлен (http://mailman.nginx.org/pipermail/nginx-announce/2019/00024...) первый выпуск новой основной ветки nginx 1.17 (http://nginx.org), в рамках которой будет продолжено развитие новых возможностей (в параллельно поддерживаемой стабильной ветке 1.16 (https://www.opennet.ru/opennews/art.shtml?num=50561) вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей).Основные изменения (http://nginx.org/en/CHANGES):
- Добавлена поддержка переменных в директивах "limit_rate" и "limit_rate_after", а также в директивах "proxy_upload_rate" и
"proxy_download_rate" модуля stream;
- Повышены требования к минимально поддерживаемой версии OpenSSL - 0.9.8;- По умолчанию обеспечена сборка модуля ngx_http_postpone_filter_module;
- Решены проблемы с неработой директивы "include" внутри блоков "if" и "limit_except";
- Исправлена ошибка при обработке байтовых значений "Range (https://tools.ietf.org/html/rfc7233)".
Из значительных улучшений, которые ожидаются в ветке 1.17, упоминается реализация поддержки протоколов QUIC и HTTP/3 (https://www.opennet.ru/opennews/art.shtml?num=49594).Дополнительно можно отметить выпуск (http://mailman.nginx.org/pipermail/nginx-announce/2019/00024...) njs 0.3.2, интерпретатора языка JavaScript для веб-сервера nginx. Интерпретатор njs реализует стандарты ECMAScript и позволяет расширять возможности nginx по обработке запросов с помощью скриптов в конфигурации. Скрипты могут использоваться в файле конфигурации для определения расширенной логики обработки запросов, формирования конфигурации, динамической генерации ответа, модификации запроса/ответа или быстрого создания заглушек с решением проблем в web-приложениях.
В новом выпуске njs добавлена поддержка шаблонов строк, определённых в спецификации ECMAScript 6 (https://www.opennet.ru/opennews/art.shtml?num=42450). Шаблоны строк являются строковыми литералами, допускающими встраивание выражений. Выражения определяются в размещённом внутри строки блоке ${...}, который может включать как отдельные переменные (${name}), так и выражения (${5 + a + b})). Кроме того, добавлена поддержка именованных групп в объекте RegExp, позволяющих связать сопоставленные регулярным выражением части строки с определёнными именами вместо порядковых номеров совпадений. Добавлена поддержка сборки с библитекой GNU Readline.URL: https://www.nginx.com/blog/nginx-1-16-1-17-released/
Новость: https://www.opennet.ru/opennews/art.shtml?num=50718
С точки зрения производительности и потребления ресурсов, что лучше - встроенный Lua или JS?
LUA - это сторонний модуль сторонних разработчиков. njs - модуль от авторов, выводы делай сам. (njs выигрывает, такой должен быть вывод)
Lua + nginx это уже openresty. он архитектурно идет немного в разрез с nginx. Но в целом свою задачу решает.
njs быстрый потому что поддерживает только основные элементы ECMAScript и интерпретатором выступает не v8, а самописный движок заделанный под экосистему nginx
Не думаю, что вы заметите разницу, если вы не Фейсбук. Но вообще njs должен быть пошустрее, поскольку теснее интегрирован.А вообще, lua-модуль - это причина, по которой в nginx стали делать njs. В lua-модуле используется ряд костылей для интеграции с nginx, типа залезания во внутренние API и структуры nginx-а, неизменность которых никто никогда не гарантировал, но ввиду популярности lua-модуля в том числе и у коммерческих пользователей они вынуждены поддерживать совместимость nginx (в том числе nginx-plus) с lua-модулем (или самостоятельно патчить его под новые версии). В какой-то момент им это все явно поднадоело.
поскольку ни в том ни в другом нет jit, а схема работы в них одинаковая - существенной разницы не может быть (до тех пор пока они используются по назначению).
Подозреваю, что для типичного применения в 2-3 строки кода от jit-а будет больше вреда, чем пользы.
А почему нельзя сделать так, чтобы jit работал только когда быстрее?
Чёто типа уровня оптимизации. И почему низя кэшировать результаты?
Эта жаба не кэшируит (кажется). (хотя у неё уже на входе бинарный код для машины) И при каждом новом запуске она делает одну и ту же работу по оптимизации того же кода (вроде).
И меня раздражает, что она так долго запускает программы.
Почему нельзя запускать их в первом уровне оптимизации (быстро), а потом уже в отдельном потоке щитать? (И чем больше вызывается код - тем лучше его оптимизировать, например).
Но ведь jvm делают не дураки (а вот я - дурак), им что то мешает?
Почему нельзя ВСЁ закешировать???
> Почему нельзя запускать их в первом уровне оптимизации (быстро), а потом уже в отдельном потоке щитать?В web js-ных движках так и сделано.
А вот Java в её мире запускается один раз в неделю (месяц, год, 10 лет?) и работает, работает, работает. При таком подходе вообще глубоко фиолетово, сколько времени оно запускается. И за такое время работы накапливается статистика запуска функций огого.> (И чем больше вызывается код - тем лучше его оптимизировать, например).
Гляньте, например, параметр XX:CompileThreshold (дефолт 10000).
Вообще, в Яве я профан. Так что оправьте, если что.
Всё это похоже на, так сказать, серверный профиль использования. И что там на декстопе прога запускается и закрывается каждые 10 минут - ну ой. Может, так есть какой-то "десктопный" профиль.
> А почему нельзя сделать так, чтобы jit работал только когда быстрее?Потому что если вы хотите засунуть программу в 100 000 строк кода в nginx, вы не должны этого хотеть. Пишите на nodejs и проксируйте на него (или используйте nginx unit).
Nginx - не application server. Назначение этих модулей - реализация конфигураций, для которых не хватает встроенных возможностей nginx, а на таких микроскопических объемах кода от JIT-а никогда не будет особого толку. Если и будет, то недалеко от погрешности измерения.
есть lua jit
https://openresty.org/en/luajit.html
> ни в том ни в другом нет jitLua-модуль для Nginx проектировался под LuaJIT, хоть и с поддержкой Lua 5.1. Не знаю, зачем им поддержка Lua 5.1, потому что даже в режиме интерпретатора LuaJIT быстрее.
>поскольку ни в том ни в другом нет jitВообще-то в lua-nginx-module как раз LuaJIT используется
QUIC http/3 в какой версии ожидается?
Надеюсь, что никогда.
Товарищ мамакин майор как вам не стыдно?
а не будете делать что велим - отключим газ...то есть гугль...то есть интернет вообще.
В тексте новости написано, что ожидается в ветке 1.17.
Посмотрите на цикл релизов nginx и сделайте выводы.