Сетевой вопрос
Oct. 9th, 2016 06:21 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ermouthХэлп нидед ) Разбираюсь с ненормальными задержками в пролезании данных, ситуация описана в одном из недавних постов.
Детали такие:
- есть два клиентских браузера и сервер между ними
- в одном браузере в какой-то документ вносится правка, она сохраняется в локальную базу
- также браузер немедленно пытается отправить правки на сервер, это серия из 2-3 коротких запросов, каждый в пределах килобайта; несколько запросов нужно для согласования дерева ревизий
- если связи нет, браузер повторяет попытку каждые ~20 секунд, аналогично если репликация завершается с ошибкой
- браузер на другом конце отслеживает изменения longpoll-запросом, который обрывается и возобновляется каждую минуту
- этот запрос – подписка на канал изменений в БД, как только в базе что-то поменялось, оно появляется в этом канале
- подписка на канал имеет параметр since, в котором указывается номер обновления, с которого надо начинать слив; так браузер получает обновления “из прошлого” после обрывов
- один клиент соединён через 3G, второй через спутник
- одновременно с браузером работал вайбер, никаких проблем с доставкой сообщений в вайбере не было.
Дополнительно:
- протокол репликации надёжно работает на 14400 (<2kb/s) с latency в 1 секунду и обрывами каждые 30 секунд, в рассматриваемом случае мы имеем лучшие условия
- у меня не воспроизводится проблема ни при каких комбинациях сетевых параметров и нагрузок, худшее, что я смог получить – две минуты задержки
- в логах сервера ничего не видно, на сервере в БД конфликтов нет (то-есть не было таких ситуаций, что два человека пишут в один документ одновременно)
- логи в браузерах клиентов уже затёрты, там log rotate и небольшой объём.
Вообще, нормальная задержка в пролезании – единицы секунд, на хороших сетях – меньше секунды. В нашей ситуации люди иногда видели лаг в часы. Я хз вообще, куда думать.
Тут что-то экзотическое – и скорее всего, сетевое. Может, у кого-то из уважаемых френдов есть догадки?
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2016-10-09 05:45 pm (UTC)no subject
Date: 2016-10-09 06:04 pm (UTC)Ога, и на несколько часов придерживают )
Не, думаю тут что-то чисто инженерное, race какой-то.
no subject
Date: 2016-10-09 10:31 pm (UTC)1. Не очень понятно, причём тут вайбер - совершенно непоказательно, на мой взгляд. Ты рассказываешь про проблемы на пути A - B - C (A это клиент, C это клиент на том конце, а B это сервис). Если Вайбер работает так же как Skype, то Вайбер это либо A - C, либо или A - X - C, где X это какой-то сервер вайбера или же один из общих контактов (да, этот сволочной Скайп гоняет шифрованный трафик через общих контактов, если это помогает для более хорошей связи!).
2. Добавь инструментарий, чтобы узнать точно, проблема на куске A - B, B - C или на обоих. Тебе нужен такой протокол логгинга, который скорректирует проблемы несинхронизированных часов.
3. Повторять попытку каждые 20 секунд нужно только если рвётся соединение. В остальных случаях я бы рекомендовал на стороне A тоже держать одно long-poll соединение. Открытие нового TCP соединения это куча оверхеда, но главное - тормозня может возникнуть не просто из-за обмена handshake'ами, а из-за физических промежуточных девайсов (раутеры, свитчи, netscalers, etc). Они могут кэшировать существующие TCP соединения и давать по ним зелёный свет, а для новых соединений тормозить - по куче разных причин (misconfiguration, overload, etc, etc).
4. А ещё, открытие нового соединения - это DNS lookup. Который обычно кэшируется, но это just yet another potential failure point. Ты можешь изолировать эту проблему, если DNS lookup сделаешь вручную отдельным вызовом, а потом будешь открывать повторные соединения по IP. Хотя, опять же, я рекомендую один long poll.
5. Вайбер наверняка использует другой порт. Где-то посередине может быть traffic shaping (QoS или какие-то ограничители по полиси), завязанный на порты.
no subject
Date: 2016-10-10 07:50 am (UTC)1. Вайбер просто показывает, что last mile-ы с обеих сторон не разорваны физически.
2. У меня есть удовлетворительно синхронизированные отсчёты (номер обновление БД, типа USN в Active Directory) и инструментарий есть – только надо доработать логгер, чтобы log rotate не через 500Кб наступал.
3. Держать открытое исходящее POST-соединение никак не выйдет по целому набору причин. Главная: много какой пограничный софт считает атакой несколько открытых пост-запросов, по которым не идут данные.
4. Этой проблемы точно нет.
5. Это я рассматриваю как вариант.
Главная проблема у меня сейчас – нет того оборудования и соединения, с которым были проблемы, и его затруднительно имитировать.
Мне вчера подсказали, что я слишком оптимистичен насчёт latency 1s, для спутника это может быть и больше 2 секунд. На 2-3 секунды latency _всё время_ система действительно не расчитана, можно получить race. Подозреваю, что-то в таком духе и происходит.
no subject
Date: 2016-10-10 07:55 am (UTC)3. А почему нужен HTTP-POST? Нельзя ли сделать обычное TCP соединение, уровнем ниже, чем HTTP, или JavaScript не даёт нужных APIs?
У спутника действительно может быть "стабильно пару секунд", при некоторых обстоятельствах, конечно. Но, благо, имитировать задержку ведь должно быть нетрудно. Есть жестокий, но простой/быстрый способ: добавь на сервере 2 секунды ко всему и посмотри, не валятся ли другие клиенты :)
no subject
Date: 2016-10-10 08:11 am (UTC)Есть вебсокеты ещё, но там проблем больше чем преимуществ в моём случае.
> Есть жестокий, но простой/быстрый способ
Есть ещё быстрее – задать прямо в браузере throttling. Оказывается, Хром даёт не просто набор predefined-настроек, но можно и свои добавлять.
Я вот только что сделал 3s latency и 5кбит/с uplink, и, похоже краешек жопы уже увидел )
no subject
Date: 2016-10-10 08:16 am (UTC)Реально плохой коннект - это не просто 3s, а что-то вроде диапазона от 3 до 8, и ещё 10% packet loss. На прошлой работе у нас даже был специальный Wifi ssid, подключившись к которому ты получаешь вот такой лажёвый коннект. Типа потестировать свой мегасерис в более реальных условиях, а то в обычной обстановке там пинги 1-10 мс, скорость 1 гигабит/сек и без packet loss :)
no subject
Date: 2016-10-10 08:18 am (UTC)no subject
Date: 2016-10-13 11:38 am (UTC)no subject
Date: 2016-10-13 11:49 am (UTC)no subject
Date: 2016-10-13 12:03 pm (UTC)