ArchLord42
Дмитрий Королев

(53) В желтых книгах про это не пишут )

(54)
(55)

Какое открытие!) Вам следуют разобрать что такое асинхронность и что такое многопоточность.
И про UI поток почитать заодно...

(16) неа у 1С нету возможности публикации через nginx напрямую.

(22) Скорее всего на JS, т.к. все эти подходы, еще с первой реализации (промис, резолв, реджекс) больше на него указывают, чем на шарп.
Ну и в целом это логично, веб клиент же на нём написан.

(24) Не важно сколько бы он жил, важно что если я кину 1000 реквестов в одну единицу времени оверхед по памяти и процессору (на инициализацию потока) был бы очень сильным, вот как раз так АПАЧ \ IIS и работают.

Даже если представить что у нас 512gb оперативки, и скажем 64 ядерный проц, то в тик времени, процессор будет пережевывать только 64 потока \ реквеста, ну а на завершение реквеста нам будет нужно явно не 1 тик, а намного больше, что же для остальных реквестов?) ну ничего подождут :))

Ваш бенчмарк, который вы мне второй раз кидаете, показывает как хорошо работает асинхронность в nginx, спасибо я и так это знаю :)

Раз так любите бенчмарки, вот вам бенчмарк, который показывает разницу в подходах:
1) поток на реквест
2) асинхронный поток, который обрабатывает несколько реквестов.
https://i.stack.imgur.com/ds7Ly.png

ЗЫ. на самом деле, там все посложней, осюда чаще всего для повышения производительсности используется thread pool ибо не всегда можно избежать блокирующего вызова, в общем доклад выше, очень рекомендую :)

Если бы на каждое содеинение инициировался поток, вам бы не процессора не оперативной памяти не хватило. Это довольно жуткий оверхед получился бы.

Рекомендую ознакомится с докладом Jeffrey Richter — Building responsive and scalable applications, на ютубчике есть, там супер подробно рассказано что такое асинхронность, почему многопточность это иногда зло и как делать приложения быстрыми. Правда про .NET (но кода почти нет) и на иглише, но подробнее не видел

А то что вы мне какие то замеры кидаете...и про нейронки пишите...хм да это и так понятно, я ж не говорю, что многопоточность = зло. Я говорю, что это сложно, не всегда возможно (кстати да, GUI приложения очень сильно завязаны на одном едиственном GUI потоке) и что асинхронность это чаще всего залог производительности, которую часто путают с многопоточностью.

(16)

Цитата
Я, например, множество Мандельброта на С рисовал, разделив окно на столько частей, сколько у меня ядер/потоков. Более того, встречал в интернете простой код, который делал то же самое - создать поток и передать ему координаты - вообще не проблема.

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


(16)

Цитата
Но когда в приложении разные потоки могут читать и писать одно и то же, то, обычно, выделяют быстрый однопоточный механизм вставки/чтения и вокруг него множество потоков генерируют ему задачи. На этом принципе основан REDIS и NGINX, например, поэтому они такие резкие )))

Вот как раз наоборот, из-за того NGINX однопоточен и у него нет контекст свитчинга, он работает быстро :)
Так же у него выделяется несколько дочерних процессов (workers) обычно на количество ядер, но все процессы работают в однопоточном режиме, тут скорость же достигается из-за того, что работает они в асинхронном режиме со стейт машинами, async IO + events, грубо говоря тот же async \ await.

В общем формула тут такая:

Быстродействие != многопточность
Многопточность != асинхронность

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

Если вы думаете, что сделать многопоточное приложение легко, то я вас разочарую, это довольно сложный процесс, я даже больше скажу, в 2020!!! году современные приложения на других языках пишутся не с оглядкой на многопоточность, а на максимальную утилизацию потоков, распространненный async \ await паттерн тому пример.

(12) В IIS есть вкладка "Пулы приложений", там создать пул "без управляемого кода \ No managed code" с произвольным именем, потом кликнуть на публикацию -> основные настройки, там будет поле ввода так и называется "Пул приложений" выбрать в качестве пула созданный пул.

(5) А самое главное не стоит 10 СМов + код очень хорошо написан! :)