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

Если вы обнаружили, что пул потоков ASP.NET негативно влияет на мас­штабируемость системы, у вас есть несколько вариантов. Можно изменить верхний предел пула потоков. Как было сказано, верхний предел по умол­чанию соответствует 25 рабочим потокам и 25 потокам ввода-вывода. Ра­зумеется, увеличение верхнего предела — решение довольно грубое. Если вы сможете найти магическое число, позволяющее интенсивно использо­вать процессор и откладывать/отклонять запросы, только когда сервер

действительно слишком занят, чтобы их обрабатывать, считайте, что вам

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

Другое решение заключается в выявлении запросов, которые требуют мно­го времени для обработки, но не нагружают процессор, и выделении для них отдельных потоков, что позволит освободить пул потоков для обра­ботки дополнительных запросов. Здесь в игру и вступают асинхронные

обработчики.

Асинхронные обработчики

Хотя большинство страниц и обработчиков ASP.NET обслуживается син­хронно в потоках из пула уровня процесса, можно создать обработчики (и даже страницы), которые будут обслуживать запросы асинхронно. Асинх­ронные обработчики