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

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

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

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

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

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

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

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

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

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