Здравствуйте, okon, Вы писали:
O>А как Go решит проблему ? ведь большое количество одновременных соединений это скорее проблема связанная с операционной системой как мне кажется. O>Например ОС не поддерживает многопоточность, или ограниченое количество сокетов
The theoretical maximum for Windows is approximately 25,000 socket handles
)
Ну я, честно говоря, надеюсь на здравый смысл что само по себе не предполагает использование Windows в качестве хоста для сервиса
Здравствуйте, Ватакуси, Вы писали:
В>100 тыщ одновременных запросов к веб серверу Вот именно так клиент хочет.
Классические грабли "у нас есть придуманное мной решение, а теперь вы сношайтесь с языками/платформами, чтобы оно работало". Кстати, на RSDN'е таких клоунов тоже полно — приходят со своим (не самым удачным) решением проблемы, а потом, когда уже клещами вытянут саму проблему, оказывается, что она гроша выеденного не стоит. И не смешно вам пыхтеть над этим??
В> Зачем, почему без понятия ибо это конкурс и свои хотелки они не объясняют.
ТЕМ БОЛЕЕ в сад. Писать второй фэйсбук — никому нафиг не надо. Кто хочет решений — тот предлагает проблему, а не набор бессмысленной чуши "хочу стотыщмильёнов запросов". Да, просто к слову: у "больших дядь" подобные решения могут стоить миллионы, поэтому нищебродам с конкурсами туда вход не заказан. Заметь — это люди с готовым решением. Почему бы этим "устроителям конкурса" не расщедриться на отработанное решение?
В> Система типа MIS
что MIS? Это кому-то должно что-то говорить?
В> Железо (в облаке) подразумевается хорошее
Облака тут вообще не причём. Проблема больших пулов сугубо сетевая.
В>Теперь вот размышляю, есть ли в природе решения, которые справятся с такой нагрузкой и на таком железе?
Забесплатно? Пусть поищут клоунов в зеркале.
Re[5]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, okon, Вы писали:
O>Вероятно тут проблемы начнуться раньше из-за необходимости записи в базу или логирование, т.е. физические возможности железа принять такой поток информации.
100K одновременных соединений не означает наличие даже 1К запросов в секунду. Насколько я понимаю, речь идет про Management Information System (MIS), так что, подавляющее количество времени сервер будет просто ждать на открытом соединении, может пинги слать.
O>Немного другую вещь хотел выяснить, что мне даст Go, по сравнению с тем же C, C++ например. O>Производительность или быстрее написать
Он тебе даст: а) писать в раз так 3-5 быстрее чем на C++, б) зеленые потоки из коробки, и) заточенность под разработку сервисов (куча около-web компонент высокого класса). Я вот тут собирал в кучу свои мысли на этот счет.
Здравствуйте, Hardballer, Вы писали:
scf>>А на чем вы пишете вообще? Нужен язык с приличным быстродействием и поддержкой NIO, так что питон не предлагать. Помимо java/go/C++, node.js, возможно, потянет.
H>C#/.NET Core
Рискуешь оказаться первым человеком на планете, обрабатывающим 100 тыс коннекшнов на .net core)
Здравствуйте, Ватакуси, Вы писали:
В>>>И сколько это счастье стоит в год? C>>Где-то от $1 в час: https://www.ec2instances.info/?min_memory=32 В>9 штук в год + инет + диск + ещё что-нить. Дорого, очень.
9 штук в год — это пара месяцев работы программиста в России или один месяц для США. Так что ещё вопрос что будет выгоднее.
Sapienti sat!
Re[8]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Masterspline, Вы писали:
M> Чет мне кажется, что современная тяга к облакам обусловлена тем, что разработчики с администрированием не просто совсем не дружат, а даже задумываться не хотят (разумеется, есть и случаи, когда облака оправданы, чем бы они ни были).
До определенного количества серверов (порядка 10-20), собственные сервера на старте будут дешевле, но обслуживать их будет дороже и геморнее нежели арендовать. И дело тут не в администрировании (оно будет нужно в любом случае), а в том что железо надо куда-то ставить, закупать комплектующие, своевременно обслуживать и т.д.
Здравствуйте, _ABC_, Вы писали:
_AB>Ничего дешевле я не нашел с 48 ядрами, но я по всем регионам не шастал, конечно.
Вроде же речь шла про память?
Есть очень удобная страничка, где легко искать нужные типы: https://www.ec2instances.info/?min_memory=64
m2.4xlarge — $0.98 в час за 68Гб оперативки, т.е. около $9k в год за чистый on-demand. Или около $5k за RI.
r5.4xlarge — $1.08 в час за 128Гб и 16 CPU.
Специально взял Intel'овские варианты.
C>>Будет новый продукт, который просто позволяет получать более дешёвые инстансы при покупке на длительный срок. _AB>А вот это очень интересно. Какие-нибудь подробности доступны? А то мы уже серьезно подумываем сваливать куда-нибудь.
Пока подробности сказать не могу, но могу сказать, что многое будет существенно дешевле. Ну и спотовые инстансы надо использовать, однако.
Здравствуйте, Ватакуси, Вы писали:
В>Вот именно так клиент хочет. Зачем, почему без понятия ибо это конкурс и свои хотелки они не объясняют. Система типа MIS + свой протокол с не более, чем 5 внешних и сторонних систем. Т.е. веб-сервер, сервер(а), база + сервис(ы) для внешнего общения. Аппаратный VPN. В>UI на вебе для раб. станций, ноутов и мобильников.
В>1) Go. Мы на нём не пишем вообще, хотя конечно можно нанять специалистов, но помочь им будет особо некому, если понадобится.
Вот этим путем и стоит идти, так как для Go 100K соединений вполне себе рабочая ситуация, ничего экстраординарного. В крайнем случае за балансер спрячьте пару серверов, если вдруг криво выйдет. Вам будет достаточного нанять одного опытного тимлида с Go, который легко подтянет на язык ваших людей на чем бы они не писали. Говорю по своему текущему опыту.
Здравствуйте, Ватакуси, Вы писали:
В>1) Go. Мы на нём не пишем вообще, хотя конечно можно нанять специалистов, но помочь им будет особо некому, если понадобится.
Если делать на Go наивно, то 100К гороутин сожрут чуть меньше, чем полгига памяти на свои стеки, что несколько обидно, да и кэш процессора будет выносить без нужды.
Здравствуйте, _ABC_, Вы писали:
_AB>Есть только ма-а-а-аленькая деталь. 9 штук в год — это если ты сразу за 3 года вперед заплатил, т.е. единовременно ты платишь 27К.
Я взял цены при покупке Reserved Instances на год.
Кстати, скоро будет ещё дешевле. Reserved Instances подразумевают реальное резервирование, что не всегда нужно. Будет новый продукт, который просто позволяет получать более дешёвые инстансы при покупке на длительный срок.
Здравствуйте, Sharov, Вы писали:
C>>С M3/M4 ещё была проблема, в том что железо в разных партиях чуть-чуть отличалось, что ломало возможность делать hibernate/resume. S>Почему, какая связь?
Процессоры с немного разными наборами поддерживаемых команд.
В> Теперь вот размышляю, есть ли в природе решения, которые справятся с такой нагрузкой и на таком железе?
Напиши кастомное ядро (по аналогии с seL4) и сетевой стек к нему на ассемблере.
А из железа — есть же 100 корные процессоры. По 250 запросов на кору (при четырёхпроцессорной материнской плате) — не выглядит слишком страшным. Blade-сервера ещё бывают...
Здравствуйте, Masterspline, Вы писали:
M>Корутины в GoLang stackFULL (хранят аргументы вызова, локальные переменные, собственное состояние в stack frame,
И сколько это в среднем?
M> т.е. для каждой корутины выделяется свой стек
И? Чтобы сотня тысяч корутин выжрала хотя бы гиг оперативы, каждая должна откушать по 10Кб. Что то как то дофига, не?
M>Но при любом раскладе в реальном приложении stackless потребляет меньше памяти (и виртуальной и физической) чем stackfull.
Меньше. Но не настолько меньше же, чтобы это стало критичным в сценариях с IO, потому что намного раньше оно упрется в другие ограничения.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[6]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Cyberax, Вы писали:
В>>9 штук в год + инет + диск + ещё что-нить. Дорого, очень. C>9 штук в год — это пара месяцев работы программиста в России или один месяц для США. Так что ещё вопрос что будет выгоднее.
Есть только ма-а-а-аленькая деталь. 9 штук в год — это если ты сразу за 3 года вперед заплатил, т.е. единовременно ты платишь 27К.
А если платить за год вперед, то уже 14 штук в год получается, тоже единовременно.
А если платить on-demand по умолчанию, так все 20 штук уже.
Вот именно так клиент хочет. Зачем, почему без понятия ибо это конкурс и свои хотелки они не объясняют. Система типа MIS + свой протокол с не более, чем 5 внешних и сторонних систем. Т.е. веб-сервер, сервер(а), база + сервис(ы) для внешнего общения. Аппаратный VPN.
UI на вебе для раб. станций, ноутов и мобильников.
Почитал я, поговорил с людьми и повыяснял, что в наше время может шустро работать под такими нагрузками. Железо (в облаке) подразумевается хорошее, но ничего экстравагантного. 32 гига, 8 ядер, ксеоновский проц средний. В теории, можно две таких железяки. Либо больше, если делать своё облако, но этого не очень хотелось.
И получается только 3 варианта, которые мне не нравятся.
1) Go. Мы на нём не пишем вообще, хотя конечно можно нанять специалистов, но помочь им будет особо некому, если понадобится.
2) nginx + gunicor + flask. Скорее всего понадобится более мощное железо или же большее кол-во железа + диспетчер нагрузки.
3) java + соответсвующий зоопарк систем. Скорее всего не покатит на этом железе, кроме того не очень хочется писать обработку данных на яве.
Теперь вот размышляю, есть ли в природе решения, которые справятся с такой нагрузкой и на таком железе?
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Ватакуси, Вы писали:
В>>Вот именно так клиент хочет. Зачем, почему без понятия ибо это конкурс и свои хотелки они не объясняют. Система типа MIS + свой протокол с не более, чем 5 внешних и сторонних систем. Т.е. веб-сервер, сервер(а), база + сервис(ы) для внешнего общения. Аппаратный VPN. В>>UI на вебе для раб. станций, ноутов и мобильников.
В>>1) Go. Мы на нём не пишем вообще, хотя конечно можно нанять специалистов, но помочь им будет особо некому, если понадобится.
KP>Вот этим путем и стоит идти, так как для Go 100K соединений вполне себе рабочая ситуация, ничего экстраординарного.
А как Go решит проблему ? ведь большое количество одновременных соединений это скорее проблема связанная с операционной системой как мне кажется.
Например ОС не поддерживает многопоточность, или ограниченое количество сокетов
The theoretical maximum for Windows is approximately 25,000 socket handles
)
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[4]: 100 тыщ одновременных запросов к веб серверу
KP>Ну я, честно говоря, надеюсь на здравый смысл что само по себе не предполагает использование Windows в качестве хоста для сервиса
Вероятно тут проблемы начнуться раньше из-за необходимости записи в базу или логирование, т.е. физические возможности железа принять такой поток информации.
Например входной и выходной пакет > 10 кб и информация по одному запросу ее результат сохранение в базе в различных таблицах занимает в общей сумме 10 Кб, если 100 000 запросов в секунду то это 1 Gb / sec нужно пропускать.
Это начнуться уже ограничения канала сетевого, скорость записи диска.
К тому клоню что 100 000 запросов для того чтобы система не работала на пределе возможностей, нужно сразу рассматривать балансировщик и распределение нагрузки на несколько серверов.
Например 10 серверов по 10 000 запросов на каждый.
Немного другую вещь хотел выяснить, что мне даст Go, по сравнению с тем же C, C++ например.
Производительность или быстрее написать
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[5]: 100 тыщ одновременных запросов к веб серверу
ход мысли верный
не столько балансировщик (есть несколько кандидатов, кто напрямую сможет переварить столько соединений), сколько заморочки с хранилищем, которое захлебнется
Здравствуйте, Ватакуси, Вы писали:
В>Вот именно так клиент хочет. Зачем, почему без понятия ибо это конкурс и свои хотелки они не объясняют. Система типа MIS + свой протокол с не более, чем 5 внешних и сторонних систем. Т.е. веб-сервер, сервер(а), база + сервис(ы) для внешнего общения. Аппаратный VPN. В>UI на вебе для раб. станций, ноутов и мобильников.
В>Почитал я, поговорил с людьми и повыяснял, что в наше время может шустро работать под такими нагрузками. Железо (в облаке) подразумевается хорошее, но ничего экстравагантного. 32 гига, 8 ядер, ксеоновский проц средний. В теории, можно две таких железяки. Либо больше, если делать своё облако, но этого не очень хотелось. В>И получается только 3 варианта, которые мне не нравятся.
В>1) Go. Мы на нём не пишем вообще, хотя конечно можно нанять специалистов, но помочь им будет особо некому, если понадобится. В>2) nginx + gunicor + flask. Скорее всего понадобится более мощное железо или же большее кол-во железа + диспетчер нагрузки. В>3) java + соответсвующий зоопарк систем. Скорее всего не покатит на этом железе, кроме того не очень хочется писать обработку данных на яве.
В>Теперь вот размышляю, есть ли в природе решения, которые справятся с такой нагрузкой и на таком железе?
А на чем вы пишете вообще? Нужен язык с приличным быстродействием и поддержкой NIO, так что питон не предлагать. Помимо java/go/C++, node.js, возможно, потянет.
Re[2]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, scf, Вы писали:
В>>Теперь вот размышляю, есть ли в природе решения, которые справятся с такой нагрузкой и на таком железе?
scf>А на чем вы пишете вообще? Нужен язык с приличным быстродействием и поддержкой NIO, так что питон не предлагать. Помимо java/go/C++, node.js, возможно, потянет.
100к одновременных запросов на любом языке можно держать, лишь бы асинхронная обработка была, а не поток ОС на запрос. С такими запросами — такой ответ. А так — я бы посоветовал Java. Там точно никуда не упрётесь, всё оптимизировано веками.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, okon, Вы писали:
O>>Вероятно тут проблемы начнуться раньше из-за необходимости записи в базу или логирование, т.е. физические возможности железа принять такой поток информации.
KP>100K одновременных соединений не означает наличие даже 1К запросов в секунду. Насколько я понимаю, речь идет про Management Information System (MIS), так что, подавляющее количество времени сервер будет просто ждать на открытом соединении, может пинги слать.
Если тупо держать коннект и редко писать/принимать данные без отдачи, то можно просто кластер на кролике поднять и забыть.
Re[3]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, okon, Вы писали:
O>Немного другую вещь хотел выяснить, что мне даст Go, по сравнению с тем же C, C++ например. O>Производительность или быстрее написать
Быстрее написать, и не потонуть в отладке.
Разумеется, на C такое тоже можно написать. Но надо очень хорошо понимать, что ты делаешь.
Здравствуйте, Ватакуси, Вы писали:
В>Почитал я, поговорил с людьми и повыяснял, что в наше время может шустро работать под такими нагрузками. Железо (в облаке) подразумевается хорошее, но ничего экстравагантного. 32 гига, 8 ядер, ксеоновский проц средний. В теории, можно две таких железяки. Либо больше, если делать своё облако, но этого не очень хотелось.
Странное какое-то облако. В Амазоне можно взять инстанс с сотнями Гб оперативки и 48 CPU.
Sapienti sat!
Re[3]: 100 тыщ одновременных запросов к веб серверу
O>А как Go решит проблему ? ведь большое количество одновременных соединений это скорее проблема связанная с операционной системой как мне кажется.
Для операционной системы нет большой проблемы держать много соединений. Раньше была проблема 10K, но она уже давно превратилась в 10M. Машина, конечно, понадобиться не слабая, но и не суперкомпьютер, обычный средний сервак.
Сложности возникнут с тем, чтобы эти соединения не отображались на потоки или stackfull корутины (т.е. если использовать GoLang, то не втупую создавая по корутине на соединение), потому что памяти не хватит (по сути мегапопулярный для данной задачи GoLang от C++ мало отличается). В результате нужно организовать конвейер, который при появлении данных в соединении, начнет его обрабатывать и приоритет будет отдаваться самым ранним запросам. Т.е. при появлении данных в очередном соединении, начинать его обрабатывать, когда обработка приостановится (ждем данные из базы или еще откуда-то), брать другой такой же запрос, который был приостановлен, но получил нужные данные (из базы, например). Если запросов, которые уже начали обрабатывать нет — берем очередной запрос и начинаем его обрабатывать с нуля. Получится конвейер из небольшого количества обработчиков (по количеству этапов между ожиданиями данных) и набор объектов, в которых хранится состояние обработки текущего соединения. Очередное соединение начинает обрабатываться только тогда, когда нет уже начавшихся обрабатываться соединений, для которых есть данные (т.о. в текущий момент будет обрабатываться сильно меньше запросов, чем есть соединений). Такая архитектура получится самая шустрая, потому что будет меньше всего использовать память, а значит эффективнее кеш. Ну, а ядер CPU так вообще не сильно больше, чем пальцев у человека, поэтому нет смысла обрабатывать все соединения одновременно (закончили одно — начали другое).
Язык можно брать любой под эту задачу, главное чтобы подходящие прикладные библиотеки уже были и разработчик понимал архитектуру приложения и особенности работы с памятью в своем языке. Если нужна производительность (количество соединений тут ни при чем), нужно брать что-то компилируемое.
Re[5]: 100 тыщ одновременных запросов к веб серверу
O>Вероятно тут проблемы начнуться раньше из-за необходимости записи в базу или логирование, т.е. физические возможности железа принять такой поток информации. O>Например входной и выходной пакет > 10 кб и информация по одному запросу ее результат сохранение в базе в различных таблицах занимает в общей сумме 10 Кб, если 100 000 запросов в секунду то это 1 Gb / sec нужно пропускать. O>Это начнуться уже ограничения канала сетевого, скорость записи диска.
Если не хватит IOPS'ов или пропускной способности сети — то это проблемы железа. Понятно, что нужно будет распределять запросы на несколько машин.
O>Немного другую вещь хотел выяснить, что мне даст Go, по сравнению с тем же C, C++ например.
На GoLang проще найти специалиста для такой задачи.
Re[6]: 100 тыщ одновременных запросов к веб серверу
O>>Немного другую вещь хотел выяснить, что мне даст Go, по сравнению с тем же C, C++ например. O>>Производительность или быстрее написать
KP>Он тебе даст: а) писать в раз так 3-5 быстрее чем на C++, б) зеленые потоки из коробки, и) заточенность под разработку сервисов (куча около-web компонент высокого класса). Я вот тут собирал в кучу свои мысли на этот счет.
Не соглашусь про зеленые потоки. Корутины (Гор-рутины) в С++ сильно меньше жрут память, чем StackFull корутины GoLang (как я писал, если втупую создавать корутину на запрос в GoLang, память закончится). Кроме того корутины в C++ stackLESS, поэтому они пошустрее (меньше регистров сохраняется при переключении, но главное — они гораздо лучше оптимизируются).
С остальным согласен.
Re[2]: 100 тыщ одновременных запросов к веб серверу
VC>Одновременных? Может соединений? Тогда Round-Robin DNS.
С круглым Робином нужно быть готовым к тому, что он не обеспечит равномерную балансировку. Более того, может сделать очень неравномерную балансировку (90% запросов отправить на один IP).
В>Они хотят 100 тысяч concurrent users. И 20% буфер. Just in case...
Я примерно так и думал, что будут 100K веб сокетов от пользователей, через которые отправляется информация "на открытой вами странице добавили комментарий" или "вам сообщение в личку". 100K — это количество соединений (или даже пользователей), а не запросов.
Здравствуйте, Masterspline, Вы писали:
VC>>Одновременных? Может соединений? Тогда Round-Robin DNS.
M>С круглым Робином нужно быть готовым к тому, что он не обеспечит равномерную балансировку. Более того, может сделать очень неравномерную балансировку (90% запросов отправить на один IP).
Неравномерность это херня на булке с малсом. Ни одна железка 100 тыс одновременно не потащит — вот где собака зарыта
Re[4]: 100 тыщ одновременных запросов к веб серверу
VC>>>Одновременных? Может соединений? Тогда Round-Robin DNS.
M>>С круглым Робином нужно быть готовым к тому, что он не обеспечит равномерную балансировку. Более того, может сделать очень неравномерную балансировку (90% запросов отправить на один IP).
VC>Неравномерность это херня на булке с малсом. Ни одна железка 100 тыс одновременно не потащит — вот где собака зарыта
100 тыщ чего? В железке процессорных ядер не больше сотни штук, поэтому одновременно запросов больше количества ядер не обслужить.
Но если 100 тыщ — это количество висящих соединений, по которым бегают данные раз в час, то проц подойдет любой, главное чтобы памяти хватило на хранение состояния каждого соединения.
А если 100 тыщ — это количество пользователей в базе...
Re[2]: 100 тыщ одновременных запросов к веб серверу
В>>Почитал я, поговорил с людьми и повыяснял, что в наше время может шустро работать под такими нагрузками. Железо (в облаке) подразумевается хорошее, но ничего экстравагантного. 32 гига, 8 ядер, ксеоновский проц средний. В теории, можно две таких железяки. Либо больше, если делать своё облако, но этого не очень хотелось. C>Странное какое-то облако. В Амазоне можно взять инстанс с сотнями Гб оперативки и 48 CPU.
И сколько это счастье стоит в год?
Все будет Украина!
Re[5]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Masterspline, Вы писали:
M>Не соглашусь про зеленые потоки. Корутины (Гор-рутины) в С++ сильно меньше жрут память, чем StackFull корутины GoLang
Память или VA space?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[8]: 100 тыщ одновременных запросов к веб серверу
M>>Не соглашусь про зеленые потоки. Корутины (Гор-рутины) в С++ сильно меньше жрут память, чем StackFull корутины GoLang
НС>Память или VA space?
Корутины в GoLang stackFULL (хранят аргументы вызова, локальные переменные, собственное состояние в stack frame, т.е. для каждой корутины выделяется свой стек, по сути такая корутина — это поток без выделения CPU, поэтому у boost fiber даже интерфейс сделан как у std::thread), C++ — stackLESS (данные хранятся в объекте, отдельный стек не выделяется). Поэтому и то и другое. Даже с оптимизациями Go для стека, при создании корутины будет выделен stackframe вряд ли меньше 1K. Но, даже если это будет виртуальная страница памяти 4K, все равно в нее что-то запишут и она превратиться в физическую. Также понятно, что неиспользуемые страницы окажутся в swap. Но при любом раскладе в реальном приложении stackless потребляет меньше памяти (и виртуальной и физической) чем stackfull.
Re[7]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Masterspline, Вы писали:
M>Не соглашусь про зеленые потоки. Корутины (Гор-рутины) в С++ сильно меньше жрут память, чем StackFull корутины GoLang (как я писал, если втупую создавать корутину на запрос в GoLang, память закончится). Кроме того корутины в C++ stackLESS, поэтому они пошустрее (меньше регистров сохраняется при переключении, но главное — они гораздо лучше оптимизируются).
Очень зря не согласишься. Стартовый размер стека одной горутины 2Кб, что дает 0.2 Gb что вообще ни о чем. Даже с данными сверху там 1 Gb с трудом набертся на поддержку самих горутин.
Re[8]: 100 тыщ одновременных запросов к веб серверу
M>>Не соглашусь про зеленые потоки. Корутины (Гор-рутины) в С++ сильно меньше жрут память, чем StackFull корутины GoLang (как я писал, если втупую создавать корутину на запрос в GoLang, память закончится). Кроме того корутины в C++ stackLESS, поэтому они пошустрее (меньше регистров сохраняется при переключении, но главное — они гораздо лучше оптимизируются).
KP>Очень зря не согласишься. Стартовый размер стека одной горутины 2Кб, что дает 0.2 Gb что вообще ни о чем. Даже с данными сверху там 1 Gb с трудом набертся на поддержку самих горутин.
Ты же не станешь спорить, что stackless корутины в C++ потребляют меньше памяти в такой задаче, чем stackfull в GoLang? При этом я соглашусь, что для задачи держать 100К соединений памяти достаточно даже если создавать по корутине Go на соединение. А если ресурсов хватает, то решение можно не усложнять.
Однако, stackless корутины потребуют раз в 10 меньше памяти, а потому смогут держать раз в 10 больше соединений. Впрочем, если в GoLang не создавать по корутине на соединение, а сделать более хитрую архитектуру, то и там можно их сильно больше держать.
Re[3]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Ватакуси, Вы писали:
C>>Странное какое-то облако. В Амазоне можно взять инстанс с сотнями Гб оперативки и 48 CPU. В>И сколько это счастье стоит в год?
Где-то от $1 в час: https://www.ec2instances.info/?min_memory=32
Sapienti sat!
Re[10]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И? Чтобы сотня тысяч корутин выжрала хотя бы гиг оперативы, каждая должна откушать по 10Кб. Что то как то дофига, не?
Это для дотнета дофига, где объекты на стеке обычно не располагаются.
А там где активно располагаются — это ни о чём.
НС>Меньше. Но не настолько меньше же
На пару порядков в среднем по палате из-за необходимости под новый стек резервировать заранее неизвестное кол-во памяти.
Поэтому, куча лишних телодвижений.
В Линухах по-умолчанию резервируют 8 мег под стек, но коммит физ.памяти происходит по мере надобности какими-то довольно большими страницами.
Re[2]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Cyberax, Вы писали:
C>Странное какое-то облако. В Амазоне можно взять инстанс с сотнями Гб оперативки и 48 CPU.
И стоить это будет во сколько раз больше озвученной конфигурации?
Re[11]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, vdimas, Вы писали:
V>На пару порядков в среднем по палате из-за необходимости под новый стек резервировать заранее неизвестное кол-во памяти.
Заранее резервируется не память, а VA space.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[12]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>На пару порядков в среднем по палате из-за необходимости под новый стек резервировать заранее неизвестное кол-во памяти. НС>Заранее резервируется не память, а VA space.
А что еще могло называться "резервированием" и "коммитом" тут?
В Линухах по-умолчанию резервируют 8 мег под стек, но коммит физ.памяти происходит по мере надобности какими-то довольно большими страницами.
Вторая часть этого предложения ключевая.
Как и тот факт, что стек — он локален, т.е. после пика нагрузки на стековую память та не возвращается в некий общий пул.
В этом плане подход дотнетных Task эффективнее, с оговоркой на GC-операции на каждый чих.
Сейчас ввели ValueTask, что дало инструмент для "окончательного решения вопроса".
(Еще бы сеть в дотнете до ума довели, а то стыдуха сплошная...)
C>>>Странное какое-то облако. В Амазоне можно взять инстанс с сотнями Гб оперативки и 48 CPU. В>>И сколько это счастье стоит в год? C>Где-то от $1 в час: https://www.ec2instances.info/?min_memory=32
9 штук в год + инет + диск + ещё что-нить. Дорого, очень.
Все будет Украина!
Re[7]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, smeeld, Вы писали:
s> M>На GoLang проще найти специалиста для такой задачи. s> Это миф, который повторяют все как попугаи. На самом деле, сложнее, чем такого же, который cваяет на плюсах.
Здравствуйте, Cyberax, Вы писали:
C>9 штук в год — это пара месяцев работы программиста в России или один месяц для США. Так что ещё вопрос что будет выгоднее.
Это с одной стороны. А с другой — есть вот у меня один сервис. Некоторые крупные (из S&P 500) конторы хотят собственную инсталляцию. Однако когда узнают, что на весь сервис (весь, а не один сервер) нужно тратить 5-6К в год — начинают воротить рожу.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Cyberax, Вы писали:
_AB>>Есть только ма-а-а-аленькая деталь. 9 штук в год — это если ты сразу за 3 года вперед заплатил, т.е. единовременно ты платишь 27К. C>Я взял цены при покупке Reserved Instances на год.
N.Virginia — 10.738K 1 year Standard RI All Upfront за амдшный варинат md5a.12xlarge. Возможно, у меня предубеждение ретрограда, но я свои сервисы на АМД машинах не стал бы разворачивать. Ничего не имею против десктопов на их базе, но по сервакам как-то недоверие имеется. Возможно, повторюсь-таки, абсолютно безосновательное.
Ничего дешевле я не нашел с 48 ядрами, но я по всем регионам не шастал, конечно.
C>Кстати, скоро будет ещё дешевле. Reserved Instances подразумевают реальное резервирование, что не всегда нужно.
Это очень мягко говоря — "не всегда".
C>Будет новый продукт, который просто позволяет получать более дешёвые инстансы при покупке на длительный срок.
А вот это очень интересно. Какие-нибудь подробности доступны? А то мы уже серьезно подумываем сваливать куда-нибудь.
Re[7]: 100 тыщ одновременных запросов к веб серверу
В>>>9 штук в год + инет + диск + ещё что-нить. Дорого, очень. C>>9 штук в год — это пара месяцев работы программиста в России или один месяц для США. Так что ещё вопрос что будет выгоднее. _AB>Есть только ма-а-а-аленькая деталь. 9 штук в год — это если ты сразу за 3 года вперед заплатил, т.е. единовременно ты платишь 27К. _AB>А если платить за год вперед, то уже 14 штук в год получается, тоже единовременно. _AB>А если платить on-demand по умолчанию, так все 20 штук уже.
Кстати, сколько будет стоит аналогичный физический сервер? В смысле купить такую машину без хостинга. Размером, например, 2U, чтобы можно было дисками заполнить по уши. Без брендовой наценки, какой-нибудь Хуавей или Супермикро, в общем, такого уровня...
Чет мне кажется, что современная тяга к облакам обусловлена тем, что разработчики с администрированием не просто совсем не дружат, а даже задумываться не хотят (разумеется, есть и случаи, когда облака оправданы, чем бы они ни были).
Re[2]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Pzz, Вы писали:
Pzz>Вот тут ребята описывают, как сделать не наивно.
Ребята заморочились с велосипедом, чтоб не жрало 74G на соединения. Но для сервера, 74 это немного — 128 и 256G можно воткнуть. И ещё пойнт, в чём смысл плясок вокруг горутин, если они опустились до epoll? С этим можно и на C++, и на Java свободно написать, да хоть на Python (без горутин).
Re[3]: 100 тыщ одновременных запросов к веб серверу
Pzz>>Вот тут ребята описывают, как сделать не наивно.
%>Ребята заморочились с велосипедом, чтоб не жрало 74G на соединения. Но для сервера, 74 это немного — 128 и 256G можно воткнуть. И ещё пойнт, в чём смысл плясок вокруг горутин, если они опустились до epoll? С этим можно и на C++, и на Java свободно написать, да хоть на Python (без горутин).
Когда смотришь на цену памяти в магазине компьютерных комплектующих или на aliexpress — видишь одно, когда на прайс где-нибудь на амазоне (хостинге) — совсем другое. Сразу появляется мотивация оптимизировать ее потребление приложением.
Re[10]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Cyberax, Вы писали:
C>m2.4xlarge — $0.98 в час за 68Гб оперативки, т.е. около $9k в год за чистый on-demand.
Сейчас пятое поколение. Емнип, м4 уже недоступны, а ты м2 предлагаешь? Я что-то путаю?
C>r5.4xlarge — $1.08 в час за 128Гб и 16 CPU.
Используем сейчас.
C>Пока подробности сказать не могу, но могу сказать, что многое будет существенно дешевле. Ну и спотовые инстансы надо использовать, однако.
Когда можно ожидать новости?
А они применимы, если нам нужен аптайм в строго определенное время? Частью в рабочее время, частью круглосуточно.
Re[11]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, _ABC_, Вы писали:
C>>m2.4xlarge — $0.98 в час за 68Гб оперативки, т.е. около $9k в год за чистый on-demand. _AB>Сейчас пятое поколение. Емнип, м4 уже недоступны, а ты м2 предлагаешь? Я что-то путаю?
Ну так работает, можно не трогать. Доступность, в основном, зависит от того, сколько железа купили.
С M3/M4 ещё была проблема, в том что железо в разных партиях чуть-чуть отличалось, что ломало возможность делать hibernate/resume. Потому их достаточно быстро вывели из эксплуатации.
А вот удачные M2 до сих пор живут. Сама по себе цифра поколения не особо важна.
C>>Пока подробности сказать не могу, но могу сказать, что многое будет существенно дешевле. Ну и спотовые инстансы надо использовать, однако. _AB>Когда можно ожидать новости?
Скорее всего, re:Invent. Так как проект влезает в систему биллинга, а там всё движется крайне медленно.
_AB>А они применимы, если нам нужен аптайм в строго определенное время? Частью в рабочее время, частью круглосуточно.
Так это можно scheduled instances уже прямо сейчас использовать. Там прямо расписание настраивать можно.
Sapienti sat!
Re[3]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, %, Вы писали:
Pzz>>Вот тут ребята описывают, как сделать не наивно.
%>Ребята заморочились с велосипедом, чтоб не жрало 74G на соединения. Но для сервера, 74 это немного — 128 и 256G можно воткнуть.
Память — штука медленная. Причем очень медленная, по сравнению с процессором. Соответственно, если программе ее нужно много, программа будет тормозить.
%>И ещё пойнт, в чём смысл плясок вокруг горутин, если они опустились до epoll? С этим можно и на C++, и на Java свободно написать,
Можно. Но на Go удобнее. Их низкоуровневый кусочек, на самом деле, очень небольшой.
%>да хоть на Python (без горутин).
На питоне будет слишком медленно.
Re[12]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, Cyberax, Вы писали:
C>Ну так работает, можно не трогать. Доступность, в основном, зависит от того, сколько железа купили.
Но купить-то сейчас нельзя?
C>А вот удачные M2 до сих пор живут. Сама по себе цифра поколения не особо важна.
Важна возможность их купить.
C>Скорее всего, re:Invent. Так как проект влезает в систему биллинга, а там всё движется крайне медленно.
Ну почему "всё"? Счета в этом биллинге растут дай боже...
Как и время ожидания ответа на тикет, кстати.
C>Так это можно scheduled instances уже прямо сейчас использовать. Там прямо расписание настраивать можно.
Делаем, разумеется.
Но всё равно дороговато выходит...
Основная проблема даже не в дороговизне как таковой, а в том, что цены в регионах у вас всё равно в USD. Мы в Австралии заключаем с клиентами договора в AUD, размещаем ресурсы в австралийской же зоне, а счета от Амазона получаем в USD. Курс же, мягко говоря, своим трендом не радует.
Здравствуйте, Cyberax, Вы писали:
C>С M3/M4 ещё была проблема, в том что железо в разных партиях чуть-чуть отличалось, что ломало возможность делать hibernate/resume.
Почему, какая связь?
Кодом людям нужно помогать!
Re[13]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, _ABC_, Вы писали:
C>>Ну так работает, можно не трогать. Доступность, в основном, зависит от того, сколько железа купили. _AB>Но купить-то сейчас нельзя?
Да, сейчас просто будет невыгодно.
C>>А вот удачные M2 до сих пор живут. Сама по себе цифра поколения не особо важна. _AB>Важна возможность их купить.
Ближайшие пару лет — будет.
C>>Скорее всего, re:Invent. Так как проект влезает в систему биллинга, а там всё движется крайне медленно. _AB>Ну почему "всё"? Счета в этом биллинге растут дай боже...
Это ты не знаешь как оно внутри работает
_AB>Основная проблема даже не в дороговизне как таковой, а в том, что цены в регионах у вас всё равно в USD. Мы в Австралии заключаем с клиентами договора в AUD, размещаем ресурсы в австралийской же зоне, а счета от Амазона получаем в USD. Курс же, мягко говоря, своим трендом не радует.
Тут проблема в том, что основные расходы у Амазона — в USD. Так что даже при расчётах в AUD просто тупо будут брать по курсу.
Единственный регион, где используются местные валюты — это Китай. Но там даже цены непубличные, с каждым клиентом договариваются.
Sapienti sat!
Re[3]: 100 тыщ одновременных запросов к веб серверу
И не смешно вам пыхтеть над этим??
