Здравствуйте, vdimas, Вы писали:
V>В общем, даже в доках MS речь идет о "диспетчере трафика Azure" или, например, узел, выполняющий "корневую" роль NLB в кластере так и называют — диспетчером.
What is Traffic Manager?
Azure Traffic Manager is a DNS-based traffic load balancer
Azure Traffic Manager это просто название конкретного продукта, чтобы отличить его от других LB в ажуре.
Здравствуйте, vdimas, Вы писали:
_>>>А вот у Яндекса ситуация с нагрузкой совсем другая и им очевидно очень полезно оптимизировать свой серверный софт, что они и делают (ведя разработку на современном C++). lpd>>А насколько по-твоему ты сможешь оптимизировать бэкенд на современном C++ по сравнению с классическим? Я думаю не более чем 10-15% _результирующей_ скорости. V>На деле в 10-20 раз. V>Вот такой фокус.
Не, ты его не правильно понял. ))) Он под классикой имел в виду не Java или .Net, а классический C++ (ну типа C++03). И соответственно говорил о приросте в производительности от современных возможностей (типа семантики перемещения, статического if'а и всякой там шаблонной магии). В этом смысле его цифры выглядят достаточно адекватно.
Его неадекватность заключается совсем в другом. Он почему-то считает, что эти возможности ввели как раз ради ускорения, а платим мы за них более трудным написанием кода. В то время как в реальности всё было с точность до наоборот: все эти новейшие возможности вводили для упрощения написания кода, а небольшое ускорение в некоторых случаях возникло просто как приятный побочный эффект. )))
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, vdimas, Вы писали:
V>>В общем, даже в доках MS речь идет о "диспетчере трафика Azure" или, например, узел, выполняющий "корневую" роль NLB в кластере так и называют — диспетчером.
НС>Azure Traffic Manager это просто название конкретного продукта, чтобы отличить его от других LB в ажуре.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>И? Это как-то влияет на нагрузку сервера приложений? ) НС>Влияет. Есть некий минимум, ниже которого мощность кластера быть не может. И этот минимум при соответствующей нагрузке вполне может быть избыточен. НС>Либо стоимость кластера, обращающегося к БД, может быть 1-2% от стоимости вычислительного кластера или БД, и на экономию затрат в размере 0.1% от общей суммы всем плевать.
И какое отношение все эти экономические расклады (кстати говоря верные только для некоторых типов проектов, ну да ладно, не суть) имеют к обсуждаемому нами вполне техническому вопросу? Или может ты хочешь сказать, что это твоё "упирается в СУБД" как раз и было изначально в экономическом смысле? )))
_>>Если у тебя вся нагрузка на приложения умещается в один сервер НС>Сама эта фраза говорит о том, что ты в облаках не особо в теме. Там почти никогда не бывает одного сервера, и дело вовсе не в нагрузке на CPU.
Эта фраза говорит о том, что я давно на этом форуме и в курсе, что у нас тут водятся толпы троллей и демагогов. Так что высказывая какое-то утверждение, я всегда оговариваю крайние условия, в которых это утверждение не работает. Потому как иначе тут же прибегут, размахивая этим крайним случаем, чтобы опровергнуть всё утверждение.
_>>Вообще говоря зависит, т.к. очень разные модели хранения объектов в C++ и скажем Java. НС>Это все мелочи.
Ну да, всего то в среднем в 2 раза больший расход памяти. Ну да, действительно, какие незначительные мелочи...
_>>И? Какая разница, что один компонент системы дороже дороже другого? НС>Такая, что экономия в 0.1% никого не колышет.
Не стоит мерить по своим проектам, всех вокруг. ) Не у всех так мало серверов и приложения заняты только перекладыванием данных из БД в ответ пользователю. )))
Здравствуйте, alex_public, Вы писали:
_>Его неадекватность заключается совсем в другом. Он почему-то считает, что эти возможности ввели как раз ради ускорения, а платим мы за них более трудным написанием кода. В то время как в реальности всё было с точность до наоборот: все эти новейшие возможности вводили для упрощения написания кода, а небольшое ускорение в некоторых случаях возникло просто как приятный побочный эффект. )))
Ну тут уже soteam5 писал, что мув семантика не для ускорения нужна. Но вот ты и многие другие весьма часто делают акцент именно на ускорение, в том числе в этой подветке только 3-4 сообщения назад. Если же вам С++17 проще, чем С++98, то это конечно ваше дело. Но реально мув семантика программисту нужна как повару фехтование. Основные проблемы в программировании — алгоритмические, и далеко не всегда решаются синтаксисом языка, сколько бы вы его не усложняли.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>В общем, даже в доках MS речь идет о "диспетчере трафика Azure" или, например, узел, выполняющий "корневую" роль NLB в кластере так и называют — диспетчером. НС> НС>What is Traffic Manager?
Именно так.
См. ту же самую статью на русском.
НС>Azure Traffic Manager это просто название конкретного продукта, чтобы отличить его от других LB в ажуре.
ECR>Как оно, если не секрет? Хорошо кормили или как обычно в чипостроении?
Меня хорошо. Потому что нанимающий менеджер знал меня и нанимал работать на себя. Он был в Саннивейл, а я в Сиднее, в результате у него была возможность платить практически то, что они платят в долине. А это больше чем в Сиднее. Ну и я хорошо поторговался из-за того, что у меня был хороший каунтер-оффер от на той момент текущей компании.
А вообще много денег в этой области нет. Средненько.
Скажем так, гугл и контракты в банке в Сиднее платят ощутимо больше.
Но есть куча мест, где еще хуже чем заниматься чипами.
Потом, и тогда в Броадкоме и сейчас в текущей компании, если смотреть на долину — люди стараются и периодически исчезают то в фейсбуке, то в аппл.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Да, проблема в потенциальном падении проги сервера, однако джавовские серваки обычно не обеспечивают живое дублирование сессии на другом узле. НС>Чего это вдруг не обеспечивают?
Не джавовская это фишка.
Там это, скорее, редкость.
НС>Я уж не говорю о том, что в большинстве случаев никакой сессии на серверах нет.
Это я упомянул.
V>>Аналогично происходит с перезапуском нейтивного сервера — с теми же эффектами и примерно теми же таймингами. НС>Ты, как и Алекс, вообще не понимаешь о чем говоришь.
Походу, ровно наоборот.
Ты тянешь сценарии из одного мира в другой, о котором даже не наслышан.
НС>Ну какие, нафик, перезапуски, если там даже без перезапусков машин много?
Зачем перезапускать машину, если можно запустить сервак на другой, уже запущенной?
Это же нейтив, он легковесный.
Одна железка может тянуть несколько разных (несвязанных) серваков.
НС>И очередной реквест может попасть на любую из них (sticky sessions это изврат, который даже не всеми LB поддерживается).
Если в наличии всё-таки есть диспетчер LB, то тот прекрасно в курсе, какие узлы работоспособные, а какие нет.
НС>>>В реальности от единиц до десятков минут. V>>Тем более. V>>А на что тратится это время, почему бы вслух не озвучить? )) НС>В основном на развертывание собственно ОС и прикладных решений
При высоких требованиях к доступности в наличии всегда есть уже готовое железо с нужной копией окружения.
Попробуй еще раз.
НС>>>>>или геораспределенность. V>>>>При геораспределенности можно смело говорить о независимой работе серверов приложений НС>>>Нельзя. V>>Можно, бо если используется еще +1 диспетчер на входе НС>Нельзя. И далеко не всегда там вообще LB на геолокацию есть, схемы бывают и посложнее.
Рассуждая таким образом ты делаешь неправыми нас обоих. ))
Бессмыслица на выходе...
V>>(типа как google.com перекидывает на google.ru) НС>Это не для геораспределенности. Датацентров у гугла сильно меньше, чем локальных сайтов.
Уже лет 5 назад гугл начать переносить российские данные на нашу территорию.
Еще не закончил разве? ))
Если бы он этого не стал делать, его бы забанил роскомнадзор.
V>>Описанный сценарий более-менее устоявшийся при масштабировании джавовских серверов. НС>Нет. Сейчас более менее устоявшийся это кубер+докер, и неважно на чем под реализован, на жабке или на С++.
А тут уже ты не прав в одиночестве.
Бо докер — это лишь ср-во разворачивания в таких сценариях, т.е. не противоречит ничему сказанному мною.
В линухах докер — это просто окружение, дальнейшее развитие идеи chroot.
Здравствуйте, alex_public, Вы писали:
_>И какое отношение все эти экономические расклады
Ты первым начал про экономику.
_>>>Вообще говоря зависит, т.к. очень разные модели хранения объектов в C++ и скажем Java. НС>>Это все мелочи. _>Ну да, всего то в среднем в 2 раза больший расход памяти.
Да чего там, в 50 раз.
_>>>И? Какая разница, что один компонент системы дороже дороже другого? НС>>Такая, что экономия в 0.1% никого не колышет. _>Не стоит мерить по своим проектам, всех вокруг. )
Да, стоит мерять по мифическим проектам, у которых в облаке один сервер.
_> Не у всех так мало серверов и приложения заняты только перекладыванием данных из БД в ответ пользователю. )))
Сервера, не занятые общением с БД в контексте топика нерелевантны.
Здравствуйте, vdimas, Вы писали:
V>Уже лет 5 назад гугл начать переносить российские данные на нашу территорию. V>Еще не закончил разве? )) V>Если бы он этого не стал делать, его бы забанил роскомнадзор.
Мне ужасно любопытно, роскомнадзор может как-то проверить этот факт, или им достаточно официального письма "дорогой роскомнадзор, спешу сообщить, что мы перенесли данные российских пользователей на твою территорию, целую в щёчку, гугль"?
Просто если им достаточно официального письма, то из того факта, что их не забанили, нельзя сделать выводы об их технологиях,
Здравствуйте, Basil2, Вы писали:
B>Если кратко, то все. Но некоторые языки требуются вкупе с дополнительными знаниями. Если вы например хорошо строите мат. алгоритмы и знаете Rust, то вакансий море на огромные деньги (точнее, самих-то вакансий численно не много, но конкуренции там нет и вас с руками оторвут). То же самое с веб-сервисами и Go, графикой и С++; и т.д.
B>То есть если у вас есть доп. знания, выгодно _под них_ изучить язык, ибо такие сочетания ценятся.
Хорошо, а тогда какие дополнительные знания нужны для следующих языков программирования:
1) Java;
2) C#;
3) Python.
Здравствуйте, lpd, Вы писали:
lpd>Но реально мув семантика программисту нужна как повару фехтование.
Отучаемся говорить за всех (c)
lpd>Основные проблемы в программировании — алгоритмические, и далеко не всегда решаются синтаксисом языка, сколько бы вы его не усложняли.
Как раз move-семантика добавляет в язык средство для прямого выражения такого понятия, как "хэндл", т.е. объект, который единолично владеет каким-то ресурсом и который нельзя копировать, но можно перемещать владение этим ресурсом от одного хэндла к другому. Например, std::ofstream или std::unique_ptr являются такими хэндлами.
Соответственно, если в вашей предметной области выделяются подобные "хэндлы", то в C++11/14/17 вы можете выражать это явным образом. А не лепить костыли, как в C++98. Скажем, std::vector<std::unique_ptr<T>> -- это прямое следствие поддержки move-семантики в языке.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нафига тогда вообще облако, если все на одной машине?
Можно и так, можно и этак, зависит от задачи, ресурсов, ограничений.
В облаке в среднем проще и быстрее деплоить, не нужно знать как настраивать условную линуху
В общем БД совсем не обязательно будет узким местом.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И? Я же не говорил ни про кого из собеседников, верно? А говорить про третьих лиц — так это тогда то же самое надо применять к Путину, Трампу, Навальному и т.п?
Если тебе с профессиональной точки зрения нечего сказать, то можешь и так, но это не особо интересно и репутицию хорошую ты себе этим не заработаешь
НС>Но это все неважно. Потому что я не о каком то его физическом недостатке написал, не о его цвете кожи или разрезе глаз, что мерзко.
Ты назвал человека "хипста-фриком", не знаю, что ты вкладываешь в эти слова, но на комплимент не они похожи.
НС>Я написал о его сознательном выборе, отражающем его стиль мышления
Попробуй привести хоть сколько-нибудь рациональную критику, а не лить пустую воду и не клеить ярлыки.
НС>ты позволяешь себе прямо оскорблять собеседника.
Ты считаешь прямым оскорблением, что тебе указали, что ты вместо высказывания профессиональной критики оскорбляешь человека?
Здравствуйте, alex_public, Вы писали:
_>Не, ты его не правильно понял. ))) Он под классикой имел в виду не Java или .Net, а классический C++ (ну типа C++03). И соответственно говорил о приросте в производительности от современных возможностей (типа семантики перемещения, статического if'а и всякой там шаблонной магии). В этом смысле его цифры выглядят достаточно адекватно.
Там будет уменьшение кодовой базы в N-раз, в плане производительности выигрышь будет только елси "классическую" версию писали криворуки, но мы же не это рассматриваем.
_>Его неадекватность заключается совсем в другом. Он почему-то считает, что эти возможности ввели как раз ради ускорения, а платим мы за них более трудным написанием кода. В то время как в реальности всё было с точность до наоборот: все эти новейшие возможности вводили для упрощения написания кода, а небольшое ускорение в некоторых случаях возникло просто как приятный побочный эффект. )))
+1
Здравствуйте, lpd, Вы писали:
_>>Его неадекватность заключается совсем в другом. Он почему-то считает, что эти возможности ввели как раз ради ускорения, а платим мы за них более трудным написанием кода. В то время как в реальности всё было с точность до наоборот: все эти новейшие возможности вводили для упрощения написания кода, а небольшое ускорение в некоторых случаях возникло просто как приятный побочный эффект. ))) lpd>Ну тут уже soteam5 писал, что мув семантика не для ускорения нужна. Но вот ты и многие другие весьма часто делают акцент именно на ускорение, в том числе в этой подветке только 3-4 сообщения назад. Если же вам С++17 проще, чем С++98, то это конечно ваше дело. Но реально мув семантика программисту нужна как повару фехтование. Основные проблемы в программировании — алгоритмические, и далеко не всегда решаются синтаксисом языка, сколько бы вы его не усложняли.
Я уже писал об этом, прямо в этой темке (не помню тебе или ещё кому-то). Без семантики перемещения ты в принципе не сможешь написать unique_ptr. А без unique_ptr современный C++ превращается грубо говоря из безопасного Rust'а в опасный "C с классами". И речь не только про управления памятью, а про любые уникальные ресурсы (мьютексы, потоки и т.д.).
А ускорение — это да, местами возникает. Но совсем не это является причиной желания использовать современный C++. А как раз гораздо большее удобство написания кода и безопасность (в смысле контроля компилятора за ошибками).
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>И какое отношение все эти экономические расклады НС>Ты первым начал про экономику.
Я совсем не против поговорить про все стороны проблемы. Но только чтобы было понятно о чём речь в конкретном сообщение. А то, когда ты писал что может упираться в CPU, пямять или БД, естественно казалось, что речь о каких-то технических вопросах. А в итоге выяснилось, что под "упирается в БД" ты тут неожиданно имел в виду, всего лишь что на некоторых проектах цена серверов БД может быть в десятки раз больше цены серверов приложений.
_>>>>Вообще говоря зависит, т.к. очень разные модели хранения объектов в C++ и скажем Java. НС>>>Это все мелочи. _>>Ну да, всего то в среднем в 2 раза больший расход памяти. НС>Да чего там, в 50 раз.
Если нечего сказать, то можно же просто промолчать. Зачем писать что-то просто так? )
