SP
экономия подразумевается на парсинг HTTP?
Size: a a a
2019 December 17
PK
Да
PK
И на цикл encoding/decoding поскольку nginx в любом случае стоит перед ковбоем
c🦊
Слушайте, а никто не думал о том, что вместе ковбоя можно использовать nginx к которому дописать плагин, который будет конвертить http запросы в erlang distibuted протокол и выступать как отдельная нода, чтобы максимально эффективно сделать работу с http?
Идея вообще огонь
СИ
Слушайте, а никто не думал о том, что вместе ковбоя можно использовать nginx к которому дописать плагин, который будет конвертить http запросы в erlang distibuted протокол и выступать как отдельная нода, чтобы максимально эффективно сделать работу с http?
ML
Ты наверное не оценил ожидаемые проблемы от передачи результата по distributed?
Даже 40 мегабит для distributed уже проблема
Даже 40 мегабит для distributed уже проблема
СИ
И на цикл encoding/decoding поскольку nginx в любом случае стоит перед ковбоем
тут вряд-ли профит будет, потому-что в любых балансировочных схемах с nginx у тебя 99% будет ванильный nginx даже перед nginx с конвертером
PK
тут вряд-ли профит будет, потому-что в любых балансировочных схемах с nginx у тебя 99% будет ванильный nginx даже перед nginx с конвертером
у нас tcp балансер, заводит трафик на ноду, где уже стоит nginx и за ним эрланг с ковбоем
PK
Ты наверное не оценил ожидаемые проблемы от передачи результата по distributed?
Даже 40 мегабит для distributed уже проблема
Даже 40 мегабит для distributed уже проблема
У меня кейс, когда очень много маленьких http/json запросов.
ML
у нас tcp балансер, заводит трафик на ноду, где уже стоит nginx и за ним эрланг с ковбоем
А нафига тебе nginx перед ковбоем?
PK
Терминировать ssl как минимум
PK
но вообще админы очень часто хотят закрывать ковбой nginx'ом
PK
Да, и эти мысли ещё в контексте недавного разговора про производительность второго ковбоя.
PK
Но хочется и не терять http/2.0 и иметь максимальную производительность.
PK
Про возможные проблемы от erlang distribution думал, меня тоже это смущает.
PK
Но пока других вариантов не вижу.
c🦊
Про возможные проблемы от erlang distribution думал, меня тоже это смущает.
Тогда вариант сделать upstream в nginx, который в binary Erlang term будет запрос упаковывать, а не в http
c🦊
Как минимум на парсинге http сэкономить получится
СИ
Про возможные проблемы от erlang distribution думал, меня тоже это смущает.
На одном хосте если будут то норм или даже локально там траблы?
PK
Тогда вариант сделать upstream в nginx, который в binary Erlang term будет запрос упаковывать, а не в http
И слать по голому tcp, выкинув erlang distibution?