Многопоточность в asp.net

Question

С какими проблемами многопоточности вам нужно быть осторожными в asp.net?

Answer 1

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

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

Answer 2

Одна вещь, которую нужно остерегаться при истечении срока действия (я думаю, что httpContext делает), если вы используете его для операций, которые «запускаются и забываются», помните, что внезапно, если код очистки asp.net запускается до того, как вы операция завершена, вы не сможете получить доступ к определенной информации.

Answer 3

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

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

Answer 4

В зависимости от того, что вам нужно, что касается многопоточности, вы подумали о порождении запросов от клиента. Безопасно создавать запросы с использованием AJAX, а затем воздействовать на результаты в обратном вызове. Или используйте сервис в качестве фонового механизма, который запускается каждые X минут и обрабатывает в фоновом режиме.

Answer 5

Не существует ли ограничения в 25 потоков в конфигурации IIS? По крайней мере, в IIS 6 я верю. Если вы превысите этот лимит, могут произойти интересные вещи (читай: время отклика).

Answer 6

Кеширование программ - одна из областей, которая сразу приходит мне в голову. Это отличная функция, которую нужно использовать осторожно. Поскольку он распределяется между запросами, перед его обновлением необходимо установить блокировки.

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