Как справляетесь со слишком большой задержкой между серверами?

Ответ в стиле постановки вопроса, когда «базы любого вида», оптика 10гбит между серверами.

За более подробным ответом потрудитесь схему изобразить.

DigitalOcean, Private network между серверами в одной сети, из ответов людей там достижима скорость на обычных инстансах 1-2Гбит, т.е. там явно есть коннект в 10гбит.

Тогда вопрос к k8s и тем, кто это хозяйство поддерживает… Есть метрика на руках? Отправьте ее в саппорт, пусть репы почешут.

меньше запросов и больше данных за запрос

Не угадал. Лучше больше коротких и простых запросов. Чем проще запрос, тем он менее специфичен, а это лучше для кэширования. Проще говоря, лучше иметь 1000 запросов из которых 99% будут кэшироваться и использоваться повторно из кэша как есть, т.к. параметры не меняются, чем 10 запросов которые не будут кэшироваться т.к. каждый запрос имеет уникальные параметры. Кроме того кэш проще инвалидировать, если запросы простые, т.е. имеют минимум зависимостей.

Как с этим справляются с админ-стороны?

Никак.

но не наткнулся ни на одно обсуждение в плане снижения задержек

Потому что любой прокси увеличивает задержки, а не снижает.

есть ещё и TCP/IP, авторизация, и прочее

Как-будто у тебя там HFT на расте крестах и ты ищешь где бы ещё пару наносекунд срезать. Люди для которых TCP/IP является лимитирующим фактором и так знают куда копать. А ты иди пинай криворуких макак, которые написали это твоё тормозилово.

Со стороны кода - понятно, меньше запросов и больше данных за запрос.

Икнул. Или не понял.

меньше запросов
и больше данных за запрос

Гонять select * from table1 outer join table2 outer join table3.... outer join tableN
Вы за это? Или ваши макаки такое написали и вы против?
Если второе то только вариант иметь мозг макакам.

авторизуются один раз, держат связь с сервером и гоняют туда-сюда сжатые команды.

Авторизация и сам сикул запрос это скорее копейки, по сравнению с полученными данными. Не всегда, но вы не описали полный кейз.

Он по-моему сам с трудом понял, что написал. Лично я перечитал дважды, но телепат во мне сегодня так и не проснулся.

И таки да, приветствую Вас, товарищ anc. Я тот самый анон, приходящий раз в три года и сетующий на молодежь, а Вы убеждаете, что еще не все пропало:)

Приветствую анона. Но, уж простите меня, за три года всех не запомнишь :)
ЗЫ Тут и регистранты бывают путаются :)

Да ничего:) Итераций 3 летних было много, ну да ладно. Конечно не упомнить. Как Ваши успехи?

Икнул. Или не понял.

Батчинг (в случае с redis) когда берёт за один запрос не один объект, а пачка.

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

Короче, очевидные оптимизации, которые очевидны.

Гонять select * from table1 outer join table2 outer join table3…. outer join tableN Вы за это? Или ваши макаки такое написали и вы против?

Не, ещё не докатился до такого

Обычный цикл у ORM-ов, которые с кешем - посмотрел в кеш -> пусто? стукнуля за объектом в SQL, положил объект в кеш, следующий… Поэтому, когда пишут код сначала втупую, получается много коротких запросов.

Если крутить базу данных и кеш на одной и той же железке, скорость работы 1x. Если вынести redis и базу на отдельный сервер - я получил где-то 0.4x у Digital Ocean.

Отсюда у меня возник вопрос, есть-ли какие способы это подтюнить со стороны сервера? Со стороны кода-то всё понятно.

Напомнили интересную простыню которую видел в жизни. Все тоже самое select * from.... но дальше шло where fieldname in ('a','b','c'..... '100500-й') в определенный момент это уперлось в ограничение на длину строки сикул запроса со стороны субд :) Так что говнокод он такой... :)

Подскажите пожалуйста, а для Вас русский - родной язык. Я наверное очень глуп, но я совершенно не понимать Ваши пассажи.

Да, это тот самый случай:)

ну, значит я разучился говорить, бывает.

Нет, я без троллинга. Серьезно. Может конечно лорчанка поразила уже меня. Посмотрим, что скажут коллеги. Но вообще, при проблема в БД обычно анализирует запросы. Включают логгирование медленных запросов. Собирают метрики. У Вас есть что-то из этого?

Пробовали ли Вы всю связку на локальной тестовой машине? Повторяется ли проблема? Или докером сразу в бой?

+1 Не знаю что не знаю как, но помогите. С анализа надо начинать. Что собственно выше обсудили.

Давай попробую перефразировать менее абстрактно.

Редис, установленный на том же сервере, что и софт показывает при redis-cli –latency тесте, допустим, 0.2мс, а при расположении на удалённом сервере - 0.8мс. На локалке так же, как и удалённо на одном сервере. Если ORM нагенерировал запросов, то там с миру по миллисекунде - и съедается их 200, 300, и.т.д. То же самое вытворяет и SQL.

Сейчас вообще без докера - это не он.

Мне было интересно, с этим просто смиряются и работают только с кодом, или есть какие-то варианты основанные на протоколах, которые меньше общаются (как например пытались сделать с http2 и пытаются сделать с http/3)?

Что делать с кодом мне итак понятно, особенно в случае с redis - у него есть MGET, который притаскивает множество ключей почти за то же время, что и один.

Ну а почему сразу так не написали? Я давненько не крутил редис, но на мой взгляд, коллеги выше правильно отправили Вас в сторону кода. Тем более Вы сами написали, что знаете…

Ну а почему сразу так не написали?

Ну потому что не умею.

Потому что сравните первоначальную постановку с тем, что написали здесь Как справляетесь со слишком большой задержкой между серверами? (комментарий)

Ну раз вопрос топика решили, позволю себе немного оффтопа. Товарищ anс, как оцениваете современное положение дел в мире гну? Абстракции абстракций абстракций; докеры, системд вот это все…? По-нашему по-стариковски? А-ли поддерживаете «инновации» по уходу от kiss?

Вы перечислили «абстракции», но образно, то есть совершенно разные по сути понятия. По каждому пункту можно как соглашаться так и нет. По списку:
1. докер - я не сильно против него, но и не за повсеместного использования. Поясню. Нужно понимать для чего его готовим. А то многие в него и субд запихивают. Это касалось ранее и lxc. Бездумное использование молотка для заворачивания шурупа.
Вещь хорошая. Но народ ломанулся пользовать не думая к чему это приведет. Получился этакий «рутрэкер» со сборками «торрентэдишен» только уже для онтопика.
2. системд - идея хороша, реализация всё ещё не очень. Хотя можно сказать что кривая косяков выравнивается. Однако я до сих пор полноценно не воспринимаю эту хрень, по причине того что это хрень.

А-ли поддерживаете «инновации» по уходу от kiss?

Нет!

ЗЫ В другом топике
Каким VPN пользуетесь ? (комментарий)
меня топят за то что ovpn «глюкалово глючное». Потрясающе, ссылка на баг в NM «а виноват конечно слоненок» :) Это я про абстракции накидываю.

абстракции», но образно, то есть совершенно разные по сути понятия

Под абстракциями я имел в виду решения современных хипсто-погроммистов.

А то многие в него и субд запихивают.

Многие? Вы как всегда дипломатичны:) не многие, но некоторве туда и сетевой манагермент пытаются запихать и изобразить полноценную виртуалку. А про субд, так я давно не удивляюсь. Они же так свои «боевые кластеры» плэйбуками размазывают.

Вещь хорошая. 

Чем она хороша? На мой взгляд ее можно юзать только для деплоя в тестовых средах доставки быдлокода тестеровщикам. На бою этой шайтан мойшине не место. Это даже если нивелировать вопрос самой архитектурной реализации сего убер поделия.

системд - идея хороша, реализация всё ещё не очень. Хотя можно сказать что кривая косяков выравнивается.

Между идеей и реализацией - пропасть. У вяленого идея хороша, реализации пока не завезли. Но оно и не внедрено повсеместно….

В целом, Вы как всегда дипломатичны. Сказали все как есть, но обходя острые углы:) а ведь суть есть одна…

другом топике  Каким VPN пользуетесь ? (комментарий) меня топят за то что ovpn «глюкалово глючное».

Ну что Вы! Я хоть и бываю на протяжении всей истории лора здесь в три года раз, но сразу понял, что тот молодой человек с понями, или как оно там, из этих хипстеров. Тред пока не читал, завтра ознакомлюсь, но вангую, что топит он за вайргард, очевидно. Вы у него поинтересуйтесь, а смотрел ли он пермишны клиента вайргарда ндля ведроида. И если да, зачем оно доступ к камере хочет. Овпн для точка - мультиоточка на сегодня - бест солюшн из открытых решений.

Чем она хороша? На мой взгляд ее можно юзать только для деплоя в тестовых средах доставки быдлокода тестеровщикам.

Я только про это. Думал поймете. :)

На бою этой шайтан мойшине не место.

Ага. Но мля куча народа пользует.
ЗЫ Тут навеяло другой недавней темой. Пользует народ тонкие тома в ЛВМ? Пользует. И даже пропагандирует. Только вот нихрена не обращают внимание на просадку по производительности. Точнее даже голову не включает зачем я взял эту кувалду вместо молотка.

У меня постгрес на отдельном сервере, на сервере приложений pg_bouncer который держит готовые конекты к серверу бд. Работает быстро, как будто с того же сервера. Возможно и для редис/mysql такое есть?

Да что Вы, какой wg? Там за ProtonVPN :) А все остальное видимо не заходит у товарища. У него ovpn глюкалово на всех платформах. :)

Протон? А его разве можно развернуть на своем сервере? Что-то ему совсем поплохело. Крутится у одного аутсорс клиента, на пфсенсе овпн 9 лет. Ни единого разрыва. Ни единой жалобы. Плюс оно еще радиусом с ад дружит. Сертификаты и доменная авторизация подтягиваются. Много чего слышал, но чтобы кто-то не осилил в овпн - это что-то… там же прекрасно все документировано!

Ага. Но мля куча народа пользует. 

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

Тут навеяло другой недавней темой. Пользует народ тонкие тома в ЛВМ? Пользует. И даже пропагандирует. Только вот нихрена не обращают внимание на просадку по производительности. Точнее даже голову не включает зачем я взял эту кувалду вместо молотка.

Такие времена…

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

Тут не соглашусь, что это именно «бест солюшн» родовые проблемки у него есть (однопоточность). Но и называть его глюкавым по меньшей мере «перебор». Имхо на текущий момент самый простой в настройке и в части поддержки клиентского софта.

А какие Вы видите достойные, устоявшиеся альтернативы? Которые можно пустить в прод и не иметь головной боли.

Вопросом на вопрос. Для чего? Поясню, для какой цели, выпустить клиента в инет, дать клиенту доступ к корп сети, обьединение корп сетей?
ЗЫ И планируемая нагрузка не указана вами.

Ну я писал о точка-многоточка. В данном контексте хоум офис. Кстати клиент был очень доволен, в карантин все работали из дома в обычном режиме. Благо айпекс мг завезли и настроили коммуникаторы, на мобилках были даже внутренние номера. Вход/выход.

120 клиентов с ключом 4096 тянет один престарелый зеончик не напрягаясь. Конечно речь не о провайдерских решениях. Где все крутится на проприетарном сетевом оборудовании.

Под бест солюшн я подразумевал его нишу.

Отвечу на все разом :)
У меня до сих пор используются три варианта:
1. ovpn
2. ipsec
3. ipsec + l2tp
Все работает годами, но не сказать что не было проблем и изменений.
Из темы которую я приводил выше мой ответ (кусок, а то там больше текста)

Если говорить про ovpn, вот совсем полный список «исторических» проблем.
1. Клиент - Установка dns передаваемого от ovpn сервера: Шин 10, os x, linux(зависило от дистра так что даже не интересно, там отдельная песня) Мобильные платформы не замечены.
2. Сервер/Клиент - изменение cipher (если был слабый) что в принципе логично в части безопастности. Но об этом писали задолго что такое произойдет.
3. Клиент - удаление параметра tls-remote Но об этом писали задолго что такое произойдет.

А так, в качестве замены мешсети на уровне ipsec все ещё думаю попробовать tinc. Но пока нет острой необходимости «работает не трогай».

Зеону 9 лет. Не помню что там стоит.

Пиписек - это все таки о обьединении сетей.

Л2тп - попробуйте сменить на ике2, сейчас модно.

Есть там ряд принципиальных проблем, доставшизся от циски в наследство.

По перечисленным Вами проблемам:

1-решается конфигом 2-тоже решается конфигом 3-честно не помню. Надо гуглить.

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

так, в качестве замены мешсети на уровне ipsec все ещё думаю попробовать tinc. 

Я писал о том, что из опенсорсных для точка-мультиточка лучшего не знаю, чем овпн. И чтобы в прод не страшно. Тинк не крутил. Но рекомендую таки попробовать ике2 в связке с пиписеком.

Все верно. Каждой «софтинке» своё. Я полностью согласен, что как самый простой вариант для клиентского подключения при кроссплатформенности это ovpn. Это не отменяет других вариантов, но в данной теме это можно обсуждать долго.

120 клиентов с ключом 4096 тянет один престарелый зеончик не напрягаясь. Конечно речь не о провайдерских решениях. Где все крутится на проприетарном сетевом оборудовании.

Вот! У всех все работает. И никто не жалуется.
Так же из моего ответа в той же теме:
«У меня сотни пользаков и у всех все робит. Отдельно показала пандемия с самоизоляцией, пришлось в срочном порядке подключать почти всех начиная от секретерей. А зоопарк тот ещё начиная от хрени.»

ага, вот это уже похоже на зацепку - connection pooler, теперь хоть понимаю, как это называется, спасибо

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

На сегодня откланяюсь, пожалуй. Продуктивного Вам наставничества!:)

Зеону 9 лет. Не помню что там стоит.

У меня думаете моложе? :)

Л2тп - попробуйте сменить на ике2, сейчас модно.

Сорри не указал, у меня все варианты и чистые ikev1 и ikev2 и + l2tp. Девайсы у клиентов разные, так что считай «с запасом», что бы не ломать голову когда у кого-то появиться очередной.

По перечисленным Вами проблемам:
1-решается конфигом 2-тоже решается конфигом 3-честно не помню.

Я приписал где клиент а где клиент и сервер. Про мас ос, пункт 1. может и решается унутри конфига tunnelblick, но проще жмякнуть в гуйне другой пункт выбора метода установки dns :) Про linux. Как написал сложнее, зависит от дистра, например в слаке нет готовых скриптов для внесения изменений в /etc/resolv.conf А в современных реалиях(дистрах) «не одним /etc/resolv.conf живы»

3-честно не помню.
Надо гуглить.

Оно там просто, без гули, запустите вам и лог сам подскажет. :)

Убрать тсп-айпи, сунуть все на одну железку и пускай они друг с другом через юникс сокет разговаривают.

Со стороны кода - понятно, меньше запросов и больше данных за запрос.

Со стороны кода - пулл коннектов, к которому обращается код и всегда получает готовое соединение без всяких там установлений соединений и авторизаций - за ними следит то что управляет пулом - это может быть внутри либы в коде (sqlalchemy да питона например) либо "встроено" в платформу (например это касается всяких серверов приложений для java).

Вообще интересно было бы посмотреть как вы это "меньше запросов и больше данных" делаете на асинхронном многопотоке.

Что поставить между кодом и базой уже сказали.

Девайсы у клиентов разные, так что считай «с запасом», что бы не ломать голову когда у кого-то появиться очередной.

Разумно.

Про мас ос, пункт 1. может и решается унутри конфига tunnelblick, но проще жмякнуть в гуйне другой пункт выбора метода установки dns :)

На мой взгляд в проде это не нужно. Есть же прекраснейшее решение на вынь и макак https://www.sparklabs.com/viscosity/

В приведенном выше примере использую его. Никаких доп настроек. Как 9 лет назад поднял, только за апдейтами слежу, да счета выставляю… Рекомендую потраить и просветить болезного в треде! Стоит копейки.

Ознакомился с представленным Вами топиком. Правда так и не понял почему Вы вдруг фанатик. А так же почему Вы позволяете этому бандерлогу в такой форме с Вами разговаривать. Ну дело конечно Ваше.. Вбросьте про вискосити, я не могу, так как от вселенского знания анонимов там огородились :(

Вообще не понятно, человек приобрел на авите мамбук, а на качественный софт жалко грошей? Хороший понт, как говорится, дороже денег! :)

Про linux. Как написал сложнее, зависит от дистра, например в слаке нет готовых скриптов для внесения изменений в /etc/resolv.conf А в современных реалиях(дистрах) «не одним /etc/resolv.conf живы»

То есть это дома Вы сидите под виндой (в чем я ничего зазорного в нашем возрасте не вижу), а на работе юзвера под пингви да еще и шлаченным? Мсье знает толк в извращениях, ал-ли наброс такой?)

Вообще бывали у меня решения на пингвин для планктонины, где 1с+офис=успех. Но только в двух видах: 1) терминальный доступ на тонких клиентах 2) одинаковые дистрибутивы на всех клиентских устройствах. Иное в энтерпрайз…ну как-то по сектантстки)

Под бандерлогом я подразумевал конечно же вымышленный обезьяний народ из «Книги джунглей» Редьярда Киплинга, а так же не всем уже известный советский мультфильм «Маугли», по мотивам все того же Киллинга, а не то, что могли подумать молодые представители племени :)

На мой взгляд в проде это не нужно. Есть же прекраснейшее решение на вынь и макак https://www.sparklabs.com/viscosity/
В приведенном выше примере использую его. Никаких доп настроек. >Как 9 лет назад поднял, только за апдейтами слежу, да счета выставляю…

Значит у вас изначально уже не было проблемы описанной в пункте 2. Тут какой бы не был клиент, платный бесплатный... в любом случае править конфиги как сервера так и клиента.
Пункт 3, тут не исключаю вероятности того, что если ранее в конфиге был параметр tls-remote и клиент сам поправил на verify-x509-name.
Пункт 1, ну как-то не очень вериться, что платное решение так уж оперативно отслеживает все (рандомные, это важный момент) баги ябла. Хотя может оно и так. Сильно спорить не буду. Хотя если у вас не было сервисов связанных с корп dns серверами, то вы могли даже и не заметить тот трэшак.
Итого: Большого желания покупать не возникло. :)

Значит у вас изначально уже не было проблемы описанной в пункте 2. Тут какой бы не был клиент, платный бесплатный… в любом случае править конфиги как сервера так и клиента.

Не могу помнить как конфигурил 9 лет назад, но клиент относится к вопросу 1, надо полагать.

Пункт 1, ну как-то не очень вериться, что платное решение так уж оперативно отслеживает все (рандомные, это важный момент) баги ябла. Хотя может оно и так. Сильно спорить не буду. Хотя если у вас не было сервисов связанных с корп dns серверами, то вы могли даже и не заметить тот трэшак.

Как-то Вы по-линуксовому…верится/не верится, мыж не в свидетелях иеговы, чесн слово. Как же эмпиризЪм? Скачать демку, подивиться возможности настройки днс. Ну или хотя бы описание почитать.

Итого: Большого желания покупать не возникло. :)

Как Вам будет угодно. Вы сказали, что вносите изменения, я поделился живым рецептом. И да, Ваш поцыэнт более всего визжал о кривизне овпн клиентов….