если у тебя хайлоад (железо забито на соточку) - то никак, только мучиться. Одна приложуха - одна железка.

если у тебя не хайлоад и нет конкуренции по процу, то в целом наплевать. В джаве только отрегулируй Xmx и Xms (количество занимаемой RAM)

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

А как на одном сервере совместить MySQL и PostgreSQL?
Ставить и тюнить каждый по отдельности. Обе вещи самостоятельны и о существовании друг друга ничего не знают.
Другой вопрос
- есть ли хитрое взаимодействие, которое может быть можно перенести c http/tcp на уровень unix сокетов?
- нет ли откровенных перекосов по IO/CPU/Mem между сервисами?

если у тебя хайлоад (железо забито на соточку) - то никак, только мучиться. Одна приложуха - одна железка.

Нет, нагрузка не запредельная, но желательно быстродействие пользовательского интерфейса. Если железок 2, время ожидания становится ощутимым.

Гоняй нагрузочные, мониторь систему и решай конкретные проблемы.

Обе вещи самостоятельны и о существовании друг друга ничего не знают

А нет пытался ли кто их подружить?

- есть ли хитрое взаимодействие, которое может быть можно перенести c http/tcp на уровень unix сокетов?

Возможно. Но этого делать не будут ради кроссплатформенности.

- нет ли откровенных перекосов по IO/CPU/Mem между сервисами?

Надо тестировать под нагрузкой.

Вынести Python + gunicorn за nginx, джаву проксить в нжинксе на jetty/netty. Апач выкинуть нах.

Если железок 2, время ожидания становится ощутимым.

Они у тебя между собой общаются что ли?

Как общаются сейчас то?

Java-приложение рисует страницу, на которой пользователь жмёт кнопки, Java посылает запросы в REST на WSGI-шный скрипт, который дёргает сишную числодробильную библиотеку, и возвращает данные в JSON, которые Java рисует на странице.

gunicorn

Чем он лучше uWSGI? Умеет ли он передавать в скрипт параметры командной строки?

jetty/netty

Они оба нужны, или подойдёт любой? Чем они отличаются?

джаву проксить в нжинксе

Это как?

Вынести Python + gunicorn за nginx, джаву проксить в нжинксе на jetty/netty.

Есть свежий сервер, скрипт *.py, пакет *.war. Что ещё нужно ставить? Java, Python, nginx, Gunicorn, Jetty достаточно?

по идее сейчас внутри Java можно выполнять Python с помощью GraalVM. Это полностью решает проблемы с необходимостью отдельного микросервиса на Python и помогает в хайлоаде. Но я даже за деньги не готов помочь с этим сейчас, потому что нет времени

Я не пользовал uWSGI, насколько я помню, его вполне можно оставить, и реверс проксить запросы нжинксом на него, gunicorn, вроде, проще в настройке, по крайней мере, у меня всё элементарно настраивалось. Параметры можно передавать через переменные окружения, про командную строку - глянь доки сам. Но, думаю, если у вас всё отлично настроено в uwsgi, то оставайтесь на нём.

Любой подойдёт, я не джавист, сравнить не смогу, разве что, netty активнее развивается и более «низкоуровневый», если я что не путаю, ну jetty как раз и создан как пускалка java сервлетов, а netty, вроде, как интегрируемый в war/jar веб асинхронный сервак.

Ну, нжинксом запросы на какой-либо конкретный url (типа https://server/api) отсылать (реверс проксить) в java application, запущенном в докер контейнере, либо на локалхост и порт, а в инет выставить тока порты https/http нжинкса.

джаву проксить в нжинксе на jetty/netty

А сервлеты они все стандартные? Т.е без разницы что томкат что джетти?

Да сервлеты это стандарт. В это кстати плюс джавы

+100500

вообще jetty на статике тоже очень быстрый можно попробовать uwsgi реверсить средствами jetty без nginx...

А питон тут точно нужен?

А питон тут точно нужен?

Да. А вот Джава опциональна :)

вообще jetty на статике тоже очень быстрый

В смысле «на статике»? И Джава и Питон динамически генерируют страницы.

можно попробовать uwsgi реверсить средствами jetty без nginx...

Как это делать? Как называются соответствующие опции?

И раз уж речь о jetty, почему для него не делают deb-пакетов? Какие-то принципиальные ограничения?

А сервлеты они все стандартные? Т.е без разницы что томкат что джетти?

Netty тут упомянут не к месту, хотя может автор имел ввиду что jetty внутрях использует netty. Оба, и tomcat и jetty реализуют servlet-api, если не использовать что-то специфичное, то все будет работать. Обычно дело разрабатывать с jetty, а разворачивать на tomcat.

Обычно дело разрабатывать с jetty, а разворачивать на tomcat.

Какие у них преимущества и недостатки?

Томкета умеет jndi (не пользовал, но думаю что это про конфигугирование множества инстансов), думаю jetty такое не умеет, а еще apache (в роли прокси) может с томкет работать через ajp, это бинарный протокол вместо http, который позволяет проверять жив ли сервер пингами и что-то еще. Про jetty могу сказать, что его запустить в IDE проще, по этой причине на нем часто разрабатывают. И я даже не знаю можно ли jetty запустить как standalone сервлет контейнер для нескольких веб приложений, вот как embedded его использовать не сложно, получается типа как go, самозапускаемые сервисы.

можно ли jetty запустить как standalone сервлет контейнер для нескольких веб приложений, вот как embedded его использовать не сложно

Какая разница? Потребление ресурсов? Отзывчивость? Время восстановления при падении? Масштабируемость?

В смысле «на статике»? И Джава и Питон динамически генерируют страницы.

fyi jetty может отдавать статические файлы тоже https://www.codeproject.com/Articles/1223459/Using-Jetty-to-Serve-Static-Web-... технически ничто не мешает джавовскому (или питоновскому) коду прочитать статический файл с диска и выплюнуть пользователю. естественно это может быть медленнее чем nginx, с другой стороны чтобы отдать буквально пару скриптиков пяток картинок и пару css - дешевле на джава (если она УЖЕ есть) чем ради этого еще и nginx поднимать. В java (jetty) для этого есть стандартный компонент (org.eclipse.jetty.server.handler.ResourceHandler). Конфигурируется в web.xml

Как это делать? Как называются соответствующие опции?

Ровно как и со статическим контентом есть стандартный компонент https://www.eclipse.org/jetty/documentation/9.4.x/proxy-servlet.html

И раз уж речь о jetty, почему для него не делают deb-пакетов? Какие-то принципиальные ограничения?

Да, есть идеологические соображения. Jetty по сути это библиотека (вернее Framework) на java, а y java есть свой механизм/экосистема под названием maven. Вообще концептуально Jetty отличается от Tomcat итп следующей мыслью. В «классических» серверах несколько сайтов хостятся (может хостится). Это и для томкета и для апача и для nginx. Jetty разработан для случая когда один исполняемый файл (процесс) - один сайт. В нагруженных системах так обычно и делают, и этот подход более правильный... Более того зачастую Jetty встраивают в приложение, т.е. java-приложение стартует, настраивает Jetty (не web.xml-ем единым) после чего начинает слушать порт... Ну это все программистские штучки, но Jetty в основном как раз для них (программистов).

Несколько веб-приложений в одном сервлет-контейнере в эпоху докеров и виртуализации это моветон и пережиток прошлого.

JNDI это по сути недо IoC-контейнер. Обычно служит для задания(настройки) подключения к БД итп. B Jetty он есть (настройки читаются из xml-файла или настраиваются в рантайме)

получается типа как go, самозапускаемые сервисы.

ну вообще это основная идеология Jetty. и это правильно.

вообще twitter весь на jetty и вроде как одноклассники. представляете нагрузку? что касается ajp по сути оно нафиг не нада. там вся разница что текстовые http-заголовки передаются в бинарном виде, т.е. считается что их легче парсить. надо понимать что «в боевом» приложении парсинг заголовков занимает 0.0001% а все остальное это бизнес-логика, запросы к БД итп то даже 10-ти кратное ускорение парсинга даст общий прирост 0.00009% - на пороге инструментальной погрешности измерения. именно поэтому на этот протокол все положили болт...

суть в том что раньше было «модно» держать несколькл «сайтов» на одном «сервере».

jetty это не просто высокопроизводительный сервер. он в основном расчитан на hi-load сценарий работы под высокой нагрузкой когда обычно несколько «серверов» крутят один «сайт» а перед ними стоит network load balancer. поэтому концепция «несколько сайтов на одном сервере» это не про него.

помимо всего прочего надо понимать что «несколько сайтов на одном сервере» крутятся в рамках одного процесса java-машины, а это накладывает определенные ограничения и условия. поэтому такой подход сейчас по сути считается «древним» и «устаревшим»...

опять же если очень надо то на одном физическом сервере можно запустить несколько экземпляров под разные сайты (на разных сетевых интерфейсах или портах или в докер-контейнерах)