еще одно поле в табличке, типа job_owner_id

главное в такой схеме, что сами воркеры могут быть вообще на разных машинах даже

>мультиплекс это очень важная фича нет, потому что HOL Blocking.

HOL как-раз и решается мултиплексом, поэтому я немного удивлён слышать что мултиплекс не нужен?!

пфф, ну добавить id каждому

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

Ладно, я придираюсь)

HOL как-раз и решается мултиплексом, поэтому я немного удивлён слышать что мултиплекс не нужен?!

у тебя там внизу tcp-соединение, поверх которого фрейминг. если какая беда случается, то аффектит вообще все, а не только 1 коннект

у тебя там внизу tcp-соединение, поверх которого фрейминг. если какая беда случается, то аффектит вообще все, а не только 1 коннект

ну ясное дело, однако какова вероятность?

ну и да, на long fat network да с потерями запросто получишь невозможность утилизировать всю полосу

а скорее, вообще все будет еле ползать

ну ясное дело, однако какова вероятность?

шумный wifi, перегруженная 3g/4g сота

шумный wifi, перегруженная 3g/4g сота

ты уверен что если у тебя wifi band похерится то спасут 6 TCP/IP соединений?

они-же все встанут по идеи

я думаю, @irc0p может больше вариантов рассказать когда такое бывает

ты уверен что если у тебя wifi band похерится то спасут 6 TCP/IP соединений?

я не просто уверен, я это неоднократно видел

когда tcp window маленький, то печаль-беда

я не просто уверен, я это неоднократно видел

получается в HTTP/2 это не учли?

ну и да, на long fat network да с потерями запросто получишь невозможность утилизировать всю полосу

о какой полосе речь вообще? вот у меня 100 мегабит полоса - как мне ее утилизировать-то? всем насрать сегодня, даже на мобилке при нормальном сигнале полоса на порядок избыточная

о какой полосе речь вообще? вот у меня 100 мегабит полоса - как мне ее утилизировать-то? всем насрать сегодня, даже на мобилке при нормальном сигнале полоса на порядок избыточная

полоса у тебя может быть хоть 10гбит, но если latency там 2с секунды, тебе понадобится огромное окно

так и лейтенси сегодня все хорошо

о какой полосе речь вообще? вот у меня 100 мегабит полоса - как мне ее утилизировать-то? всем насрать сегодня, даже на мобилке при нормальном сигнале полоса на порядок избыточная

и ты смотришь как оптимист, не глядя на реалии

о какой полосе речь вообще? вот у меня 100 мегабит полоса - как мне ее утилизировать-то? всем насрать сегодня, даже на мобилке при нормальном сигнале полоса на порядок избыточная

+ У меня давно ощущение, что сети по умолчанию можно считать быстрыми, но ненадёжными

жаэе на мобилке rtt единицы миллисекунд

и ты смотришь как оптимист, не глядя на реалии

да ладно :) я же делал мобильную рекламу

Смотря докуда, смотря вообще какой кейс

+ У меня давно ощущение, что сети по умолчанию можно считать быстрыми, но ненадёжными

тут вопрос был в том, надёжнее ли HTTP/1.1 со своими 6-8 параллельными TCP/IP соединениями без мултиплекса, или HTTP/2 со своим 1 TCP/IP соединением но с мультиплексом

а вот тут прячется ответ

Проверочное задание - понять, почему openvpn / tcp работает в разы медленнее udp

6-8 параллельных ssl это дорого для сервера

жаэе на мобилке rtt единицы миллисекунд

Да ну?

и именно эту проблему решает гугл. для себя!

6-8 параллельных ssl это дорого для сервера

да вот и я о чём

Проверочное задание - понять, почему openvpn / tcp работает в разы медленнее udp

+много. Особенно интересует вариант с пакетлосс

это, кстати, не всегда так

6-8 параллельных ssl это дорого для сервера

Это почему?

потому, что RSA

плюс 6х - 8х прирост голода на память

сегодня мы в проц упираемся - у нас тупо rsa пары медленно генерятся

потому, что RSA

Один раз

это как?

в 6х - 8х больше file-descriptor'ов на котоых select'ить (хотя я не уверен насколько это дороже для современных kqueue, epoll)

жаэе на мобилке rtt единицы миллисекунд

50ms, вот только проверил - 65ms до ya.ru

в 6х - 8х больше file-descriptor'ов на котоых select'ить (хотя я не уверен насколько это дороже для современных kqueue, epoll)

O(1)

50ms, вот только проверил - 65ms до ya.ru

и не факт что долетит

O(1)

в любом не может быть 6-8 соединений настолько же дёшево как 1

50ms, вот только проверил - 65ms до ya.ru

у меня - 30. видимо, что-то изменилось

и не факт что долетит

Да, на радио не такое бывает

у меня - 30. видимо, что-то изменилось

Сильно зависит от соты, ее загруженности и ещё кучи факторов

угум

но даже 30 - это очень мало

т.е. я правильно понимаю что HTTP/2 хуже себя поведёт в случае высокого packet-loss?

так же он себя поведет

просто ретрансмиты будут все соединения тормозить, а не одно

так же он себя поведет

я просто предполагал что @pragus имеет ввиду, что при наличии нескольких TCP/IP соединений, когда например соединение 1 делает запрос но валится - он естественно откатывается на sleep чтоб предотвратить загрузку и без того загруженной сети а следующий запрос будет осуществлять соединением 2, и тут например сеть будет менее насыщеной и поэтому потери пакетов не будет и запрос выполнится ещё до того, как соединение 1 перепошлёт свой первый запрос так? т.е. если у нас несколько соединений, то timeout wait на каждое соединение индивидуально и вероятность восстановления сети до timeout'а выше, следственно throughput чуток выше но latency инициализации соединений будет больше чем с 1 и памяти больше будет жрать, и если в сети потерь мало, то всё это - напрасно

эммм

если мы не уперлись в полосу - а мы не уперлись - мы уперлись в rtt

rtt у нас одинаковый, что мы один пакет шлем, что 10

latency будет одинкавая, соответсвенно, хоть 1 соединение устанавливай, хоть 10

но если соединение одно с мультиплексированием - на один пакет, в среднем, больше информации приходится, и потеря его, соответственно, больнее отзывается

rtt у нас одинаковый, что мы один пакет шлем, что 10

мм, я думаю я не про round-trip-time, a про retransmit delay

если мне не отказывает память, то TCP/IP старается беречь сеть нагружая её меньше обнаружив packet loss

latency будет одинкавая, соответсвенно, хоть 1 соединение устанавливай, хоть 10

А сколько алгоритмов congestion control у нас будет исполняться в случай 1 и 10 соединений?

т.е. от первого retransmit до второго может вырасти delay

А сколько алгоритмов congestion control у нас будет исполняться в случай 1 и 10 соединений?

по одному на соединение, понятное дело

А сколько алгоритмов congestion control у нас будет исполняться в случай 1 и 10 соединений?

короче если я тебя правильно понял, то в сетях с большой потерей - несколько соединений выгоднее потому-что congestion control откатывает на более высокий delay индивидуально на каждое соединение (однако непредсказуемо, насколько это выгодно, зависит от сети, как повезёт) а в случае сетей с низким уровнем потерь или вообще их отситствием - несколько соединений лишь сжирают лишнюю память и CPU

Сетей без потерь не бывает, или бывают, но на некоторое время, и при некотором объеме траффика

вопрос в сочетании количества потерь и latency.

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

Сетей без потерь не бывает, или бывают, но на некоторое время, и при некотором объеме траффика

суть я думаю в том, что networtk congestion чаще возникает не из-за interference'а беспровоной сети, а переполнения буферов роутеров. В таком случае, если packet loss происходит в результате router buffer excess - ни 2, ни 8, ни 100 паралелльных TCP/IP соединений в теории не спасут и не будут агировать лучше одного единственного

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

для серверов

короче если я тебя правильно понял, то в сетях с большой потерей - несколько соединений выгоднее потому-что congestion control откатывает на более высокий delay индивидуально на каждое соединение (однако непредсказуемо, насколько это выгодно, зависит от сети, как повезёт) а в случае сетей с низким уровнем потерь или вообще их отситствием - несколько соединений лишь сжирают лишнюю память и CPU

Да, объем передаваемых данных один и тот же Ну за счёт того что они размазаны по нескольким соединениям tcp не настолько пессимистичен

суть я думаю в том, что networtk congestion чаще возникает не из-за interference'а беспровоной сети, а переполнения буферов роутеров. В таком случае, если packet loss происходит в результате router buffer excess - ни 2, ни 8, ни 100 паралелльных TCP/IP соединений в теории не спасут и не будут агировать лучше одного единственного

Там вообще все сразу

Да, объем передаваемых данных один и тот же Ну за счёт того что они размазаны по нескольким соединениям tcp не настолько пессимистичен

интересная мысль однако. Нужно подумать как реализовать поддержку нескольких underlying TCP/IP с round-robin в webwire-go, для конкретно таких случаев спасибо за мысль!

интересная мысль однако. Нужно подумать как реализовать поддержку нескольких underlying TCP/IP с round-robin в webwire-go, для конкретно таких случаев спасибо за мысль!

По этой причине, например, syncthing на длинных дистанциях не может делегировать всю полосу

По этой причине, например, syncthing на длинных дистанциях не может делегировать всю полосу

да уж, это хреново. в любом случае нужно тестировать, создать виртуальную сеть с симуляцией больших потерь и опробовать на ней webwire 2.0, попробовать добавить поддержку нескольких underlying соединений в 2.1 и сравнить throughput & latency

в идеале webwire должен сам понять, какое колво соединений в каком случае лучше использовать учитывая какое макс. колво разверешает сервер... но это уже звучит сложнее..

да уж, это хреново. в любом случае нужно тестировать, создать виртуальную сеть с симуляцией больших потерь и опробовать на ней webwire 2.0, попробовать добавить поддержку нескольких underlying соединений в 2.1 и сравнить throughput & latency

tc-netem в помощь ;)

tc-netem в помощь ;)

👍🏻

На стороне сервера ты вынимаешь значение из query, а надо десереализовать тело запроса

Вот, но с помощью не родного роутера, а с посредством gin (вообще, рекомендую) https://medium.com/go-to-golang/создания-api-restful-сервера-с-golang-и-mysql-3085133bab91

И вот неплохая статья https://pragmacoders.com/building-a-json-api-in-golang/