пойди бенчмарк напиши =)

запусти и проверь, тысяч 500 тредов

Alex иногда я думаю, может зря я тебя разбанил? :)

сотни тысяч тредов в линупсе будут только лишь инициализироваться минут десять

Сотни тысяч тредов не могут ошибаться!

пойди бенчмарк напиши =)

что мен писать, я сравнивал pthread с горутинами

с другом было дело баловались

ну и сколько занимает создание треда?

я создание каждого треда по времени не замерял. Создавали по 12 тысяч. У меня уходило порядка 15-18секунд минимум

Треды линупсовые хорошие где нужен быстрый io

т.к крутятся в системном планировщике

100к тредов за десять минут это 6 миллисекунд на тред (6000000 наносекунд карл!!11), за это время можно очень многое сделать

а инициализация все равно не многим шустрее fork классического

Поэтому для сотен тысяч тредов взял бы язык с зелеными потоками

мне кажется ты не понимаешь о чём ты говоришь

И не долбил ядро сотнями тысяч системных вызовов, не говоря про память

И не долбил ядро сотнями тысяч системных вызовов, не говоря про память

Сколько памяти ест один тред?

Сколько памяти ест один тред?

тролльский вопрос

тролльский вопрос

Человек заявил, я спросил. Сам нарывается

Сколько памяти ест один тред?

Я вес одного потока не замерял. Явно меньше 4кб

Я вес одного потока не замерял. Явно меньше 4кб

а это значит, что если я перепишу приложение с многих процессов на треды, то я сэкономлю бездну памяти?

понятно, ещё один golangfanboy

Подсказать правильный счет куда перечислять?

Все равно не даст. Секьюрити thru анальная огороженность.

мне кажется ты не понимаешь о чём ты говоришь

Я говорю что сотни тысяч потоков запускать с отображением N:M на ядро маразм. Выигрыш только в лучшем IO за счет того что вся эта масса в системном планировщике висит

понятно, ещё один golangfanboy

лол. я и на плюсах пишу

просто кто-то выбирает инстурмент под задачу

а кто то "пишу на том что знаю"

дада, я в школе тоже "на плюсах писал" =_)

дада, я в школе тоже "на плюсах писал" =_)

Ну я не знаю, судя по тому что ты говоришь о сотнях тысяч вызовов системного clone для асинхронщины- кажется что школа не прошла

>лучшем IO за счет того что вся эта масса в системном планировщике висит а вот этот момент давайте подробнее (:

мне кажется там про асинхронщиность речи не шло =) там был абстрактный сервер в вакууме, и ceph судя по хостнейму =)

>лучшем IO за счет того что вся эта масса в системном планировщике висит а вот этот момент давайте подробнее (:

материала полно, думаю при желании и в вике можно найти

материала полно, думаю при желании и в вике можно найти

слился.

мне кажется там про асинхронщиность речи не шло =) там был абстрактный сервер в вакууме, и ceph судя по хостнейму =)

Угу

>лучшем IO за счет того что вся эта масса в системном планировщике висит а вот этот момент давайте подробнее (:

Это называется на слив, а "впадлу рассказывать про очевидные вещи". или про системный планировщик не слышал? Контекст процесса, что pthread это оторажение на странички памяти через ядрышко? Да знаешь ты все это

Поэтому лень даже мусолить про это

я тоже всегда говрю: главное знать термины! тогда ими можно давить в любом аргументе! =)

мне кажется там про асинхронщиность речи не шло =) там был абстрактный сервер в вакууме, и ceph судя по хостнейму =)

я просто сказал что мне страшно представить сотня тысяч системных процессов в 1 задаче))

что тут такого-то)

я не говорил что в одной

Ну ок)

я тоже всегда говрю: главное знать термины! тогда ими можно давить в любом аргументе! =)

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

я говорил про кол-во тасков в системе -- я старался быть точным в своей терминологии

к слову об сотне тысяч тредов в нескольких процессах -- есть идеи почему CDN'ы часто терминируют TLS на apache а не nginx? =)))

(пример - Fastly)

к слову об сотне тысяч тредов в нескольких процессах -- есть идеи почему CDN'ы часто терминируют TLS на apache а не nginx? =)))

интересно. nginx дает слишком волосатое (скачущее) время инициализации TLS?

интересно. nginx дает слишком волосатое (скачущее) время инициализации TLS?

близко, но не совсем

наверное потому что напрефоркали на всю память процессов и сидят на жопе ровно

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

ты начал просить подробнее тебе рассказать про планировщик. Тебе коротко и ясно ответил - есть маны и по планировщику, и по clone в линукс мане. Сказал бы сначала в чем я не прав, а то откуда вылез и с каким словом- не понятно

наверное потому что напрефоркали на всю память процессов и сидят на жопе ровно

да, трумоде

наверное потому что напрефоркали на всю память процессов и сидят на жопе ровно

ну оно потом проксируеются на event-ориентированный сервер

ты начал просить подробнее тебе рассказать про планировщик. Тебе коротко и ясно ответил - есть маны и по планировщику, и по clone в линукс мане. Сказал бы сначала в чем я не прав, а то откуда вылез и с каким словом- не понятно

производительность io не связана с тем, кто дергает сисколл (процесс, тред, блаблабла).

близко, но не совсем

тогда объясни. интересно. не вижу глубокой разницы в таком режиме, если nginx'у сделать много воркеров (заметно больше, чем ядер) и apache с префорком

к слову об сотне тысяч тредов в нескольких процессах -- есть идеи почему CDN'ы часто терминируют TLS на apache а не nginx? =)))

так вот, твоя прекрасная event-ориентированная идеология идёт, мягко говоря, по пизде, если event-loop блокируется, но блокироваться он может не только на IO, но ещё и на CPU, например при большём потоке TLS хендшейков(а это ~2мс блокировки на каждый, для RSA2048) nginx просто перестаёт обслуживать соединения, только и занимаясь handshake'ами. И тоже самое для любой cpu-intensive штуки. Gzip -9? Brotli -11? - эти шткуки всегда должны быть в отдельных потоках, чего зилоты event-oriented парадигмы часто не понимают.

если сильно увеличить кол-во воркеров, там появлляется другая проблема - нагрузка на них начинает очень не ровно разбазываться, что скорее linux-related проблема

так вот, твоя прекрасная event-ориентированная идеология идёт, мягко говоря, по пизде, если event-loop блокируется, но блокироваться он может не только на IO, но ещё и на CPU, например при большём потоке TLS хендшейков(а это ~2мс блокировки на каждый, для RSA2048) nginx просто перестаёт обслуживать соединения, только и занимаясь handshake'ами. И тоже самое для любой cpu-intensive штуки. Gzip -9? Brotli -11? - эти шткуки всегда должны быть в отдельных потоках, чего зилоты event-oriented парадигмы часто не понимают.

да, да, да. я потому и говорю про волосатое время, потому что ssl - долго и event-loop в это время простаивает. но почему увеличение числа воркеров нджинкса действует хуже, чем префорк?

если сильно увеличить кол-во воркеров, там появлляется другая проблема - нагрузка на них начинает очень не ровно разбазываться, что скорее linux-related проблема

reuseport в listen это не полечил хотя бы частично разве?

reuseport в listen это не полечил хотя бы частично разве?

ну там другой баг есть в ядре - в момен reload'а будут rst'шиться syn'ы =)

производительность io не связана с тем, кто дергает сисколл (процесс, тред, блаблабла).

Согласен, но ты здесь не учитываешь другого. Зависимость тут обратная скорее. Если ты сокеты те же раскидаешь по потокам системного уровня, то за счет большего процессорного времени чтение происходил бы быстрее, чем если бы потоки были пользовательского уровня и спрятаны были бы за свой планировщик. Это сильный оверхед. Поэтому, как гвоорят, если в го стартануть несколько процессов, то планировщик его начинает сильно тупить, IO проседает. Я тут скорее сравнивал потоки системного и пользовательского уровней

ну там другой баг есть в ядре - в момен reload'а будут rst'шиться syn'ы =)

(так как кол-во воркеров меняеться и hashtable превращается в тыкву)

> Поэтому, как гвоорят, если в го стартануть несколько процессов, то планировщик его начинает сильно тупить, IO проседает а как связаны между собой разные golang процессы?

(так как кол-во воркеров меняеться и hashtable превращается в тыкву)

гы, забавный эффект. не думал о нем. а это, раз уж ты тут, получается с reuseport, если не париться о reload'ах, все становится хорошо? я буквально недавно тестировал reuseport на ssl и нагрузка идеально ровная на ядра. если добавить еще cpu affinity на воркеры, то выглядит совсем хорошо.

> Поэтому, как гвоорят, если в го стартануть несколько процессов, то планировщик его начинает сильно тупить, IO проседает а как связаны между собой разные golang процессы?

общим планировщиком. Вот если общий планировщик мапит N:1, то IO работает лучше в го, чем мат например N:100.

reuseport в listen это не полечил хотя бы частично разве?

в нём кстати есть другая засада --- там коннект получает тот worker на который hash попал, а не тот который щас свободен и вызвал на accept()

общим планировщиком. Вот если общий планировщик мапит N:1, то IO работает лучше в го, чем мат например N:100.

ааа, ты "процессами" горутины назвал

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

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

пару тысяч можно делать на 2х ядрах -- это не нагрузка

а сколько нагрузка?

ааа, ты "процессами" горутины назвал

ничего страшного, процесс пользовательского уровня это. все правильно с терминологией. Поток пользовательского уровня было бы вернее

Ребята срочно нужна помощь

Как пользоваться ботом TempMail. Как посмотреть эту чертову почту? Как войти в этот ящик? Помогите!!!!!???

дуал ксеон в 48 ядер с трудом тянет 7

это канал про аниме?

а сколько нагрузка?

нагрузка это 60%+ от максимума - на Xeon v3 это примерно 1500+ в секунду для RSA2k

если тебя заботит производительность кода на 99%-ной нагрузке, то ты что-то делаешь не так

дуал ксеон в 48 ядер с трудом тянет 7

значит либо старый Xeon, либо хреново собраный / старый openssl

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

когда цифры большие, графики времени ответа становятся лохматые. ну потому что event-loop лочится. там можно дойти до того, что будут ложные таймауты бэкендов, когда бэкенд отвечает быстро, а у event-loop не доходит за таймаут до бэкенда. в нджинксе, это кажется полечено атомарностью времени на начало event-loop'а, но я не уверен.

если тебя заботит производительность кода на 99%-ной нагрузке, то ты что-то делаешь не так

меня заботит что будет когда меня начнут DDoS'ить, и поверьте любой CDN ну оооочень часто DDoS'ят =)

в случае ддосов речь о порядках запаса

а не о двух процентах

зачем кстати ддосить сдн?:)

к слову а всинхронных хендшейках -- вот тут был неплохой тред на эту тему(патчи прилагаются), но я вроде скидывал уже http://mailman.nginx.org/pipermail/nginx-devel/2016-November/009158.html

меня заботит что будет когда меня начнут DDoS'ить, и поверьте любой CDN ну оооочень часто DDoS'ят =)

Ты меня запутал) Я именно процессы Gо назвал. Которые мапятся на ядро. С горутинами работает внутренний планировщик. Собственно, если ты создаешь много процессов, то планировщик GO начинает тупить и IO. Go по факту лучше всего работает с моделью N:1

вы какую-то лабораторную задачу решаете кажется:)

зачем кстати ддосить сдн?:)

ну ДДоСят сайт игровой или продажной тематики -- все в щоке -- ген дир рвёт волосы -- быстро ищую в интернете -- оказывается если положить сайт за cloudflare то он начнёт тянуть DDoS, тут же подписывают контракт, переводят dns'ы на CF и вуаля - аттакер ддосит CDN.

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

ну все-таки cf не совсем cdn :)

ну щас любой CDN практически тебе может ddos-shield дать

тупо потому что это очень денежная ниша

не делайте популярных сервисов, не зарабатывайте на проектах

и не будут Вас ддосить

?все просто пацаны

Ты меня запутал) Я именно процессы Gо назвал. Которые мапятся на ядро. С горутинами работает внутренний планировщик. Собственно, если ты создаешь много процессов, то планировщик GO начинает тупить и IO. Go по факту лучше всего работает с моделью N:1

а как я могу там процесы создать (предположим я не юзаю cgo)? =)

Блиа. Зачем опять какие-то тупые картинки тут?

кукла малолетка

Чтобы тебя позлить конечно

кукла малолетка

Жмет она поболее, чем ты )

ноги - ок, пресидает значит!