Имеет ли многопоточность смысл в asp.net?

в разработке winforms вы можете создать BackgroundWorker чтобы избежать блокировки пользовательского интерфейса в длительном процессе. В ASP.NET сообщение / GET в основном зависает до завершения. Я не вижу, как добавить Thread было бы полезно для этого процесса. Может быть, если Thread ускорит завершение (скажем на многоядерном сервере), это поможет ускорить процесс.

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

- Это что? Является ли threading довольно бесполезным ASP.NET?

9
asp.net multithreading

6 ответов

многопоточность может сделать запросы быстрее, если:

  1. работа каждого веб-запроса может быть разбита на несколько задач, которые могут выполняться параллельно
  2. каждая из этих задач очень интенсивна для процессора (CPU bound), или у вас есть несколько связанных задач ввода-вывода на разных путях ввода-вывода (см. комментарии)
  3. вы можете реализовать их с помощью разделение/объединение параллельность.

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

5

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

1

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

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

1

Это зависит от рабочей нагрузки и варианта использования. Системы запросов/ответов лучше всего обслуживаются, выполняя их asynchrounously на стороне клиента.

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

суть в том, что если данные, которые вы получаете, могут быть загружены быстрее параллельно, сделайте это, иначе используйте асинхронные (ajax) вызовы от клиента, чтобы предотвратить пользовательский интерфейс от блокировки

1

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

private void Page_Load(object sender, EventArgs e)
{
  ICollection<WorkItem> workitems = GetWorkItems();

  Parallel.ForEach(workitems,
    (item) =>
    {
      ProcessWorkItem(item);
    });

  // Now that we have all of our work items completed we can continue loading the page.
}
1

Я бы не зашел так далеко, чтобы сказать, что резьба бесполезна в ASP.NET но это определенно другая модель. Для запросов ресурсов (запросов страниц) в целом поток обрабатывается системой. То есть запрос A от пользователя 1 может занять больше времени, чем запрос B от пользователя 2, и последний не неудобен первым. Применяя эту концепцию к AJAX-запросам, как вы предлагаете, и вся модель становится многопоточной по умолчанию и масштабируется до любого оборудования ручка.

нерест нить can оказаться полезным, если по какой-то причине, запрос должны породить какой-то длительный процесс и должен ответить пользователю до завершения процесса. Как правило, неработающие процессы должны быть повторно учтены из веб-приложения и помещены в их собственную серверную службу. Но это не совсем неслыханно для запроса страницы, чтобы создать поток, который, как ожидается, сделает что-то в фоновом режиме в течение нескольких минут, чтобы браузер не ждет все время (и, вероятно, тайм-аут).

0