Доступен (http://mailman.nginx.org/pipermail/nginx-announce/2016/00017... выпуск основной ветки высокопроизводительного HTTP-сервера nginx 1.9.12 (http://www.nginx.org/), в котором реализована поддержка более 64 CPU в директиве "worker_cpu_affinity" и добавлена поддержка кодирования Хаффмана (https://ru.wikipedia.org/wiki/%D0%9A%D0%... для заголовков ответов в HTTP/2. Также устранена порция ошибок в ngx_http_v2_module и реализации HTTP/2, решены проблемы с совместимостью со сторонними модулями на языке Си++, исправлены проблемы со сборкой с OpenSSL.
URL: http://mailman.nginx.org/pipermail/nginx-announce/2016/00017...
Новость: http://www.opennet.me/opennews/art.shtml?num=43935
>в котором реализована поддержка более 64 CPUЭто у кого такие мэйнфреймы для веба стоят, не проще ли просто балансировать нагрузку по сети ?
Более 64 логических ядер сейчас есть не только в мейнфреймах, но и в мощных 1U серверах. Скажем, два сокета по xeon E5-2699 v3.
До чего дошла техника, пока я танки играл.
Вначале прикрутили жабо-скрипт, который как все знают – "благодаря JITу быстр как Си и совсем не тормозит"
https://www.opennet.me/opennews/art.shtml?num=43022
Так что поддержка "более 64 CPU" – вполне логичный шаг.
>>в котором реализована поддержка более 64 CPU
> Это у кого такие мэйнфреймы для веба стоятДовольно давно уже можно было воткнуть четыре бульдозера (например, на нашей сборочнице стоят двухмоторные 32-ядерные узлы), с тех пор каменотёсы тоже чутка шевелились...
> Доступен (http://mailman.nginx.org/pipermail/nginx-announce/2016/00017...
> выпуск основной ветки высокопроизводительного HTTP-сервера nginx 1.9.12 (http://www.nginx.org/),
> в котором реализована поддержка более 64 CPU в директиве "worker_cpu_affinity" и
> добавлена поддержка кодирования Хаффмана (https://ru.wikipedia.org/wiki/%D0%9A%D0%...
> для заголовков ответов в HTTP/2. Также устранена порция ошибок в
> ngx_http_v2_module и реализации HTTP/2, решены проблемы с совместимостью со сторонними
> модулями на языке Си++, исправлены проблемы со сборкой с OpenSSL.
> URL: http://mailman.nginx.org/pipermail/nginx-announce/2016/00017...
> Новость: http://www.opennet.me/opennews/art.shtml?num=43935отлично на FreeBSD уже обновил
Зачастили как-то релизы nginx-а...
Ребята, а кто быстрее, nginx или java? Например wildfly на раздаче сервлетов отрабатывает 40-50 тысяч запросов в секунду на обычном десктопе c i7-4820K (данные не статические, генерится XML-ка из массива в ОЗУ, которое в свою очередь хранится в СУБД). Неужели nginx был бы быстрее? Насколько?
> Ребята, а кто быстрее, nginx или java?Вопрос воставлен некорректно. Надо сравнивать конкретные конфигурации nginx и wildfly.
И в какой конфигурации nginx начнет генерировать xml из данных в СУБД?
> И в какой конфигурации nginx начнет генерировать xml из данных в СУБД?Поробуйте, например, https://github.com/odoo/ngx_postgres . Потом расскажете!
Те ни в какой.
Пока вы не скачаете, скомпилируете и подключите сторонний модуль третьей фирмы.
>Ребята, а кто быстрее, nginx или java?Кто сильнее слон или кит?
>данные не статические, генерится XML-ка из массива в ОЗУ, которое в свою очередь хранится в СУБДОЗУ хранится в СУБД? До чего дошла техника.
Массив в ОЗУ и при этом хранится в СУБД. Кому интересно, читаем про JPA/Hibernate.Получается, что nginx нужен только там, где не хватает 50Kreqps Jetty? Т.е. почти никому?
>данные не статические, генерится XML-ка из массива в ОЗУ, которое в свою очередь хранится в СУБДМассив - мужского рода, XML-ка - у вас женского рода, так что "которое" тут может относится только к ОЗУ, которое(sic!) расшифровывается как "Оперативное запоминающее устройство".
В вашем предложении у вас в СУБД хранится ОЗУ.
> Кому интересно, читаем про JPA/Hibernate.Что уже мало кому интересно, читаем https://en.wikipedia.org/wiki/Overengineering
>Получается, что nginx нужен только там, где не хватает 50Kreqps Jetty? Т.е. почти никому?Среди "Лютый жабист"-ов никому. Слава богу они в собственной палате и реальности.
>> Среди "Лютый жабист"-ов никому. Слава богу они в собственной палате и реальности.С месяц назад пролетала смешная новость про то, что тот кто заходил на сервер под упр. Ubuntu сам стал убунтоидом. В общем, у меня для вас плохая новость, вы жабкой в жизни просто каждый день пользуетесь. Нравится это вам или нет. 8)
Не нравится. Но мы, сисадмины, в какое только г. по локоть не залезали. Главное в рот не тащить что попало, и оды ему не петь.
А что в wildfly с проблемой 10К? Сколько получится rps, если каждый запрос будет забираться с сервера по 1 секунде?Первоочередная задача nginx, если я верно понимаю документацию, это реверс-проксирование, забота о передаче ответа клиенту. Все эти головняки с плавающим окном tcp, буферами, дисконектами, кешированием и прочее.
wildfly не форкается на каждого клиента, поэтому непонятно что вас гложет.То что nginx впаривают как реверс-прокси для javaEE (даже на сайте нгинкса есть мануалы). Проблемка в том, что на сайте того же jboss-а никто не впаривает nginx. Так что возможно акционерам nginx-а просто хочется кушать лучше среднего, а технических причин нет использовать костыли.
Особенно учитывая, что java application-серверы шикарно масштабируются из коробки.
То, что не форкается на каждый запрос, это хорошо. Но еще раз - сколько памяти уйдет на ОДНОВРЕМЕННОЕ обслуживание 10 тыс. запросов к вашей Wildfly? И возможно ли это вообще? Сделайте так, чтобы клиент отправил запрос, но не вычитывал ответ, и проверьте.Я не фанатик nginx. Если результаты будут мало-мальски приемлемы, я готов признать, что в паре с Wildfly nginx не требуется.
у меня домашний комп не тянет 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&userna...
'
Running 1m test @ http://192.168.1.189:8080/site/getConfig?domain=34434&userna...
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 запросов в секунду так и раздаёт.
> у меня домашний комп не тянет 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&userna...А зачем вы wrk запускаете с таким количеством потоков? Он, как и nginx, асинхронный, ему нужно ровно столько потоков сколько у вас ядер в системе, больше не имеет особого смысла.
Так вы только ему хуже делаете, это вам не жаба.
>[оверквотинг удален]
> 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.54MB15k rps и это вы называете производительность? На странице обычно до 100 различных файлов и ресурсов которые нужно запросить браузеру. Ваши 15611k превращаются в максимум 150 пользователей онлайн. Для домашней странички и малопопулярного бложика - сойдет.
Чем больше потоков, тем больше скорость отдачи :)
Но на 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&userna...'
Running 1m test @ http://192.168.1.189:8080/site/getConfig?domain=34434&userna...
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
Тут тоже несколько не то тестирование, о котором я вам говорю. Я имею в виду нечто вроде вот этогоslowhttptest -c 10000 -X -r 200 -w 10 -y 100 -n 5 -z 32 -k 3 -u http://localhost/ -p 3
Wildfly в силах это выдержать, не выжрать всю память, не выдавать ошибок и оставаться доступным?
А попробуйте вашим jetty раздавать файлы. С диска. Ну скажем терабайт картинок у вас есть по 100 килобайт штука, оперативы 12Гбайт, спрашивают картинки много, рандомно и МЕДЛЕННО ЗАБИРАЮТ.
И ещё вопрос: jetty всегда такая быстрая или пока GC не решит память очистить?
Порнушечку по локалочке раздавать это не для джавы задачи. Про GC посмеялся, видно очередного диванного эксперта по тормозам джавы. Интересно, какие объекты при обработке XML или генерации сервлета создаются массово, чтобы GC было что делать.