The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск nginx 1.9.12

24.02.2016 19:54

Доступен выпуск основной ветки высокопроизводительного HTTP-сервера nginx 1.9.12, в котором реализована поддержка более 64 CPU в директиве "worker_cpu_affinity" и добавлена поддержка кодирования Хаффмана для заголовков ответов в HTTP/2. Также устранена порция ошибок в ngx_http_v2_module и реализации HTTP/2, решены проблемы с совместимостью со сторонними модулями на языке Си++, исправлены проблемы со сборкой с OpenSSL.

  1. Главная ссылка к новости (http://mailman.nginx.org/piper...)
  2. OpenNews: Выпуск nginx 1.9.11 с поддержкой динамически загружаемых модулей
  3. OpenNews: Обновление nginx 1.8.1 и 1.9.10 с устранением уязвимостей в резолвере DNS
  4. OpenNews: Выпуск nginx 1.9.9
  5. OpenNews: Выпуск nginx 1.9.8
  6. OpenNews: В HTTP-сервер nginx встроена поддержка JavaScript
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/43935-nginx
Ключевые слова: nginx
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (23) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Джо (?), 21:59, 24/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >в котором реализована поддержка более 64 CPU

    Это у кого такие мэйнфреймы  для  веба стоят,   не проще  ли  просто балансировать нагрузку  по сети ?

     
     
  • 2.2, Аноним (-), 23:18, 24/02/2016 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Более 64 логических ядер сейчас есть не только в мейнфреймах, но и в мощных 1U серверах. Скажем, два сокета по xeon E5-2699 v3.
     
     
  • 3.11, Джо (?), 10:59, 25/02/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    До чего дошла техника, пока я танки играл.


     
  • 2.15, Аноним (-), 14:31, 25/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вначале прикрутили жабо-скрипт, который как все знают – "благодаря JITу быстр как Си и совсем не тормозит"
    https://www.opennet.me/opennews/art.shtml?num=43022
    Так что поддержка "более 64 CPU" – вполне логичный шаг.
     
  • 2.16, Michael Shigorin (ok), 18:43, 25/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>в котором реализована поддержка более 64 CPU
    > Это у кого такие мэйнфреймы  для  веба стоят

    Довольно давно уже можно было воткнуть четыре бульдозера (например, на нашей сборочнице стоят двухмоторные 32-ядерные узлы), с тех пор каменотёсы тоже чутка шевелились...

     

  • 1.3, dgdgdgd (?), 00:46, 25/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Доступен (http://mailman.nginx.org/pipermail/nginx-announce/2016/000171.html)
    > выпуск основной ветки высокопроизводительного HTTP-сервера nginx 1.9.12 (http://www.nginx.org/),
    > в котором реализована поддержка более 64 CPU в директиве "worker_cpu_affinity" и
    > добавлена поддержка кодирования Хаффмана (https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B4
    > для заголовков ответов в  HTTP/2. Также устранена порция ошибок в
    > ngx_http_v2_module и реализации  HTTP/2, решены проблемы с совместимостью со сторонними
    > модулями на языке Си++, исправлены проблемы со сборкой с OpenSSL.
    > URL: http://mailman.nginx.org/pipermail/nginx-announce/2016/000171.html
    > Новость: http://www.opennet.me/opennews/art.shtml?num=43935

    отлично на FreeBSD уже обновил

     
  • 1.4, Какаянахренразница (ok), 05:22, 25/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачастили как-то релизы nginx-а...
     
  • 1.5, Лютый жабист (?), 07:50, 25/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Ребята, а кто быстрее, nginx или java? Например wildfly на раздаче сервлетов отрабатывает 40-50 тысяч запросов в секунду на обычном десктопе c i7-4820K (данные не статические, генерится XML-ка из массива в ОЗУ, которое в свою очередь хранится в СУБД). Неужели nginx был бы быстрее? Насколько?
     
     
  • 2.6, Аноним (-), 10:15, 25/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Ребята, а кто быстрее, nginx или java?

    Вопрос воставлен некорректно. Надо сравнивать конкретные конфигурации nginx и wildfly.

     
     
  • 3.8, Аноним (-), 10:25, 25/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И в какой конфигурации nginx начнет генерировать xml из данных в СУБД?
     
     
  • 4.9, Andrey Mitrofanov (?), 10:33, 25/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И в какой конфигурации nginx начнет генерировать xml из данных в СУБД?

    Поробуйте, например, https://github.com/odoo/ngx_postgres . Потом расскажете!

     
     
  • 5.10, Ларри Эллисон (?), 10:58, 25/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Те ни в какой.
    Пока вы не скачаете, скомпилируете и подключите сторонний модуль третьей фирмы.
     
  • 2.7, Аноним (-), 10:23, 25/02/2016 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >Ребята, а кто быстрее, nginx или java?

    Кто сильнее слон или кит?
    >данные не статические, генерится XML-ка из массива в ОЗУ, которое в свою очередь хранится в СУБД

    ОЗУ хранится в СУБД? До чего дошла техника.

     
     
  • 3.12, Лютый жабист (?), 11:14, 25/02/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Массив в ОЗУ и при этом хранится в СУБД. Кому интересно, читаем про JPA/Hibernate.

    Получается, что nginx нужен только там, где не хватает 50Kreqps Jetty? Т.е. почти никому?

     
     
  • 4.13, Аноним (-), 12:48, 25/02/2016 [^] [^^] [^^^] [ответить]  
  • +6 +/
    >данные не статические, генерится XML-ка из массива в ОЗУ, которое в свою очередь хранится в СУБД

    Массив - мужского рода, XML-ка - у вас женского рода, так что "которое" тут может относится только к ОЗУ, которое(sic!) расшифровывается как "Оперативное запоминающее устройство".
    В вашем предложении у вас в СУБД хранится ОЗУ.
    > Кому интересно, читаем про JPA/Hibernate.

    Что уже мало кому интересно, читаем https://en.wikipedia.org/wiki/Overengineering
    >Получается, что nginx нужен только там, где не хватает 50Kreqps Jetty? Т.е. почти никому?

    Среди "Лютый жабист"-ов никому. Слава богу они в собственной палате и реальности.

     
     
  • 5.18, Лютый жабист (?), 09:13, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Среди "Лютый жабист"-ов никому. Слава богу они в собственной палате и реальности.

    С месяц назад пролетала смешная новость про то, что тот кто заходил на сервер под упр. Ubuntu сам стал убунтоидом. В общем, у меня для вас плохая новость, вы жабкой в жизни просто каждый день пользуетесь. Нравится это вам или нет. 8)

     
     
  • 6.22, count0krsk (ok), 20:49, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не нравится. Но мы, сисадмины, в какое только г. по локоть не залезали. Главное в рот не тащить что попало, и оды ему не петь.
     
  • 4.14, Аноним (-), 13:02, 25/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что в wildfly с проблемой 10К? Сколько получится rps, если каждый запрос будет забираться с сервера по 1 секунде?

    Первоочередная задача nginx, если я верно понимаю документацию, это реверс-проксирование, забота о передаче ответа клиенту. Все эти головняки с плавающим окном tcp, буферами, дисконектами, кешированием и прочее.

     
     
  • 5.17, Лютый жабист (?), 09:11, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    wildfly не форкается на каждого клиента, поэтому непонятно что вас гложет.

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

    Особенно учитывая, что java application-серверы шикарно масштабируются из коробки.

     
     
  • 6.19, Аноним (-), 12:49, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    То, что не форкается на каждый запрос, это хорошо. Но еще раз - сколько памяти уйдет на ОДНОВРЕМЕННОЕ обслуживание 10 тыс. запросов к вашей Wildfly? И возможно ли это вообще? Сделайте так, чтобы клиент отправил запрос, но не вычитывал ответ, и проверьте.

    Я не фанатик nginx. Если результаты будут мало-мальски приемлемы, я готов признать, что в паре с Wildfly nginx не требуется.

     
     
  • 7.20, Лютый жабист (?), 20:20, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    у меня домашний комп не тянет wrk с 10k thread-ами. С 2000 одновременными ничего не изменилось, wildfly хавает 550МБ по мнению top (если смотреть монитор JVM, то занято около половины)

    wrk -c 2000 -t 2000 -d 1m  'http://192.168.1.189:8080/site/getConfig?domain=34434&username=5454
    '
    Running 1m test @ http://192.168.1.189:8080/site/getConfig?domain=34434&username=5454
      2000 threads and 2000 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency   132.43ms   52.70ms 926.75ms   82.76%
        Req/Sec     8.69      7.63     1.86k    97.08%
      938959 requests in 1.00m, 213.12MB read
    Requests/sec:  15611.10
    Transfer/sec:      3.54MB

    [root@scary go]# ps axu|grep java
    go       11781 93.0 13.7 3101592 556272 pts/1  Sl+  00:05   1:52 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly-10.0.0.Final/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly-10.0.0.Final/standalone/configuration/logging.properties -jar /opt/wildfly-10.0.0.Final/jboss-modules.jar -mp /opt/wildfly-10.0.0.Final/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly-10.0.0.Final -Djboss.server.base.dir=/opt/wildfly-10.0.0.Final/standalone

    Это раздача сервлета с динамическим содержимым. 15.5k запросов в секунду так и раздаёт.

     
     
  • 8.24, Аноним (-), 00:27, 27/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем вы wrk запускаете с таким количеством потоков Он, как и nginx, асинхрон... текст свёрнут, показать
     
  • 7.21, Лютый жабист (?), 20:28, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Чем больше потоков, тем больше скорость отдачи :)
    Но на 3600 wrk ест под 2 гига ОЗУ. В 4 раза больше чем WF - у него по прежнему чуть за 500 (590).

    [root@scary go]# wrk -c 3600 -t 3600 -d 1m  'http://192.168.1.189:8080/site/getConfig?domain=34434&username=5454'
    Running 1m test @ http://192.168.1.189:8080/site/getConfig?domain=34434&username=5454
      3600 threads and 3600 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency   169.17ms   43.84ms 632.22ms   79.67%
        Req/Sec     6.41      5.35     1.58k    98.53%
      1366127 requests in 1.00m, 310.08MB read
    Requests/sec:  22669.15
    Transfer/sec:      5.15MB

     
     
  • 8.23, Аноним (-), 23:31, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Тут тоже несколько не то тестирование, о котором я вам говорю Я имею в виду неч... текст свёрнут, показать
     
  • 6.25, Аноним (-), 01:27, 27/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А попробуйте вашим jetty раздавать файлы. С диска. Ну скажем терабайт картинок у вас есть по 100 килобайт штука, оперативы 12Гбайт, спрашивают картинки много, рандомно и МЕДЛЕННО ЗАБИРАЮТ.
    И ещё вопрос: jetty всегда такая быстрая или пока GC не решит память очистить?
     
     
  • 7.26, Лютый жабист (?), 10:11, 29/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Порнушечку по локалочке раздавать это не для джавы задачи. Про GC посмеялся, видно очередного диванного эксперта по тормозам джавы. Интересно, какие объекты при обработке XML или генерации сервлета создаются массово, чтобы GC было что делать.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру