много поточная обработка веб-приложения

IMHO, вам следует избегать использования многопоточности в веб-приложении.

возможно, многопоточное приложение могло бы повысить производительность в стандартном приложении (с правильным дизайном), но в веб- приложения вы можете захотеть сохранить высокую пропускную способность вместо скорости.

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

Многопоточность - это метод, позволяющий выделить отдельному процессу больше времени, чтобы он работал быстрее. У него больше потоков, поэтому он потребляет больше циклов процессора. (От нескольких процессоров, если они у вас есть.) Для настольного приложения это имеет большой смысл. Но предоставление большего количества циклов ЦП веб-пользователю отнимет те же циклы у 99 других пользователей, выполняющих запросы одновременно! Так что технически это плохо.

Однако веб-приложение может использовать другие службы и процессы, использующие несколько потоков. Базы данных, например, не будут создавать отдельный поток для каждого пользователя, который к ним подключается. Они ограничивают количество потоков до нескольких, добавляя соединения в пул соединений для более быстрого использования. Пока есть доступные или объединенные соединения, пользователь будет иметь доступ к базе данных. Когда в базе данных заканчиваются соединения, пользователю придется подождать.

Итак, в основном, использование нескольких потоков может использоваться для веб-приложений, чтобы уменьшить количество активных пользователей в определенный момент! Это позволяет системе совместно использовать ресурсы с несколькими пользователями без перегрузки ресурса. Вместо этого пользователям просто нужно будет стоять в очереди, прежде чем наступит их очередь.

Это будет не многопоточность в самом веб-приложении, а многопоточность в службе, которая используется веб-приложением. В данном случае он используется как ограничение, позволяя быть активным только небольшому количеству потоков.

Это позволяет системе совместно использовать ресурсы с несколькими пользователями без перегрузки ресурса. Вместо этого пользователям просто нужно будет стоять в очереди, прежде чем наступит их очередь.

Это будет не многопоточность в самом веб-приложении, а многопоточность в службе, которая используется веб-приложением. В данном случае он используется как ограничение, позволяя быть активным только небольшому количеству потоков.

Это позволяет системе совместно использовать ресурсы с несколькими пользователями без перегрузки ресурса. Вместо этого пользователям просто нужно будет стоять в очереди, прежде чем наступит их очередь.

Это будет не многопоточность в самом веб-приложении, а многопоточность в службе, которая используется веб-приложением. В данном случае он используется как ограничение, позволяя быть активным только небольшому количеству потоков.

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

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

ASP.NET уже может порождать несколько потоков для параллельной обработки нескольких запросов, поэтому для простой обработки запросов редко бывает случай, когда вам нужно вручную порождать другой поток. Однако есть несколько необычных сценариев, с которыми я столкнулся, которые требовали создания другого потока:

• Если есть какая-то операция, которая может занять некоторое время и может выполняться параллельно с остальной обработкой страницы, вы можете создать вторичный поток там. Например, если существует веб-сервис, который вам нужно было опросить в результате запроса, вы можете создать другой поток в Page_Init и проверить результаты в Page_PreRender (при необходимости ожидая). Хотя это все еще вопрос, будет ли это улучшением производительности или нет - создание потока не является t дешево, и время между типичным Page_Init и Page_Prerender в любом случае измеряется в миллисекундах. Хранение пула потоков для этого может быть немного более эффективным, и в ASP.NET также есть нечто, называемое «асинхронными страницами», которое может даже лучше подходить для этой потребности.
• Если есть пул ресурсов, который вы хотите использовать периодически убирать. Например, представьте, что вы используете какую-то странную СУБД, которая поставляется с ограниченными привязками .NET, но нет поддержки пула (это был мой случай). В этом случае вы можете захотеть реализовать пул соединений с БД самостоятельно, и это потребует «более чистого потока», который будет просыпаться, скажем, раз в минуту и ​​проверять, есть ли соединения, которые не использовались долгое время (и таким образом можно закрыть).

Еще одна вещь, о которой следует помнить при реализации собственных потоков в ASP.NET - ASP.NET любит отключать свои процессы, если они какое-то время были неактивными. Таким образом, вы не должны полагаться на то, что ваш поток останется в живых навсегда. Это может быть прекращено в любой момент, и вам лучше быть к этому готовым.