LINUX.ORG.RU

Язык+фреймворк с минимальным оверхедом для веба


0

6

Хочу странного. «Для души», практически свои хотелки не обосную.

Язык обязательно статически типизированный. Должен работать со скоростью порядка Java. C, C++, D, Rust и всё такое.

Асинхронная обработка запросов. Полностью. В node.js это близко к идеалу. Любой I/O должен переключать управление на следующий запрос. И всё это с минимальным оверхедом, чтобы могли лежать миллионы коннектов без значимого проседания, пока процессора и памяти хватает. Естественно коннект не должен занимать много памяти. Экстрима в десятки байтов не надо, но и сотни килобайтов тоже.

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

Нормальный развитый REST-фреймворк. Каких то особых требований нет, он просто должен работать и обеспечивать более-менее удобный интерфейс. Естественно полностью асинхронный.

Очень хочется мегабыстрого шаблонизатора. Который будет работать не в разы медленней, чем выплёвывание в сокет текста и подставленных значений переменных.

Общее потребление памяти должно быть вменяемым после старта. 10 мегабайтов это вменяемо. 500 мегабайтов это не вменяемо.

Что я пока видел.

Node.js. Первый минус - динамический JS. Второй минус - однопоточность. Но асинхронность сделана идеально, синхронный вызов найти надо постараться.

Java: практически нигде нет нормальной асинхронности, модель «поток на запрос» доминирует. Драйверы JDBC все синхронные. Что-то такое есть в Play, но это скала с её десятками и сотнями мегабайтов потребления оперативной памяти.

Go: есть интересный фреймворк revel. Но я пока не понимаю модель многопоточности в Go, какие у неё затраты. Как я понимаю, накладных расходов куда больше, чем в случае node.js.

Rust. Сама идея этого языка мне нравится, но нет нормальных библиотек. Какое то teepee вроде пилят, но хз когда допилят. И опять же не совсем понимаю модели многопоточности и накладных расходов.

В идеале я бы хотел видеть Java (не Scala!). Поверх Netty должна быть написана полностью асинхронная (это важно!) прослойка, которая даёт удобный способ работы с асинхронным API, посредством Promises. Учитывая, что в Java 8 все эти лямбды должны достаточно неплохо оптимизировать, работать оно должно шустро. Плюс надо написать асинхронный драйвер к постгресу на Java. Но такого нигде нет и вряд ли будет :( Даже думал запилить, но вряд ли потяну, сложная штука, нужен реально башковитый чувак, чтобы такое сделать как положено.

Собственно хотелось бы узнать, может я чего упускаю? И, если кто хорошо понимает потроха Go и/или Rust, может популярно объяснит, какие накладные расходы там идут в случае «зелёных» потоков, как система отнесётся к миллиону спящих на I/O задач.

Возможно есть какой-то фреймворк для C? Какое-нибудь расширение nginx-а? Хотя асинхронное программирование на C это, наверное, тот ещё изврат.

★★★★★

Последнее исправление: Legioner (всего исправлений: 1)

elixir во многом соответствует запросам, кроме наверное типизации. Выглядит интересным.

anonymous
()

Очень хочется мегабыстрого шаблонизатора. Который будет работать не в разы медленней, чем выплёвывание в сокет текста и подставленных значений переменных.

xml+xslt

anonymous
()

Хотя асинхронное программирование на C это, наверное, тот ещё изврат.

Почему это? УМВР.

Eddy_Em ☆☆☆☆☆
()

Erlang, да. Сервер cowboy, шаблонизатор erlydtl - жанговские шаблоны, с iolist. По памяти будет просасывать, остальное как раз то что тебе надо.

Еще варианты - lua модуль для nginx. Или обычный php с apc акселератором - скорость будет отличная, масштабируемость тоже 100%. Scala с Akka. Go тоже пойдет, но он неудобнее эрланга как язык. Нода однопоточная, придется поднимать несколько экземпляров сервиса или вручную запускать форки или использовать http://nodejs.org/api/cluster.html . А еще нода течет.

Скорость языка для мнопопоточных веб-приложений, работающих на многопроцессорных серверах, понятие бессмысленное. Один поток заблокирует виртуальную машину, и вся скорость пойдет по женскому половому органу. Ну и затык будет по любому в i/o. Ну переключится у тебя выполнение на другой запрос пока i/o ждет, очередь все равно не бесконечная, запросы будут накапливаться в очереди пока все не рухнет. И синхронизацию так или иначе придется делать, если у тебя есть перации изменения бд. А синхронизации, если не правильно написаны, валят сервисы только в путь.

shimshimshim
()
Ответ на: комментарий от shimshimshim

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

shimshimshim
()

Асинхронная обработка запросов. Полностью.

Асинхронность нужна, когда поход за данными занимает слишком много времени, а это менее 1% случаев (или нужно смотреть где ты лажанулся с БД). Нода асинхронная не потому, что так лучше, а потому, что авторы не осилили многопоточночть.

ya-betmen ★★★★★
()

Возможно есть какой-то фреймворк для C?

У меня, конечно, были подозрения и до этого пункта, но далеко ты с этим в вебе не уедешь, любитель char*-кактусов.

anonymous
()
Ответ на: комментарий от umren

Язык+фреймворк с минимальным оверхедом для веба

Go + Revel/Beego.

Плюсую :)

home_user ★★★
()
Ответ на: комментарий от ya-betmen

Нода асинхронная не потому, что так лучше, а потому, что api над v8.

очевидный фикс

umren ★★★★★
()
Ответ на: комментарий от umren

Там скорее всего и данные по другим языкам устарели, но не сильно. Думаю плюс-минус все верно, с точностью до десятков процентов.

shimshimshim
()

visual basic .net

anonymous
()

Scala + spray или go + revel

dizza ★★★★★
()
Ответ на: комментарий от Eddy_Em

Это потому, что ты не программер и у тебя нет менеджера над душой. А нам надо что бы тяп ляп и зашибись работало.

dizza ★★★★★
()
Ответ на: комментарий от anonymous

Revel/Beego.

Оба чересчур жирные.

Лорчую

gorilla/mux

ИМХО, gocraft/web поприятнее.

И ТС, горутины действительно очень дешевые. В среднем можно рассчитывать примерно на 4,5kb на горутину.

anonymous
()
Ответ на: комментарий от dizza

у тебя нет менеджера над душой

Есть. Называется научный руководитель проекта. Но "тяп-ляп и работало" не проканает! Надо как можно надежней.

Eddy_Em ☆☆☆☆☆
()

haskell по всем пунктам

Debasher ★★★★★
()
Ответ на: комментарий от bismi

Уже по «Polyglot. You can write your application components in JavaScript, Ruby, Groovy, Java or Python, and you can mix and match several programming languages in a single application.» очевидно, что там абстракция на абстракции абстракцией погоняет и производительности от него не дождёшься. Но спасибо, посмотрю ещё.

Legioner ★★★★★
() автор топика

Но я пока не понимаю модель многопоточности в Go, какие у неё затраты. Как я понимаю, накладных расходов куда больше, чем в случае node.js.

Go задумывался как язык с удобной и легковесной многопоточностью. Как на практике вышло — не в курсе. Но факт, что это один из его краеугольных камней.

KRoN73 ★★★★★
()

У сервлетов есть async context, spring mvc умеет возвращать DeferredResult или Future, есть Akka, на которую я уже давно облизываюсь, но применить пока негде. Вот асинхронных jdbc драйверов я не видел :(

f1xmAn ★★★★★
()
Ответ на: комментарий от f1xmAn

Есть асинхронный драйвер для постгреса, но он на скале.

Legioner ★★★★★
() автор топика
Ответ на: комментарий от f1xmAn

На самом деле асинхронный бд драйвер не нужен. Юзай тред пул, один фиг потоков делать больше чем в конекшен пуле конекшнов смысла нет, а теперь посмотри какой там Макс стоит? Сто? Пфф

dizza ★★★★★
()
Последнее исправление: dizza (всего исправлений: 4)
Ответ на: комментарий от dizza

На самом деле асинхронный бд драйвер не нужен. Юзай тред пул, один фиг потоков делать больше чем в конекшен пуле конекшнов смысла нет, а теперь посмотри какой там Макс стоит? Сто? Пфф

Что мешает поставить в конекшен пуле 10000? И подключаться к десятку БД (лоад-балансированных)?

Legioner ★★★★★
() автор топика

Go: есть интересный фреймворк revel. Но я пока не понимаю модель многопоточности в Go, какие у неё затраты. Как я понимаю, накладных расходов куда больше, чем в случае node.js.

Будь мужиком, запусти и проверь. Кстати можно и не пользоваться revel, просто http модуль и вперде. Думаю компактнее не выйдет по сравнению с этим нигде. Разве что С или С++

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)

взял и haskell описал... ну ладно, ищи дальше.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Потому что Warp, наверное? :) Я помню, что Warp как-то моднее работал с IO, чем Happstack, но, увы, без подробностей.

yoghurt ★★★★★
()
Ответ на: комментарий от Legioner

Довольно странная конфигурация. Ты к десятку серверов бд будешь с одной машины ходить? Скорее ты будешь со ста (или больше) машин бекендов ходить на десяток бд серверов, соответсвенно больше, чем по сто конекшнов на один бекенд сервер не нужно. Ну если тебе надо с одной машины ходить, наверное тебе асинхронный драйвер пригодится, но я такой кейс не представляю.

dizza ★★★★★
()
Последнее исправление: dizza (всего исправлений: 1)
Ответ на: комментарий от dizza

Довольно странная конфигурация. Ты к десятку серверов бд будешь с одной машины ходить?

Почему бы нет?

Скорее ты будешь со ста (или больше) машин бекендов ходить на десяток бд серверов, соответсвенно больше, чем по сто конекшнов на один бекенд сервер не нужно. Ну если тебе надо с одной машины ходить, наверное тебе асинхронный драйвер пригодится, но я такой кейс не представляю.

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

Legioner ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Да, уже разбираюсь, неплохая штука, хотя и странная местами.

Legioner ★★★★★
() автор топика
Ответ на: комментарий от anonymous

А в какой из строчек говорится про «жирность», я что-то не узрел?

Из того, что я прочитал, автор пытался получить доступ к переменной контроллера из фильтра (то, что он называет middleware), для этого он использовал много рефлекшена.

Для справки, фильтры в Revel - метод организации базовых компонентов (Session, Cache, Flash, I18n, Compression, etc). Т.е. принцип такой: не нравится, как работает тот или иной компонент, пишешь свой (берешь сторонний) и подключаешь вместо базового. Таким образом, достигается полная кастомизируемость и расширяемость.

Для юзкейса автора нужны были не фильтры, а интерцепторы (это тоже middleware, но на уровне повыше; могут выполняться Before, After, Finally). Почему он не использовал их, не знаю. Можно глянуть по дате коммитов, фильтры в Revel появились на год позже интерцепторов. Т.е. это точно не связано с тем, что на момент написания статьи такого механизма не было, он был. Скорее всего, дело просто в том, что мало кто читает документацию, предпочитая писать свои решения вместо этого.Ещё один из аргументов автора против использования каких бы то ни было фреймворков вообще в том, что он не хочет INI подобный конфиг, а хочет использовать ENV переменные или формат TOML. Внезапно, в Revel ENV переменные поддерживались всегда. Что касается TOML, в самое ближайшее время появится возможность цеплять любые конфиги файлов.И ключевой момент. Фреймворк - это не только роутинг, сессии и организация middleware. Это ещё Reverse routing, auto forms, валидация данных, кеш с поддержкой RAM, Memcached и Redis из коробки, i18n, авто перекомпиляция при изменении кода - вообще must have.Кроме того, нужно создать issue в багтрекере выбираемого фреймворка и посмотреть, как быстро вам ответят и насколько ответ будет информативен.

anonymous
()
Ответ на: комментарий от anonymous

Ещё один из аргументов автора против использования каких бы то ни было фреймворков вообще в том, что он не хочет INI подобный конфиг, а хочет использовать ENV переменные или формат TOML. Внезапно, в Revel ENV переменные поддерживались всегда. Что касается TOML, в самое ближайшее время появится возможность цеплять любые конфиги файлов.

И ключевой момент. Фреймворк - это не только роутинг, сессии и организация middleware. Это ещё Reverse routing, auto forms, валидация данных, кеш с поддержкой RAM, Memcached и Redis из коробки, i18n, авто перекомпиляция при изменении кода - вообще must have.

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

anonymous
()

Разобрался поближе с Go.

Плюсы:

+ Хорошие потоки. Планировщик O(1), накладных расходов мало, отлично интегрированы в язык.

+ Каналы. Удобная синхронизация и обмен информацией между потоками. + Сборщик мусора. Неплохой, будет ещё лучше.

+ Реализация. Всё сделано очень солидно. Над ним работают крутые дядьки. На нём пишут в гугле и он явно никуда не денется в ближайшие годы.

Минусы:

- Обработка ошибок. Хотя исключения есть, в стандартной библиотеке и других библиотеках они практически не используются. Старые недобрые коды возврата. OMG.

- Шаблоны (Generics). Их нет.

Для меня минусы оказались непреодолимыми. Писать if после каждой строчки я не хочу.

Следующий на очередь Erlang.

Legioner ★★★★★
() автор топика
Последнее исправление: Legioner (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.