Производительность — это особенность приложения. Вам нужно думать о производительности сразу при проектировании приложения, иначе вы будете переписывать ваш исходный код позже.
Публикуемый ниже материал представляет собой первый совет из целой серии советов по оптимизации приложений, использующих технологии ASP и Visual Basic Scripting Edition (VBScript). Большинство из них были многократно обсуждены и c успехом проверены на веб-сайте Microsoft Corporation и других ASP-сайтах. Авторы материала подразумевают, что вы уже знакомы с основами разработки ASP-приложений, включая VBScript и/или JScript, ASP-сессиями и др. важными объектами (Request, Response и Server).
Кэшируйте часто используемые данные на сервере
Типичная ASP-страница получает данные из базы данных и затем выводит их в формате HTML. Независимо от скорости вашей базы данных, получение данных из памяти сервера намного быстрее, чем обработка sql-запроса к конечной базе данных. Получение данных, сохраненных на локальном жестком диске, также обычно быстрее, чем получение информации из БД. Поэтому одним из основных путей увеличения скорости работы вашей ASP-страницы является кэширование часто используемой информации в памяти или на жестком диске.
Кэширование данных — это классический компромисс «место или время». Если вы избрали для кэширования правильный материал, вы можете видеть внушительное повышение производительности вашего приложения. Чтобы кэширование было эффективным нужно использовать для временного хранения только те данные, которые многократно используются для вывода и каждый раз трудоемки для повторных вычислений. Кэш, полный устаревшей информации, будет пустой тратой памяти сервера.
Данные, которые не изменяются часто, являются хорошим кандидатом для кэширования, потому что вам не надо будет волноваться относительно их синхронизации через какое-то время с конечной базой данных. Выпадающие списки (сombo-box), таблицы ссылок, пункты меню, и переменные конфигурации сайта (включая имена DSN, адреса IP и URL) — первые кандидаты для хранения в кэше. Заметьте, что вы можете кэшировать представление данных много быстрее, нежели данные сами себя. Если ASP-страница изменяется не так часто и ее временный кэш будет весьма внушительным (например, полный каталог изделий фирмы), попробуйте использовать сгенерированные HTML-страницы, чем каждый раз загружать сервер генерацией ASP-страниц.
Кэшируйте часто используемые данные в объектах Application или Session
Объекты Application и Session служат для хранения данных в памяти, значения которых могут быть доступны между несколькими HTTP-запросами (в отличие от обычных переменных, чьи значения доступны только в теле одной ASP-страницы). Данные объекта Session доступны только одному пользователю (в течении его сессии), в то время как данные Application доступны всем пользователям веб-сайта. Поэтому часто перед разработчиком возникает вопрос: в каком из объектов сохранять часто используемые данные. Обычно, для инициализации переменных этих объектов используются процедуры файла Global.asa — Application_OnStart() или Session_OnStart() соответственно. Если в вашем Global.asa еще нет этих процедур, то вы можете добавить их сами или инициализировать переменные, когда это будет необходимо. Примером может быть следующая процедура, использующая Application для хранения значений многократно использующейся переменной EmploymentStatusList. Процедура проверяет существование данных в EmploymentStatusList и при необходимости расчитывает их заново:
<% Function GetEmploymentStatusList Dim d d = Application("EmploymentStatusList") If d = "" Then " Если значения нет - выполним расчет d = FetchEmploymentStatusList() Application("EmploymentStatusList") = d End If GetEmploymentStatusList = d End Function %>
Подобную функцию можно написать для любой задачи, где не стоит каждый раз заново выполнять тродоемкий расчет. При этом могут быть сохранены данные любого формата (тип variant). Например, вы можете использовать строковые значения, целые числа, массивы или набор записей. Например:
Function FetchEmploymentStatusList Dim rs Set rs = CreateObject("ADODB.Recordset") rs.Open "select StatusName, StatusID from EmployeeStatus", _ "dsn=employees;uid=sa;pwd=;" "Получить все строки FetchEmploymentStatusList = rs.GetRows() rs.Close Set rs = Nothing End Function
Если полученный массив будет часто использоваться, тогда лучше хранить его сразу в виде HTML-списка, чем массив, которое каждый раз нужно преобразовывать в HTML:
Function FetchEmploymentStatusList Dim rs, fldName, s Set rs = CreateObject("ADODB.Recordset") rs.Open "select StatusName, StatusID from EmployeeStatus", _ "dsn=employees;uid=sa;pwd=;" s = "" & vbCrLf rs.Close Set rs = Nothing FetchEmploymentStatusList = s End Function
Кэшируйте данные на диске веб-сервера
Иногда в памяти вашего веб-сервера может быть слишком большое количество данных. "Слишком много", конечно, является спорным вопросом — это зависит от того, сколько памяти вы хотите использовать, а также число элементов для кэширования и частота, с которой эти элементы будут запрашиваться. В любом случае, если вы имеете слишком большое количество данных для кэширования в памяти, подумайте о переносе кэша в текстовый или XML-файл на жесткий диск веб-сервера. Вы можете одновременно комбинировать кэширование на диске и в памяти, чтобы сформировать оптимальную стратегию для вашего сайта.
Заметьте, что при измерении производительности одиночной ASP-страницы, получение данных с диска может не всегда быть быстрее, чем получение равноценных данных из БД. Но "файловое" кэширование уменьшает загрузку БД и сети, а при высокой загрузке БД до, значительно улучшит общую производительность после. Кэширование может быть очень эффективно при кэшировании результатов сложных запросов (например, соединение таблиц), трудоемких процедур сохранения, больших наборов записей. Чтобы убедится, насколько выгодным будет это решение требуется протестировать различные схемы сохранения.
ASP и COM обеспечивают несколько инструментальных средств для создания схем кэширования на диске. Функции набора записей ADO Save() и Open() сохраняют и загружают recordset c диска. Используя эти методы вы можете переписать код из прошлого совета, заменяя запись в объект Application на метод Save() для записи в файл.
Есть несколько других компонентов, которые работают с файлами:
* Scripting.FileSystemObject позволяет создавать, читать и записывать файл.
* MSXML, MicrosoftR XML parser поддерживает сохранение и загрузку XML-документов.
* Объект LookupTable (например, используемый на MSN.com) — лучший выбор для загрузки простых списков с диска.
Наконец, рассмотрите вопрос принудительного кэширования информации на диске. Сгенерированный HTML-код может быть сохранен на диске как.htm или.asp файл; гиперссылки могут указывать прямо на этот файл. Вы можете автоматизировать процесс генерации HTML, используя коммерческие инструментальные средства типа XBuilder или средства публикации в Интернет, входящие в MicrosoftR SQL ServerT. Кроме того, при помощи директивы #include можно включать отдельные HTML-части в файл ASP или читать HTML-файл с диска используя FileSystemObject. Например, на начальной странице vbCode (http://vbcity.com/vbcode/ru/home.asp) приводятся 10 последних тем обсуждения двух дискуссионных форумов. Отобразить эти списки можно при помощи создания двух наборов записей ADO при каждом обращении к данной странице или, следуя данному совету, сохранить их однажды в виде HTML-файла list.inc, а затем включать в home.asp:
Второй путь работает значительно быстрее.
Избегайте кэшировать медленные компоненты в объектах Application или Session
Несмотря на то, что кэшированиe данных в объектах Application или Session может быть хорошей идеей, кэширование COM-объектов может иметь серьезные ловушки. Занесение наиболее используемых COM-объектов в объекты Application или Session часто соблазняет, но, к сожалению, много COM-объектов, включая все, написанные в Visual Basic 6.0 или ранее, могут вызывать серьезные критические проблемы после сохранения в объектах Application или Session.
В частности, любой компонент, который выполняется медленно, вызовет критические проблемы когда кэшируется в объектах Session или Application. Быстрый (проворный non-agile) компонент — компонент, помеченный ThreadingModel=Both, который объединен Free-threaded marshaler (FTM), или — компонент, помеченный ThreadingModel=Neutral. (Neutral — новая модель в WindowsR 2000 and COM+). Следующие компоненты не проворны:
* Free-threaded components.
* Apartment-threaded components.
* Single-threaded component.
* Configured components (библиотека Microsoft Transaction Server (MTS)/COM+ и серверные приложения) не проворны пока они Neutral-threaded. Apartment-threaded components и другие не проворные компоненты хорошо работают в пределах страницы (т.е. создаются и разрушаются в пределах одной ASP-страницы).
В IIS 4.0 компонент, отмеченный ThreadingModel=Both выполняется быстро. В IIS 5.0 уже не так достаточно. Компонент не должен только быть отмечен как Both, он должен также объединен FTM.
IIS выполняет проверку компонентов, но если вы хотите ее отменить (т.е. хотите позволить непроворным компонентам быть сохраненными в объектах Application или Session), вы можете установить AspTrackThreadingModel в metabase в значение True. Но это (изменение AspTrackThreadingModel) не рекомендуется.
IIS 5.0 выдаст сообщение об ошибке, если Вы пытаетесь сохранить непроворный компонент, созданный с использованием Server.CreateObject, в объекте Application. Вы можете обойти это, используя
Что же все-таки неправильно если вы кэшируете непроворные компоненты? Непроворный компонент, кэшируемый в объекте Session блокирует Session от других рабочих потоков (thread) ASP. ASP обслуживает пул (контейнер) рабочих потоков, запрашиваемых другими сервисами. Обычно, новый запрос обрабатывается первым доступным потоком. Если Session блокирована, то запрос должен ждать поток, когда он станет доступным. Проведем аналогию, которая поможет понять эту ситуацию: вы идете в магазин, выбираете несколько булок, и платите за них в кассе #3. Всякий раз, после того как вы выбрали булки в том магазине, вы всегда оплачиваете их в кассе #3, даже в том случае, когда в других кассах короче очередь или даже вообще нет покупателей.
Сохранение непроворных компонентов в объект Application накладывает столь же негативный эффект на производительность. ASP создает специальный поток для выполнения меделенных компонентов в пределах Application. Это имеет два последствия: все запросы выстраиваются в очередь к этому потоку и все запросы сериализуются. Выстраивание в очередь означает, что параметры были сохранены в общедоступной области памяти; запросы переключаются к специальному потоку; метод компонента выполнен; результаты выстраиваются в общедоступную область. Сериализация (преобразование в последовательную форму) означает, что все методы выполняются в одно время. Для двух различных потоков ASP не возможно одновременное выполнение методов общедоступного компонента. Это уничтожает многопотоковость (параллелизм), особенно на мультипроцессорных системах. Хуже всего то, что все непроворные компоненты в пределах Application совместно используют один поток ("Host STA"), так что негативные результаты сериализации налицо.
Смущены? Есть некоторые общие правила. Если Вы пишете объекты в Visual Basic (6.0 или ранее), не храните их в объектах Application или Session. Если вы не знаете потоковую модель объекта, не храните его в кэше. Вместо кэширования где-либо непроворных объектов, вы должны создать и удалить их на каждой странице. Объекты выполнятся непосредственно в рабочем потоке ASP и не будет никакой очереди или сериализации. Производимость будет адекватна, если COM-объекты запущены под IIS и если они не используют много времени, чтобы инициализироваться и уничтожаться. Заметьте, что однопотоковые (single-threaded) объекты не должны использоваться этот путь. Будьте внимательным — VB может создавать однопотоковые объекты! Если вы используете однопотоковые объекты, этот путь (типа таблицы Microsoft Excel) не рассчитывает на высокую производительность.
Наборы записей (recordset) ADO могут безопасно кэшироваться когда ADO отмечен как Free-threaded. Чтобы сделать ADO как Free-threaded используйте файл Makfre15.bat, который обычно зафиксирован в каталоге Program FilesCommon FilesSystemADO.
Предупреждение: ADO не должен быть Free-threaded, если вы используете Microsoft Access в качестве БД. Набор записей ADO должен быть также вообще отсоединен, если вы не можете управлять конфигурацией ADO на вашем веб-сайте.
Не кэшируйте соединение БД в объектах Application или Session
Кэширование соединений ADO — обычно плохая стратегия. Если один объект Connection сохранен в объекте Application и используется на всех страницах, то все страницы будут бороться за использование этого соединения. Если объект Connection сохранен в ASP-объекте Session, то соединение БД будет создано для каждого пользователя. Это создает излишнюю загрузку веб-сервера и БД.
Вместо кэширования соединений БД, создавайте и уничтожайте объекты ADO на каждой ASP странице, которая использует ADO. Это эффективно, потому что IIS имеет встроенное подключение БД. Более точно, IIS автоматически допускает объединение подключений OLEDB и ODBC. Это гарантирует, что создание и уничтожение связей на каждой странице будут эффективны.
Так как соединенные наборы хранят ссылки на подключение БД, это следует, что вы должны не кэшировать соединенные наборы в объектах Application или Session. Однако, вы можете безопасно кэшировать отсоединенные наборы, которые не держат ссылку на подключение. Чтобы отсоединить набор записей, сделайте следующие два шага:
Set rs = Server.CreateObject("ADODB.RecordSet") rs.CursorLocation = adUseClient " шаг 1 " Заполните recordset с данными rs.Open strQuery, strProv " Теперь отсоедините recordset от источника данных rs.ActiveConnection = Nothing " шаг 2
Подробную информацию относительно подключений смотрите в справочниках по ADO и SQL Server.
Разумное использование объекта Session
Теперь, когда в предыдущих советах были раскрыты достоинства кэширования данных в объектах Applications и Sessions, мы собираемся предложить вам избегать использования объекта Session. Сессии имеют несколько ловушек когда используются на загруженных сайтах. Под "загруженными" имеются ввиду сайты с сотнями запрашиваемых страниц в секунду или тысячами пользователей одновременно. Этот совет также важен для сайтов, которые должны масштабироваться горизонтально — т.е. те сайты, которые используют несколько серверов для распределения нагрузки и обеспечения отказоустойчивости при сбоях. Для меньших сайтов, типа intranet-сайтов, преимущества применения Sessions все же перевешивают.
Обобщая, ASP автоматически создает Session для каждого пользователя, который обращается к веб-серверу. Каждая сессия занимает приблизительно 10 Кб памяти (сверх любых данных, сохраненных в Session) и немного замедляет выполнение всех запросов. Сессия остается действующей до окончания таймаута (timeout), обычно 20 мин.
Но самая большая проблема при использовании сессий — это не производительность, а расширяемость. Сессии не охватывают все задействованные веб-сервера; как только Session была создана на одном сервере ее данные остаются там. Это означает, что если вы используете сессии на мультисерверном веб-сайте, вы должны придумать стратегию для обработки запросов каждого пользователя, которые должны быть всегда направлены на сервер, на котором существует сессия этого пользователя. Это называется "застреванием" пользователя на сервере (или "липкой сессией").
Объект Application также не охватывает все сервера: если вам нужно совместно использовать и обновлять данные Application через веб-сервера, вам нужно использовать конечную базу данных. Однако неизменяемые (read-only) данные Application все же полезны на мультисерверных сайтах.
Наиболее критичные к скорости сайты обычно используют не менее двух веб-серверов. Поэтому при проектировании вашего ASP-приложения вы должны либо использовать "липкие сессии", либо просто избегать применения объекта Session, также как любых других методов, сохраняющих информацию пользователя на разных веб-серверах.
Если же вы не используете Session, то убедитесь, что отключили их. Это можно сделать посредством Internet Services Manager (см. документацию по ISM). Но если вам все-таки необходимо использовать сессии, то есть несколько путей уменьшить их удары про производительности.
Вы можете переместить содержимое, которое не требует сессий (например, страницы help и т.д.) в отдельное ASP-приложение, у которого сессии выключены. Кроме того, на страницах, где объект Session не используется, применяйте следующую директиву, помещещаемую вверху страницы:
<% @EnableSessionState=False %>
Одна из основных причин ее применения — то, что Session создает интересную проблему в случае использования фрэймов (frameset). ASP гарантирует, что в любое время будет выполняться только один запрос от Session. Это делается для того, чтобы при одновременном запросе одним пользователем нескольких страниц, только один ASP-запрос был обработан сессией, что помогает избежать проблем многопоточного доступа к объекту Session. К сожалению, в результате этого все страницы в frameset будут загружаться последовательно, а не одновременно, и пользователю придется продолжительное время ждать полной загрузки. Мораль этой истории: если вы не уверены, что с использованием фрэймов и Session ваше приложение правильно работает, то используйте:
<% @EnableSessionState=False %>
Альтернативой использованию объекта Session являются многочисленные параметры управления Session. При передаче малых объемов данных (менее 4 Кб) обычно рекомендуется использовать Cookies, переменные QueryString и скрытые (hidden) переменные форм. При использовании большого количества передаваемых параметров (например, корзина произведенных заказов в он-лайн магазине) наиболее лучший выбор — конечная база данных.
Статья будет полезна как новичкам, так и профессионалам. Первые получат сведения об основных возможностях MySQL, без чтения документации. А уже имея представление о…
Sponsored By
A few years back Phil Haack wrote a great article on the dangers of recurring background tasks in ASP.NET . In it he points out a few gotchas that are SO common when folks try to do work in the background. Read it, but here"s a summary from his post.
- An unhandled exception in a thread not associated with a request will take down the process.
- If you run your site in a Web Farm, you could end up with multiple instances of your app that all attempt to run the same task at the same time.
- The AppDomain your site runs in can go down for a number of reasons and take down your background task with it.
If you think you can just write a background task yourself, it"s likely you"ll get it wrong. I"m not impugning your skills, I"m just saying it"s subtle . Plus, why should you have to?
There"s LOT of great ways for you to do things in the background and a lot of libraries and choices available.
Some ASP.NET apps will be hosted in IIS in your data center and others will be hosted in the Azure cloud. The spectrum of usage is roughly this, in my opinion:
- General: Hangfire (or similar similar open source libraries)
- used for writing background tasks in your ASP.NET website
- Cloud:
- A formal Azure feature used for offloading running of background tasks outside of your Website and scale the workload
- Advanced: Azure Worker Role in a Cloud Service
- scale the background processing workload independently of your Website and you need control over the machine
There"s lots of great articles and videos on how to use , and lots of documentation on how Worker Roles in scalable Azure Cloud Services work, but not a lot about how your hosted ASP.NET application and easily have a background service. Here"s a few.
WebBackgrounder
As it says "WebBackgrounder is a proof-of-concept of a web-farm friendly background task manager meant to just work with a vanilla ASP.NET web application." Its code hasn"t been touched in years, BUT the WebBackgrounder NuGet package has been downloaded almost a half-million times.
The goal of this project is to handle one task only, manage a recurring task on an interval in the background for a web app.
If your ASP.NET application just needs one background task to runs an a basic scheduled interval, than perhaps you just need the basics of WebBackgrounder.
Using System;
using System.Threading;
using System.Threading.Tasks;
namespace WebBackgrounder.DemoWeb
{
public class SampleJob: Job
{
public SampleJob(TimeSpan interval, TimeSpan timeout)
: base("Sample Job", interval, timeout)
{
}
Public override Task Execute()
{
return new Task(() => Thread.Sleep(3000));
}
}
}
Built in: QueueBackgroundWorkItem - Added in .NET 4.5.2
Somewhat in response to the need for WebBackgrounder, .NET 4.5.2 added QueueBackgroundWorkItem as a new API . It"s not just a "Task.Run," it tries to be more:
QBWI schedules a task which can run in the background, independent of any request. This differs from a normal ThreadPool work item in that ASP.NET automatically keeps track of how many work items registered through this API are currently running, and the ASP.NET runtime will try to delay AppDomain shutdown until these work items have finished executing.
It can try to delay an AppDomain for as long as 90 seconds in order to allow your task to complete. If you can"t finish in 90 seconds, then you"ll need a different (and more robust, meaning, out of process) technique.
The API is pretty straightforward, taking Func
Public ActionResult SendEmail( User user)
{
if (ModelState.IsValid)
{
HostingEnvironment.QueueBackgroundWorkItem(ct => SendMailAsync(user.Email));
return RedirectToAction("Index", "Home");
}
Return View(user);
}
FluentScheduler
FluentScheduler is a more sophisticated and complex scheduler that features a (you guessed it) fluent interface. You have really explicit control over when your tasks run.
Using FluentScheduler;
public class MyRegistry: Registry
{
public MyRegistry()
{
// Schedule an ITask to run at an interval
Schedule
// Schedule a simple task to run at a specific time
Schedule(() => Console.WriteLine("Timed Task - Will run every day at 9:15pm: " + DateTime.Now)).ToRunEvery(1).Days().At(21, 15);
// Schedule a more complex action to run immediately and on an monthly interval
Schedule(() =>
{
Console.WriteLine("Complex Action Task Starts: " + DateTime.Now);
Thread.Sleep(1000);
Console.WriteLine("Complex Action Task Ends: " + DateTime.Now);
}).ToRunNow().AndEvery(1).Months().OnTheFirst(DayOfWeek.Monday).At(3, 0);
}
}
FluentScheduler also embraces IoC and can easily plug into your favorite Dependency Injection tool of choice by just implementing their ITaskFactory interface.
Quartz.NET
Quartz.NET is a .NET port of the popular Java job scheduling framework of the (almost) same name. It"s very actively developed. Quartz has an IJob interface with just one method, Execute, to implement.
Using Quartz;
using Quartz.Impl;
using System;
namespace ScheduledTaskExample.ScheduledTasks
{
public class JobScheduler
{
public static void Start()
{
IScheduler scheduler = StdSchedulerFactory.GetDefaultScheduler();
scheduler.Start();
IJobDetail job = JobBuilder.Create
ITrigger trigger = TriggerBuilder.Create()
.WithDailyTimeIntervalSchedule
(s =>
s.WithIntervalInHours(24)
.OnEveryDay()
.StartingDailyAt(TimeOfDay.HourAndMinuteOfDay(0, 0))
.Build();
Scheduler.ScheduleJob(job, trigger);
}
}
}
Then, inside your Application_Start, you call JobScheduler.Start(). There"s a great getting started article on Quartz at Mikesdotnetting you should check out.
Hangfire
And last but definitely not least, the most polished (IMHO) of the group,
This tutorial attempts to shed some light on the subject of Threading using ASP.NET. Threading is a technique used to give the user the impression that multiple tasks are executing at the same time. The .NET Framework provides us with many types that allow us to easily and quickly add multi-threading to our .NET Web application. I’ll assume that you have some familiarity with ASP.NET and at least some experience with writing code in Visual Basic.
Through the tutorial we’ll build a pretty simple Web application that should be a good example of some basic threading concepts. Basically we’ll have 2 textboxes in which to enter a phrase, and to enter a time period in which you want the phrase to be rebuilt. Our Web threading application consists of 2 pages, one of which is the page that will start the thread, while the other is a results page that shows us the progress of our thread. The code provided should be very portable and allow you to implement your own threading application very quickly.
Before we get started…
Before we dive into the Web application, let me first give you a quick look at some of the code that you’ll be seeing.
First, we need to import the System.Threading Namespace so we can access the Thread class provided in the .NET Framework. Add this line to the top of your .aspx/.ascx file:
<%@ Import NameSpace="System.Threading" %>
Imports System.Threading
Now for demonstration purposes, here is a sample long running method. In a real life situation this method would most likely perform a task like processing a Web form, or completing a time-consuming database query.
Public Sub SomeLongMethod()
"your code that takes a while to execute
Now to execute this method and not leave our Web form hanging, we’ll start a new thread and let SomeLongMethod execute on this new thread. To do this, we have a few options. The technique I’ll use is to set up a new method that will start our new thread running. Here’s a sample thread starter function:
Public Sub SomeLongMethod_Thread()
"first, declare a new Thread, passing the constructor the address
"of SomeLongMethod. NOTE: SomeLongMethod can be replaced with your
"own method
Dim NewThread As Thread = New _
Thread(AddressOf SomeLongMethod)
"next we set the priority of our thread to lowest, setting
"the priority to a higher level can cause unexpected results.
NewThread.Priority = ThreadPriority.Lowest
"finally we start the thread executing
NewThread.Start()
And that’s it! All we have to do now is replace our call to SomeLongMethod with a call to SomeLongMethod_Thread , and the long method will execute on its own thread. Normally, we would redirect the user to the results page at the end of the SomeLongMethod_Thread method. However in this example I left that out to prevent confusion — I’ll demonstrate it in the following example, which illustrates the use of Threading in an ASP.NET Web application.
Using Threading to Rebuild a String
The first file we’ll look at is default.aspx. This will be the page where we’ll get 2 values from the user, and start a new thread. The second file we’ll look at is the results page, where we’ll poll the Session variables created in the thread, and display current thread stats to our user. I’ll go through default.aspx method-by-method, and then do the same for the results.aspx page. The source code for this file is available at the end of this tutorial.
NOTE: I’ve assumed that your Web server has Session variables enabled. If you have Session variables Disabled, or you have cookies disabled on your browser, the results of the following example will not display correctly.
A Simple Example (default.aspx)
Let’s begin by looking at the Page_Load function for default.aspx
Sub Page_Load(ByVal sender As System.Object, ByVal e
As System.EventArgs)
SyncLock Session.SyncRoot
"here, we initialize 3 session variables to hold our results
Session("Complete") = False
Session("Status") = ""
Session("Phrase") = ""
End SyncLock
d Sub
In this method we simply initialize 3 session variables that we’ll use in our next few methods. Session("Complete") will be the sentinel for our results page. When the thread is complete we will set Session("Complete") to True . The Session("Phrase") variable will be what we use to hold our partial phrase as we slowly build it. Session("Status") is just a variable to hold the start time and the end time. Now let’s look at our phrase re-building method:
Sub PhraseBuilder()Dim str As String = ""
Dim i As Integer = 0
Dim startTimeTicks As Long = 0
Dim strStartTime As String = ""
Dim totalSleepTime As Double = 0.0
"log our start time, in ticks, and in Long Date format
startTimeTicks = DateTime.Now.Ticks
strStartTime = "Thread Started: " & DateTime.Now
" get phrase
str = txtPhrase.Text
"convert users time from seconds to milliseconds
totalSleepTime = 1000.0
totalSleepTime = totalSleepTime * CInt(txtTotalThreadLife.Text)
totalSleepTime = (totalSleepTime / str.Length)
For i = 0 To str.Length - 1
"this method will put our thread to sleep for the specified
"number of milliseconds. without the sleep, this method would
"execute too fast to see the thread working.
Thread.Sleep(totalSleepTime)
"we use synclock to block any other thread from accessing
"session variables while we are changing their values.
SyncLock Session.SyncRoot
Session("Status") = "Thread is " & _
Format((i / (str.Length - 1)) * 100, "#0.00") & _
"% complete." & " - Time Elapsed: " & _
Format((DateTime.Now.Ticks - startTimeTicks) / 10000000 _
, "#0.00") & " sec. Target: " & txtTotalThreadLife.Text & _
".00 sec."
SyncLock Session.SyncRoot
"rebuild phrase 1 letter at a time
Session("Phrase") &= str.Chars(i).ToString
End SyncLock
"our method is complete, so set the Session variables
"accordingly
SyncLock Session.SyncRoot
Session("Status") = strStartTime & _
"
Thread Complete. End Time: " & DateTime.Now & "
"
Session("Complete") = True
End SyncLock
Ok, now let’s dissect this method a little. Basically what we’re doing here is forcing a method that would otherwise run quickly to run on a schedule based on user input. This is done using the Thread.Sleep(ByVal millisecond as Integer) method. This method allows us to put the thread to sleep for the specified number of milliseconds. This Sleep method can be used in any method, not just one that’s executing on a new thread.
The other interesting technique we utilize is the use of the Synclock method. Synclock is used to block other threads from trying to obtain the same Synclock . To protect the variables from simultaneous access, we need to obtain the same Synclock before we access the variables everywhere else in the code. This is a necessity in a multi-threaded Web application to ensure that two methods aren’t reading/writing to the same variable at the same time. The Synclock method is identical to using the Monitor.Enter(Me) method that’s also provided in the System.Threading Namespace .
There are only two methods left to go! The next method we’ll look at is the PhraseBuilder_Thread function. This function is almost identical to the example at the beginning of the article:
Sub PhraseBuilder_Thread()
"method to start our phrase builder method executing
"on a new thread.
Dim myThread As Thread = New Thread(AddressOf PhraseBuilder)
MyThread.Priority = ThreadPriority.Lowest
"//start the new thread
myThread.Start()
"now redirect to the results page
Response.Redirect("results.aspx")
Now all that’s left is to call our PhraseBuilder_Thread method when the user clicks the submit button. Here’s the short code:
Sub btnSubmit_Click(ByVal sender As System.Object, ByVal eAs System.EventArgs)
"start PhraseBuilder thread...
PhraseBuilder_Thread()
End Sub
A Simple Example(results.aspx)
Now we’ll take a look at the results page. Basically our results page will check the status of the Session("completed") variable on the Page_Load , and react accordingly. Here’s the Page_load function for results.aspx:
Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)
"Put user code to initialize the page here
"check the value of Session("Completed"), if it is True, stop writing
If Session("Complete") <> True Then
"make sure session variables are enabled, if not warn user
If Session("Complete") <> False Then
"error with session variable, Session("Complete") is not
"True or False
lblComplete.Text = "Error with Session("Complete")"
"set page to auto refresh page every 2 seconds, until thread is done
Response.Write("")
SyncLock Session.SyncRoot
lblStatus.Text = Session("Status") & "
Processing. . ."
End SyncLock
Else
"thread is complete, stop writing refresh tag, and display
"results
SyncLock Session.SyncRoot
lblStatus.Text = Session("Status")
lblPhrase.Text = Session("Phrase")
lblComplete.Text = Session("Complete")
End SyncLock
This Page_Load function checks the status of the Session("Complete") variable and reacts accordingly. Feel free to customize you results page to suit you needs, but I recommend checking for the case when the Session("Completed") variable is not set to True, or False. This usually happens when Session variables are disabled, or you have cookies disabled. Also, you can remove the Response.Write statement if you don’t want the page to automatically refresh.
In Conclusion
Well that’s all there is to it! Hopefully you have just written your first ASP.NET application using threading.
Последнее обновление: 10.03.2016
Одним из ключевых нововведений последних версий фреймворка.NET стала асинхронность. Хотя фреймворк и раньше позволял использовать асинхронные методы, но с появлением библиотеки Task Parallel Library работа с асинхронным кодом была предельно упрощена, а сам формат работы изменился. Были добавлены новые возможности по созданию асинхронных методов с использованием новых ключевых слов, таких как async и await.
При создании нового контроллера мы в настройках уже можем указать, как нам нужен контроллер - синхронный или асинхронный. По умолчанию Visual Studio добавляет в проект стандартные контроллеры, методы которых, как правило, возвращают объект ActionResult. Но если мы при добавлении контроллера в папку Controllers выберем тип MVC 5 Controller with views, using Entity Framework , то в окне настройки нового контроллера специальное поле позволит нам указать, что новый контроллер будет содержать асинхронные методы:
Для чего нужны вообще асинхронные методы в контроллерах? Асинхронные методы позволяют оптимизировать производительность приложения и предназначены прежде всего для обработки таких запросов, которые занимают или могут занять довольно продолжительное время, например, обращение к базе данных или обращение к внешнему сетевому ресурсу для получения большой порции данных. Применение асинхронных методов позволяет приложению параллельно с выполнением асинхронного кода выполнять также другие запросы.
Чтобы понять различие между синхронными и асинхронными методами, рассмотрим, как IIS обрабатывает входящие запросы. Веб-сервер поддерживает пул потоков, которые обслуживают запросы. При обращении пользователя к веб-ресурсу IIS выделяет поток из пула для обслуживания данного запроса. И пока данный поток не обработает предназначенный для него запрос, другие запросы он обрабатывать не может.
Однако предположим, что метод контроллера в процессе обработки запроса должен выполнить запрос к другому ресурсу или к базе данных. Запрос к сетевому ресурсу или БД сам по себе может занять некоторое время. При синхронной обработке поток, обрабатывающий запрос, временно блокируется, пока сетевой ресурс или БД не возвратят нужные нам данные.
И если обработка запроса блокируется очень долго, то IIS начинает задействовать для обслуживания других входящих запросов новые потоки. Однако есть ограничения на общее количество потоков. Когда количество потоков достигает предела, то вновь входящие запросы помещаются в очередь ожидания. Однако и тут есть ограничение на количество запросов в очереди. И когда это количество превышает предел, то IIS просто отклоняет все остальные запросы с помощью статусного кода 503 (Service Unavailable).
При асинхронной обработке поток не ждет, пока БД вернет ему данные, а начинает обрабатывать запрос от другого пользователя. Но когда, наконец, с сетевого ресурса или БД придут нужные данные, поток возвращается к обработке ранее обрабатываемого запроса в обычном режиме.
Перейдем непосредственно к коду. Для создания асинхронных методов используются модификаторы async и await , которые позволяют выполнять продолжительные операции без блокирования основного потока.
Сравним на примере вызов синхронного и асинхронного метода:
Using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using AsyncContollers.Models;
using System.Threading.Tasks;
using System.Data.Entity;
namespace AsyncContollers.Controllers
{
public class HomeController: Controller
{
BookContext db = new BookContext();
public ActionResult Index()
{
IEnumerable
Оба метода выполняют одну и ту же операцию - извлечение данных из БД и получают идентичные результаты. Но если первый синхронный метод Index представляет привычную для нас запись, то асинхронный метод BookList уже выглядит необычно.
Этот метод возвращает не объект ActionResult, а объект Task
Кроме того, чтобы обозначить метод как асинхронный, перед возвращаемым типом ставится ключевое слово async .
Третьим ключевым моментом является использование ключевого слова await . Оно применяется в асинхронных методах, чтобы приостановить выполнение этого метода до тех пор, пока ожидаемая задача не завершится. В нашем случае такой задачей является получение данных из БД.
Но также следует учитывать, что await используется с методами, возвращающими объект Task . Поэтому для получения данных из БД используется метод await db.Books.ToListAsync() , который также извлекает данные из БД, но уже в асинхронном режиме.
Когда следует использовать асинхронные методы? В первую очередь их предпочтительно использовать при запросах к БД, к внешнем сетевым ресурсам, однако в конечном счете, что лучше синхронность или асинхронность решает уже сам разработчик исходя из конкретной задачи.
A thread is defined as the execution path of a program. Each thread defines a unique flow of control. If your application involves complicated and time consuming operations such as database access or some intense I/O operations, then it is often helpful to set different execution paths or threads, with each thread performing a particular job.
Threads are lightweight processes. One common example of use of thread is implementation of concurrent programming by modern operating systems. Use of threads saves wastage of CPU cycle and increases efficiency of an application.
So far we compiled programs where a single thread runs as a single process which is the running instance of the application. However, this way the application can perform one job at a time. To make it execute multiple tasks at a time, it could be divided into smaller threads.
In .Net, the threading is handled through the "System.Threading" namespace. Creating a variable of the System.Threading.Thread type allows you to create a new thread to start working with. It allows you to create and access individual threads in a program.
Creating Thread
A thread is created by creating a Thread object, giving its constructor a ThreadStart reference.
ThreadStart childthreat = new ThreadStart(childthreadcall);
Thread Life Cycle
The life cycle of a thread starts when an object of the System.Threading.Thread class is created and ends when the thread is terminated or completes execution.
Following are the various states in the life cycle of a thread:
- Sleep method has been called
- Wait method has been called
- Blocked by I/O operations
The Dead State : It is the situation when the thread has completed execution or has been aborted.
The Unstarted State : It is the situation when the instance of the thread is created but the Start method is not called.
The Ready State : It is the situation when the thread is ready to execute and waiting CPU cycle.
The Not Runnable State : a thread is not runnable, when:
Thread Priority
The Priority property of the Thread class specifies the priority of one thread with respect to other. The .Net runtime selects the ready thread with the highest priority.
The priorities could be categorized as:
- Above normal
- Below normal
- Highest
- Lowest
- Normal
Once a thread is created, its priority is set using the Priority property of the thread class.
NewThread.Priority = ThreadPriority.Highest;
Thread Properties & Methods
The Thread class has the following important properties:
| Property | Description |
|---|---|
| CurrentContext | Gets the current context in which the thread is executing. |
| CurrentCulture | Gets or sets the culture for the current thread. |
| CurrentPrinciple | Gets or sets the thread"s current principal for role-based security. |
| CurrentThread | Gets the currently running thread. |
| CurrentUICulture | Gets or sets the current culture used by the Resource Manager to look up culture-specific resources at run time. |
| ExecutionContext | Gets an ExecutionContext object that contains information about the various contexts of the current thread. |
| IsAlive | Gets a value indicating the execution status of the current thread. |
| IsBackground | Gets or sets a value indicating whether or not a thread is a background thread. |
| IsThreadPoolThread | Gets a value indicating whether or not a thread belongs to the managed thread pool. |
| ManagedThreadId | Gets a unique identifier for the current managed thread. |
| Name | Gets or sets the name of the thread. |
| Priority | Gets or sets a value indicating the scheduling priority of a thread. |
| ThreadState | Gets a value containing the states of the current thread. |
The Thread class has the following important methods:
| Methods | Description |
|---|---|
| Abort | Raises a ThreadAbortException in the thread on which it is invoked, to begin the process of terminating the thread. Calling this method usually terminates the thread. |
| AllocateDataSlot | Allocates an unnamed data slot on all the threads. For better performance, use fields that are marked with the ThreadStaticAttribute attribute instead. |
| AllocateNamedDataSlot | Allocates a named data slot on all threads. For better performance, use fields that are marked with the ThreadStaticAttribute attribute instead. |
| BeginCriticalRegion | Notifies a host that execution is about to enter a region of code in which the effects of a thread abort or unhandled exception might endanger other tasks in the application domain. |
| BeginThreadAffinity | Notifies a host that managed code is about to execute instructions that depend on the identity of the current physical operating system thread. |
| EndCriticalRegion | Notifies a host that execution is about to enter a region of code in which the effects of a thread abort or unhandled exception are limited to the current task. |
| EndThreadAffinity | Notifies a host that managed code has finished executing instructions that depend on the identity of the current physical operating system thread. |
| FreeNamedDataSlot | Eliminates the association between a name and a slot, for all threads in the process. For better performance, use fields that are marked with the ThreadStaticAttribute attribute instead. |
| GetData | Retrieves the value from the specified slot on the current thread, within the current thread"s current domain. For better performance, use fields that are marked with the ThreadStaticAttribute attribute instead. |
| GetDomain | Returns the current domain in which the current thread is running. |
| GetDomainID | Returns a unique application domain identifier. |
| GetNamedDataSlot | Looks up a named data slot. For better performance, use fields that are marked with the ThreadStaticAttribute attribute instead. |
| Interrupt | Interrupts a thread that is in the WaitSleepJoin thread state. |
| Join | Blocks the calling thread until a thread terminates, while continuing to perform standard COM and SendMessage pumping. This method has different overloaded forms. |
| MemoryBarrier | Synchronizes memory access as follows: The processor executing the current thread cannot reorder instructions in such a way that memory accesses prior to the call to MemoryBarrier execute after memory accesses that follow the call to MemoryBarrier. |
| ResetAbort | Cancels an Abort requested for the current thread. |
| SetData | Sets the data in the specified slot on the currently running thread, for that thread"s current domain. For better performance, use fields marked with the ThreadStaticAttribute attribute instead. |
| Start | Starts a thread. |
| Sleep | Makes the thread pause for a period of time. |
| SpinWait | Causes a thread to wait the number of times defined by the iterations parameter. |
| VolatileRead() | Reads the value of a field. The value is the latest written by any processor in a computer, regardless of the number of processors or the state of processor cache. This method has different overloaded forms. |
| VolatileWrite() | Writes a value to a field immediately, so that the value is visible to all processors in the computer. This method has different overloaded forms. |
| Yield | Causes the calling thread to yield execution to another thread that is ready to run on the current processor. The operating system selects the thread to yield to. |
Example
The following example illustrates the uses of the Thread class. The page has a label control for displaying messages from the child thread. The messages from the main program are directly displayed using the Response.Write() method. Hence they appear on the top of the page.
The source file is as follows:
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="threaddemo._Default" %>
The code behind file is as follows:
Using System;
using System.Collections;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Threading;
namespace threaddemo
{
public partial class _Default: System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
ThreadStart childthreat = new ThreadStart(childthreadcall);
Response.Write("Child Thread Started
");
Thread child = new Thread(childthreat);
child.Start();
Response.Write("Main sleeping for 2 seconds.......
");
Thread.Sleep(2000);
Response.Write("
Main aborting child thread
");
child.Abort();
}
public void childthreadcall()
{
try{
lblmessage.Text = "
Child thread started
";
lblmessage.Text += "Child Thread: Coiunting to 10";
for(int i =0; i<10; i++)
{
Thread.Sleep(500);
lblmessage.Text += "
in Child thread ";
}
lblmessage.Text += "
child thread finished";
}catch(ThreadAbortException e){
lblmessage.Text += "
child thread - exception";
}finally{
lblmessage.Text += "
child thread - unable to catch the exception";
}
}
}
}
Observe the following
When the page is loaded, a new thread is started with the reference of the method childthreadcall(). The main thread activities are displayed directly on the web page.
The second thread runs and sends messages to the label control.
The main thread sleeps for 2000 ms, during which the child thread executes.
The child thread runs till it is aborted by the main thread. It raises the ThreadAbortException and is terminated.
Control returns to the main thread.
When executed the program sends the following messages.
