1. Есть много примеров контор которые действительно гоняли OpenJDK без сборки мусора — патчили System.gc(), хотя я не приветствую такой способ и считаю его большим костылём с ещё большими рисками. Как и почему нужно тюнинговать GC можно глянуть в презентации Рогозина, так же у него был хороший CheatSheet.
2. Disruptor помогает в реализации стратегии «Share Memory By Communicating» — не нужно заморачиваться с пулами объектов и multiton'ами, размерами очередей сообщений в разнообразных вариациях модели актёров.
3. Hashcode по умолчанию использует псевдослучайную генерацию хешей, которая быстро истощает пул энтропии в системе. По этому такие вещи как Haveged могут увеличить производительность виртуальной машины, но делают её random предсказуемым. Даже банальное Android приложение в 4.4 при замене дефолтного hashcode работает в 1.5-2 раза шустрее, по моим личным наблюдениям.
Тюнинг ядра сводится к увеличению размера mmap'a что влияет на максимальное количество дескрипторов (сокетов) в системе в целом, всё остальное — это увеличение epoll пула и обоюдный тюнинг TCP стэка, влияние на производительность которого не сравнимо ни в каких рамках с overhead'ом виртуальной машины.
dpdk / netmap нужны для того чтобы обойти netfilter и лишние memcpy для сетевых буферов.
Понятное дело что тут есть много «но», и большую часть «кусков» приложения нужно правильно профилировать под нагрузкой — подобные рассуждения и скептицизм не очень то и конструктивны.
Если сравнивать высокую доступность — тут у Erlang'a есть преимущество, так как в нём почти всё в Beam машине написано с использованием wait-free (но не lock-free) алгоритмов. Если сравнивать по производительности — она ниже плинтуса, так что для задач посложнее memcpy он не очень то и подходит. А в «дикой природе» получается так что гораздо проще прикрутить ту же Akka и, при правильной допилке, получить ту же производительность — это касается любых проектов которые отправляют что-то сложнее HelloWorld по Http.
Перво-наперво нужно подтюнинговать JVM.
По хорошему — желательно вообще вырубить GC и использовать Disruptor, но я до такого сам не доходил, хотя были примеры из жизни и довольно позитивные отзывы. Я обычно выставляю выставляю низкий размер новых генераций для GC и максимальное переиспользование существующих. Как минимум, нужно поменять дефолтную реализацию hashcode что бы не было зависимости от размера пула энтропии — это уже даст довольно большой прирост производительности. Всё остальное — тюнинг ядрышка, нужно тюнинговать виртуальную память, что бы можно было запить больше файловых дескрипторов, ну там увеличить размер mmap/munmap'a посредством увеличения vm.max_map_count, после чего уже можно увеличивать всё остальное. Ещё можно увеличить количество ipv4 сокетов net.ipv4.ip_local_port_range, что иногда может приводить к довольно странным последствиям, и fs.epoll.max_user_watches для увеличения количества событий в epoll'e. Для обхода ограничения по количеству сокетов можно ещё маркировать пакеты, только «руками» без netfilter'a, и рассылать их по нескольким процессам — это позволит дублировать дескрипторы. Может чего и забыл, но я сейчас не особо то и слежу за текущим состоянием VM'a и сетевых плюшек в линуксе — переехал на более приземлённые задачи.
Очень желательно использовать netmap или dpdk для мапинга памяти.
Я писал как-то dpdk маппер для одного проекта, но заопенсорсить я его не могу по понятным причинам.
p.s. 200K на ядро это я ещё помелочился :3 — можно гораздо больше.
Перечитывал несколько раз, так и не понял что подразумевалось. Всё остальное golang/node.js успешно дохнет на 15-20К запросов, «на всех ядрах».
Вопрос стоило ли заморачиватся с Netty?
Стоит, в первую очередь из-за производительности. Если вы не строите приложений критических к скорости обработки запросов, и вам 5ms погоды не сделают — понятное дело можно использовать что-то проще. C Netty, при правильной допилке, можно выжать под 150-200K запросов на ядро с задержками в 2-3ms. Естественно для большей части простых обывателей подобные вещи бесполезны.
А вообще, сетевых библиотек с нормальным offheap'ом в природе больше замечено не было.
Vert.x сейчас находится в зачаточном состоянии и позиционируется как фреймворк для построения реактивных приложений и микросервисов. Естественно он чуть более чем полностью обёртка поверх Netty, а HA класстерные решения строятся поверх Hazelcast'a. Нужно обратить внимание на наличие автоматической кодогенерации, которая генерит Ruby / Groovy / JS API на основе существующих аннотаций Java API, т.е. в первую очередь это мультиязычное решение.
По поводу «Direct-буферов» — Netty имеет свой Arena-аллокатор на подобие того что используется в jemalloc, и самостоятельно производит менеджмент offheap'a.
А я сижу, пишу асинхронный PostgreSQL коннектор на vert.x'e :3 который можно было бы использовать в более-менее продакшенах.
Да, я как раз вспомнил про тот что понавороченней.
Кстати, у Visa экранчик повеселее будет.
Не знаю сколько стоит выпуск подобной карты, правда возможность удалённо смотреть, блокировать и обнулять счета в некоторых латвийских банках специальным GSM брелком стоила довольно дорого (200$ выпуск и 10$ в месяц в 2014'м). Не уверен что подобные поделки имеют отношение к Visa или Mastercard, это скорее особенность европейских банков через которые проводят инвестиции в СНГ :)
Есть карты со встроенными NFC и дисплеями, правда стоимость их поддержки и изготовления — не для большинства «серой массы», с которой у нас принято иметь дело.
Я хотел бы аналога MasterPass от Visa, а то тольку от этих железок с NFC не так много, с точки зрения безопасности, а для мерчантов — сплошная головная боль. Вот дискриминация пользователей с root'ом выглядит очень наивно — ничто не запрещает отпатчить что угодно и как угодно. Я считаю что Visa должна быть более открыта, и решения того же MasterCard'a сейчас более привлекательны, не сочтите рекламой — просто моё личное мнение.
Не хватает про llgo, и сравнение производительности в придачу.
Сегодня, кстати, в рассылке llvm'a проскочило что в lldb golang'овский runtime добавили 1 и 2
Я это прекрасно понимаю, но хотел глянуть что за пафосная муть скрывается под катом.
ИМХО php 7 (уже RC3) на подходе, так что почти все существующие решения устаревают не по дням, а по минутам.
Я не вижу смысла рассказывать о том что и так всем должно быть понятно — в питоне нет нормальных средств полнотекстового поиска, давайте возьмём и будем использовать то что предлагает Java-мир, ведь оно в N раз быстрее даже со всеми накладными расходами на коммуникацию. Для меня это немного абсурдно.
Впрочем и в Java сейчас только-только проясняется ответ на вопрос «есть ли в Java жизнь после J2EE ?», ответ: «с ванильными netty-based решениями — однозначно есть». Я не пытаюсь с кем-либо спорить, просто делюсь опытом и собственными наблюдениями за существующими тенденциями.
Это тот который с привкусом джавы Elastic Search / Solr?
Нет, спасибо.
Я и дальше продолжу свой микросервисный путь в Vert.x с ванильной Java без Akka и прочих Scala overhead'ов.
Хотя я и Groovy не брезгую, ибо с @ CompileStatic, @ Immutable и @ Canonical :3 overhead не столь значителеный.
А производительность питона слишком посредственна, оставляет желать лучшего.
Яндекс тому пример — давно слезли на golang.
На стандартный аргумент «железо нынче дешёвое» — скажу «миллисекунды дороже».
А я просто оставлю это здесь.
Учитывая компонентный подход, компоненты отрефайнят и будет нормальная кроссплатформенная JS тулза которой не стыдно пользоваться, по сравнению с Cordova которая имхо шлакъ.
Я думаю, это в Мегамозг надо было бы…
Да и «Я пиарюсь» подванивает попахивает.
Был бы толк, если бы было приведено сравнение функционала и всех pros/cons.
Работал почти со всем что более-менее актуально и распространено.
Получается такая ситуация что как только контра хочет разработать какое-то актуальное решение — нужно пилить свой гибрид лигерада с токамаком. Так было с Rails / Grails / Gulp.js / React.js / Sproutcore (ember) / Cappuccino / Symfony / Play2…
A практике получается так что MVC подходит только для простых UI, и на бэкенде порождает тонну шаблонной копипасты из-за Scaffolding'a. Рано или поздно, люди всеравно скатываются в CQRS-ES с всякими German / Celery / Sidekiq / beanstalk / rabbitmq и т.п. Ну или, что ещё хуже, потом обзывают это всё микросервисами. Хотя на самом деле для REST CRUD'ов, не зависимо от размера (нормализованной) базы, хватит 6 шаблонных front controller'ов.
Большую часть существующего фронта можно очень сильно абстрагировать: избавится от потребности дублирования моделей их валидации, и представления — генерировать это всё на лету автоматом с существующих серверных шаблонов, не смотря на целевые языки и платформы, полностью избавиться от node.js на сервере, для меня он часто становится бутылочным
Существует не так много решений, которые действительно удовлетворяют современные потребности рынка и обеспечивают должное качество реализации решений.
2. Disruptor помогает в реализации стратегии «Share Memory By Communicating» — не нужно заморачиваться с пулами объектов и multiton'ами, размерами очередей сообщений в разнообразных вариациях модели актёров.
3. Hashcode по умолчанию использует псевдослучайную генерацию хешей, которая быстро истощает пул энтропии в системе. По этому такие вещи как Haveged могут увеличить производительность виртуальной машины, но делают её random предсказуемым. Даже банальное Android приложение в 4.4 при замене дефолтного hashcode работает в 1.5-2 раза шустрее, по моим личным наблюдениям.
Тюнинг ядра сводится к увеличению размера mmap'a что влияет на максимальное количество дескрипторов (сокетов) в системе в целом, всё остальное — это увеличение epoll пула и обоюдный тюнинг TCP стэка, влияние на производительность которого не сравнимо ни в каких рамках с overhead'ом виртуальной машины.
dpdk / netmap нужны для того чтобы обойти netfilter и лишние memcpy для сетевых буферов.
Понятное дело что тут есть много «но», и большую часть «кусков» приложения нужно правильно профилировать под нагрузкой — подобные рассуждения и скептицизм не очень то и конструктивны.
Жду когда допилят порт erlang'a под llvm.
По хорошему — желательно вообще вырубить GC и использовать Disruptor, но я до такого сам не доходил, хотя были примеры из жизни и довольно позитивные отзывы. Я обычно выставляю выставляю низкий размер новых генераций для GC и максимальное переиспользование существующих. Как минимум, нужно поменять дефолтную реализацию hashcode что бы не было зависимости от размера пула энтропии — это уже даст довольно большой прирост производительности. Всё остальное — тюнинг ядрышка, нужно тюнинговать виртуальную память, что бы можно было запить больше файловых дескрипторов, ну там увеличить размер mmap/munmap'a посредством увеличения vm.max_map_count, после чего уже можно увеличивать всё остальное. Ещё можно увеличить количество ipv4 сокетов net.ipv4.ip_local_port_range, что иногда может приводить к довольно странным последствиям, и fs.epoll.max_user_watches для увеличения количества событий в epoll'e. Для обхода ограничения по количеству сокетов можно ещё маркировать пакеты, только «руками» без netfilter'a, и рассылать их по нескольким процессам — это позволит дублировать дескрипторы. Может чего и забыл, но я сейчас не особо то и слежу за текущим состоянием VM'a и сетевых плюшек в линуксе — переехал на более приземлённые задачи.
Очень желательно использовать netmap или dpdk для мапинга памяти.
Я писал как-то dpdk маппер для одного проекта, но заопенсорсить я его не могу по понятным причинам.
p.s. 200K на ядро это я ещё помелочился :3 — можно гораздо больше.
Перечитывал несколько раз, так и не понял что подразумевалось. Всё остальное golang/node.js успешно дохнет на 15-20К запросов, «на всех ядрах».Стоит, в первую очередь из-за производительности. Если вы не строите приложений критических к скорости обработки запросов, и вам 5ms погоды не сделают — понятное дело можно использовать что-то проще. C Netty, при правильной допилке, можно выжать под 150-200K запросов на ядро с задержками в 2-3ms. Естественно для большей части простых обывателей подобные вещи бесполезны.
А вообще, сетевых библиотек с нормальным offheap'ом в природе больше замечено не было.
По поводу «Direct-буферов» — Netty имеет свой Arena-аллокатор на подобие того что используется в jemalloc, и самостоятельно производит менеджмент offheap'a.
А я сижу, пишу асинхронный PostgreSQL коннектор на vert.x'e :3 который можно было бы использовать в более-менее продакшенах.
Кстати, у Visa экранчик повеселее будет.
Не знаю сколько стоит выпуск подобной карты, правда возможность удалённо смотреть, блокировать и обнулять счета в некоторых латвийских банках специальным GSM брелком стоила довольно дорого (200$ выпуск и 10$ в месяц в 2014'м). Не уверен что подобные поделки имеют отношение к Visa или Mastercard, это скорее особенность европейских банков через которые проводят инвестиции в СНГ :)
Сегодня, кстати, в рассылке llvm'a проскочило что в lldb golang'овский runtime добавили 1 и 2
ИМХО php 7 (уже RC3) на подходе, так что почти все существующие решения устаревают не по дням, а по минутам.
Впрочем и в Java сейчас только-только проясняется ответ на вопрос «есть ли в Java жизнь после J2EE ?», ответ: «с ванильными netty-based решениями — однозначно есть». Я не пытаюсь с кем-либо спорить, просто делюсь опытом и собственными наблюдениями за существующими тенденциями.
Это тот который с привкусом джавы Elastic Search / Solr?
Нет, спасибо.
Я и дальше продолжу свой микросервисный путь в Vert.x с ванильной Java без Akka и прочих Scala overhead'ов.
Хотя я и Groovy не брезгую, ибо с @ CompileStatic, @ Immutable и @ Canonical :3 overhead не столь значителеный.
А производительность питона слишком посредственна, оставляет желать лучшего.
Яндекс тому пример — давно слезли на golang.
На стандартный аргумент «железо нынче дешёвое» — скажу «миллисекунды дороже».
Но там такой сыр-бор твориться…
* У Swagger'a, в этой роли, пока что ничего не получается, и поддержка довольно ужасна.
Учитывая компонентный подход, компоненты отрефайнят и будет нормальная кроссплатформенная JS тулза которой не стыдно пользоваться, по сравнению с Cordova
которая имхо шлакъ.Да и «Я пиарюсь»
подваниваетпопахивает.Был бы толк, если бы было приведено сравнение функционала и всех pros/cons.
Получается такая ситуация что как только контра хочет разработать какое-то актуальное решение — нужно пилить свой гибрид лигерада с токамаком. Так было с Rails / Grails / Gulp.js / React.js / Sproutcore (ember) / Cappuccino / Symfony / Play2…
A практике получается так что MVC подходит только для простых UI, и на бэкенде порождает тонну шаблонной копипасты из-за Scaffolding'a. Рано или поздно, люди всеравно скатываются в CQRS-ES с всякими German / Celery / Sidekiq / beanstalk / rabbitmq и т.п. Ну или, что ещё хуже, потом обзывают это всё микросервисами. Хотя на самом деле для REST CRUD'ов, не зависимо от размера (нормализованной) базы, хватит 6 шаблонных front controller'ов.
Большую часть существующего фронта можно очень сильно абстрагировать: избавится от потребности дублирования моделей их валидации, и представления — генерировать это всё на лету автоматом с существующих серверных шаблонов, не смотря на целевые языки и платформы, полностью избавиться от node.js на сервере, для меня он часто становится бутылочным
Существует не так много решений, которые действительно удовлетворяют современные потребности рынка и обеспечивают должное качество реализации решений.