- Есть асинхронные издержки (отслеживание всего)
Правильно. Тем не менее, скорость, получаемая от асинхронных задач, значительно перевешивает накладные расходы, поэтому она незначительна. Если вы не начнете рассылать спам по многим задачам с помощью крошечных тел выполнения, в этот момент накладные расходы (на задачу) станут заметным фактором.
Основной момент, который я пытаюсь уточнить, заключается в том, что запрос может занять больше времени из-за того, что нет доступных потоков после завершения асинхронной задачи, например, если вызов db завершен, нужно ли когда-либо ждать больше времени для потока становится доступным?
Педантично, это правильно. Ваша «первая» операция, которая была отложена, потому что она ожидала завершения задачи, не сможет встать в очередь в тот момент, когда ее задача будет завершена.
Операция должна вернуться в очередь, но получает приоритет над операциями, которые еще не были начаты. Это очень похоже на, например, как работает почтовое отделение:
- Вы в очереди
- Вы попадаете на стойку регистрации, работник почты дает вам форму для заполнения (и, таким образом, ожидает вы заполняете эту форму)
- Вы отходите в сторону и заполняете форму, пока работник почты может помогать другим, вместо того, чтобы бездельничать, пока она ждет вас.
- Когда вы закончите со своей задачей, вы не откладываете клиента, которому в данный момент помогают, в сторону ... (это то, чего вы, похоже, хотите: получить немедленное внимание потока и не ждать окончания его работы) .
- ... но вам разрешат прыгнуть в очередь перед людьми, которые еще не разговаривали с почтовым работником.
Примечание: по крайней мере, так моя культура (Западная Европа) справляется с этим. Ваш пробег может отличаться.
Итак, да, ваше предположение на самом деле верно; но я хочу подчеркнуть, что разница во времени здесь астрономически ничтожна по сравнению с выгодами от асинхронной работы.
Если вы хотите сжать определенную операцию для максимально быстрой производительности, вам придется предоставить ей собственный поток и не позволять ей участвовать в расписании «асинхронного пула». Но я настоятельно рекомендую против этого, поскольку выгода от этого будет чрезвычайно незначительной и никоим образом не перевесит сложность ее разработки.
Во-вторых, учтите, что в «хорошо спроектированной асинхронной системе» (согласно вашему вопросу) задачи будут разбиты на наименьшие разумные операции, и, таким образом, выполнение одной задачи (исключая любое время ожидания между ними) не будет быть значительным. На практике вы не заметите необходимости ждать, пока поток станет доступным - если вы чрезмерно перенасыщаете рабочую нагрузку вашего сервера и действительно раздвигаете пределы - в какой момент у вас есть другая большая рыба, которую нужно жарить.
Предположим, у меня есть хорошо спроектированная асинхронная система, но у меня есть один метод, который мне нужен, чтобы быть как можно более быстрым и гибким - я не хочу ничего мешать времени выполнения этого одного вызова. Конечно, в этой ситуации, если я сделаю этот метод асинхронным и освободлю поток, вызов может потенциально ждать, пока поток завершит свое выполнение, если он асинхронный, тогда как, если он синхронизирован, поток всегда будет там ждать - при за счет производительности остальной части приложения?
Я не понимаю ваших рассуждений здесь.
Если вы предполагаете, что «поток ждет меня» в синхронном примере, это означает, что этот поток доступен и в данный момент не занят. Но для вашего асинхронного примера вы предполагаете, что все потоки заняты, и ни один не доступен.
Это совершенно разные ситуации. Если все потоки насыщены в асинхронном приложении, то все потоки (будь то один или несколько) в синхронном приложении также будут заняты.
Цель асинхронности совсем противоположна. Если поток в настоящее время занят, но находится в режиме ожидания, в синхронном приложении вы будете вынуждены ждать и не сможете использовать поток. Однако в асинхронном приложении ожидающий поток сможет начать обработку вашего запроса, так как он в настоящее время находится в режиме ожидания, поскольку ожидает другую задачу, которая еще не выполнена.