Вот именно так клиент хочет. Зачем, почему без понятия ибо это конкурс и свои хотелки они не объясняют. Система типа MIS + свой протокол с не более, чем 5 внешних и сторонних систем. Т.е. веб-сервер, сервер(а), база + сервис(ы) для внешнего общения. Аппаратный VPN.
UI на вебе для раб. станций, ноутов и мобильников.
Почитал я, поговорил с людьми и повыяснял, что в наше время может шустро работать под такими нагрузками. Железо (в облаке) подразумевается хорошее, но ничего экстравагантного. 32 гига, 8 ядер, ксеоновский проц средний. В теории, можно две таких железяки. Либо больше, если делать своё облако, но этого не очень хотелось.
И получается только 3 варианта, которые мне не нравятся.
1) Go. Мы на нём не пишем вообще, хотя конечно можно нанять специалистов, но помочь им будет особо некому, если понадобится.
2) nginx + gunicor + flask. Скорее всего понадобится более мощное железо или же большее кол-во железа + диспетчер нагрузки.
3) java + соответсвующий зоопарк систем. Скорее всего не покатит на этом железе, кроме того не очень хочется писать обработку данных на яве.
Теперь вот размышляю, есть ли в природе решения, которые справятся с такой нагрузкой и на таком железе?
Здравствуйте, Ватакуси, Вы писали:
В>100 тыщ одновременных запросов к веб серверу Вот именно так клиент хочет.
Классические грабли "у нас есть придуманное мной решение, а теперь вы сношайтесь с языками/платформами, чтобы оно работало". Кстати, на RSDN'е таких клоунов тоже полно — приходят со своим (не самым удачным) решением проблемы, а потом, когда уже клещами вытянут саму проблему, оказывается, что она гроша выеденного не стоит. И не смешно вам пыхтеть над этим??
В> Зачем, почему без понятия ибо это конкурс и свои хотелки они не объясняют.
ТЕМ БОЛЕЕ в сад. Писать второй фэйсбук — никому нафиг не надо. Кто хочет решений — тот предлагает проблему, а не набор бессмысленной чуши "хочу стотыщмильёнов запросов". Да, просто к слову: у "больших дядь" подобные решения могут стоить миллионы, поэтому нищебродам с конкурсами туда вход не заказан. Заметь — это люди с готовым решением. Почему бы этим "устроителям конкурса" не расщедриться на отработанное решение?
В> Система типа MIS
что MIS? Это кому-то должно что-то говорить?
В> Железо (в облаке) подразумевается хорошее
Облака тут вообще не причём. Проблема больших пулов сугубо сетевая.
В>Теперь вот размышляю, есть ли в природе решения, которые справятся с такой нагрузкой и на таком железе?
Здравствуйте, Ватакуси, Вы писали:
В>Вот именно так клиент хочет. Зачем, почему без понятия ибо это конкурс и свои хотелки они не объясняют. Система типа MIS + свой протокол с не более, чем 5 внешних и сторонних систем. Т.е. веб-сервер, сервер(а), база + сервис(ы) для внешнего общения. Аппаратный VPN. В>UI на вебе для раб. станций, ноутов и мобильников.
В>1) Go. Мы на нём не пишем вообще, хотя конечно можно нанять специалистов, но помочь им будет особо некому, если понадобится.
Вот этим путем и стоит идти, так как для Go 100K соединений вполне себе рабочая ситуация, ничего экстраординарного. В крайнем случае за балансер спрячьте пару серверов, если вдруг криво выйдет. Вам будет достаточного нанять одного опытного тимлида с Go, который легко подтянет на язык ваших людей на чем бы они не писали. Говорю по своему текущему опыту.
Здравствуйте, 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[3]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, okon, Вы писали:
O>А как Go решит проблему ? ведь большое количество одновременных соединений это скорее проблема связанная с операционной системой как мне кажется. O>Например ОС не поддерживает многопоточность, или ограниченое количество сокетов
The theoretical maximum for Windows is approximately 25,000 socket handles
)
Ну я, честно говоря, надеюсь на здравый смысл что само по себе не предполагает использование Windows в качестве хоста для сервиса
KP>Ну я, честно говоря, надеюсь на здравый смысл что само по себе не предполагает использование Windows в качестве хоста для сервиса
Вероятно тут проблемы начнуться раньше из-за необходимости записи в базу или логирование, т.е. физические возможности железа принять такой поток информации.
Например входной и выходной пакет > 10 кб и информация по одному запросу ее результат сохранение в базе в различных таблицах занимает в общей сумме 10 Кб, если 100 000 запросов в секунду то это 1 Gb / sec нужно пропускать.
Это начнуться уже ограничения канала сетевого, скорость записи диска.
К тому клоню что 100 000 запросов для того чтобы система не работала на пределе возможностей, нужно сразу рассматривать балансировщик и распределение нагрузки на несколько серверов.
Например 10 серверов по 10 000 запросов на каждый.
Немного другую вещь хотел выяснить, что мне даст Go, по сравнению с тем же C, C++ например.
Производительность или быстрее написать
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
В> Теперь вот размышляю, есть ли в природе решения, которые справятся с такой нагрузкой и на таком железе?
Напиши кастомное ядро (по аналогии с seL4) и сетевой стек к нему на ассемблере.
А из железа — есть же 100 корные процессоры. По 250 запросов на кору (при четырёхпроцессорной материнской плате) — не выглядит слишком страшным. Blade-сервера ещё бывают...
Re[5]: 100 тыщ одновременных запросов к веб серверу
Здравствуйте, okon, Вы писали:
O>Вероятно тут проблемы начнуться раньше из-за необходимости записи в базу или логирование, т.е. физические возможности железа принять такой поток информации.
100K одновременных соединений не означает наличие даже 1К запросов в секунду. Насколько я понимаю, речь идет про Management Information System (MIS), так что, подавляющее количество времени сервер будет просто ждать на открытом соединении, может пинги слать.
O>Немного другую вещь хотел выяснить, что мне даст Go, по сравнению с тем же C, C++ например. O>Производительность или быстрее написать
Он тебе даст: а) писать в раз так 3-5 быстрее чем на C++, б) зеленые потоки из коробки, и) заточенность под разработку сервисов (куча около-web компонент высокого класса). Я вот тут собирал в кучу свои мысли на этот счет.
ход мысли верный
не столько балансировщик (есть несколько кандидатов, кто напрямую сможет переварить столько соединений), сколько заморочки с хранилищем, которое захлебнется
Здравствуйте, Ватакуси, Вы писали:
В>Вот именно так клиент хочет. Зачем, почему без понятия ибо это конкурс и свои хотелки они не объясняют. Система типа 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 такое тоже можно написать. Но надо очень хорошо понимать, что ты делаешь.
Re[3]: 100 тыщ одновременных запросов к веб серверу
И не смешно вам пыхтеть над этим??
