15. Настройка, оптимизация и развертывание приложения ASP.NET 2.0

Оптимизация производительности приложений ASP.NET 2.0, объект Cache, файлы web.config и machine.config, размертывание приложений ASP.NET 2.0

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

Одна из наиболее эффективных возможностей настройки производительности Web-приложения - использование объекта Cache. При помощи его вы можете размещать элементы Web-приложения в памяти, за счет чего доступ к ним будет производиться намного быстрее. Однако злоупотреблять этим не следует - если физическая оперативная память на сервере закончится, все Web-приложения будут работать намного медленнее.

Чаще всего объект Cache используется для хранения результатов вычислений, а также Web-страниц целиком и отдельных элементов управления. Не следует путь объект Cache  и output cache - это вещи совершенно разные. Объект Cache - это и не кэш вовсе, а просто механизм, который отслеживает ссылки на объекты в оперативной памяти и не дает им удаляться оттуда.

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

Применение объекта Cache выглядит так:

·        Web-страница запрашивает объект, на который помещена ссылка в объект Cache;

·        если этого объекта нет в физическом кэше, он туда помещается и возвращается оттуда клиенту;

·        после этого объект Cache не дает удалять этот объект из физического кэша. Все последующие запросы пользователей к нему будут удовлетворяться из физического кэша.

Объект Cache существует только один для каждого Web-приложения, поэтому настраивать его нужно для каждого Web-приложения отдельно. При перезапуске Web-приложения обнуляется информация и в объекте Cache.

Объект Cache можно использовать для хранения информации переменных уровня приложения (но не сеанса). Для хранения переменных уровня сеанса см. предыдущий модуль.

Ссылки на информацию в объект Cache помещаются при помощи привычных пар ключ/значение, например, так:

Cache("mykey") = myValue

Извлечь эту информацию можно так:

myValue = Cache("myKey")

В чем преимущества применения объекта Cache:

·        как и при любом кэшировании, главный выигрыш - в скорости. Из оперативной памяти объект "достается" намного быстрее, чем из файла или источника данных;

·        в объекте Cache реализовано автоматическое управление блокировками. Соответственно, проблем с одновременным изменением информации разными страницами или разными сеансами не будет;

·        замена старых элементов более новыми их версиями также производится автоматически средствами объекта Cache. Программным образом реализовывать этот механизм не нужно;

·        вместе с объектом Cache можно использовать callback-функции (то есть в Cache предусмотрена воя событийная модель). Например, можно определить, что при программном удалении какого-то объекта из Cache в него будет автоматически помещена ссылка на более свежую версию этого объекта;

·        Cache умеет отслеживать зависимости. Например, можно сделать так, что если один объект зависит от второго, и второй объект был удален из Cache, то автоматически из Cache будет удален и второй объект.

Как выглядит работа с объектом Cache? Как уже говорилось, при помещении информации используются пары ключ/значение. При этом можно просто помещать такую пару в Cache:

Cache("mykey") = myValue

а можно определить еще кучу необязательных параметров. Для этой цели используется метод Cache.Insert:

Cache.Insert("myKey", myValue, _

Dependency, AbsoluteExpiration, SlidingExpiration, _

CacheItemPriority, CacheItemRemovedCallBack)

Про необязательные параметры будет рассказано ниже.

Извлечение данных из Cache можно производить так (пример с проверкой значения):

myValue = Cache("mykey")

If myValue <> Nothing Then

DisplayData(myValue)

End If

Места в оперативной памяти все равно может не хватить, и в этом случае объект Cache будет использовать алгоритм LRU, удаляя из памяти те объекты, которые дольше всего не использовались. Однако на этот процесс можно повлиять при помощи необязательных параметров метода Cache.Insert. Эти необязательные параметры выглядят так:

·        первый параметр - AbsoluteExpiration. Это - значение DateTime, которое определяет, через сколько времени объект удалять из Cache. Например, чтобы определить время жизни в 5 минут, можно воспользоваться кодом:

Cache.Insert("myKey", myValue, Nothing, _

DateTime.Now.AddMinutes(5), Nothing)

·        второй параметр - SlidingExpiration. Он позволяет определить время жизни объекта в кэше с момента последнего к нему обращения. Ему передается объект TimeSpan::

Cache.Insert("myKey", myValue, Nothing, _

Nothing, TimeSpan.FromSeconds(20))

·        еще один параметр - Dependency. При помощи него можно определить, что при изменении/удалении какого-либо объекта другой объект (помещаемый в Cache), будет из Cache удален:

Cache.Insert("myKey", myValue, _

new CacheDependency(Server.MapPath("myDoc.xml")))

·        следующий параметр - приоритет. Если установить значение этого параметра в High, то объект будет сохраняться в Cache "до последнего":

Cache.Insert("myKey", myValue, Nothing, Nothing, _

Nothing, CacheItemPriority.High, onRemove)

·        последний параметр - callback function. Имя событийной процедуры, которая будет срабатывать при удалении этого объекта из кэша. Пример теперь - на все вместе:

Cache.Insert("MyBook.CurrentBook", CurrentBook, _

new CacheDependency(Server.MapPath("Books.xml")), _

DateTime.Now.AddMinutes(5), _

TimeSpan.FromSeconds(30), _

CacheItemPriority.High, onRemove)

Следующая тема посвящена работе с output caching, то есть физическим кэшированием.

В ASP.NET реализовано кэширование возвращаемых данных. Если Web-страница, элемент управления, код Web-службы уже в оперативной памяти (и он удовлетворяет запросу пользователя), то заново создаваться он не будет - вместо этого он вернется пользователю из кэша.

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

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

Кэширование поддерживают и Web-службы. Для каждого тега <WebMethod> можно указать атрибут CacheDuration - сколько времени сохранять в output cache то, что он вернул. Время указывается в секундах:

<WebMethod(CacheDuration:=300)> _

Public Function CachedInfo() As String

...

End Function

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

Для того, чтобы страница помещалась в output cache, необходимо на нее добавить директиву OutputCache. Для этой директивы предусмотрено два атрибута (оба - обязательные, если их не указать, то будет ошибка):

·        Duration - максимальное время хранения страницы в кэше в секундах. По умолчанию - 0 секунд (то есть страница не кэшируется);

·        VaryByParam - будет ли в кэше создаваться новая копия этой страницы, если она запрошена с другими параметрами. Обычно используется только два значения: "None" - кэшируется только одна версия страницы и "*" - кэшируются все версии страницы

Пример этой директивы:

<%@ OutputCache Duration="900" VaryByParam="None"%>

С указанием конкретного параметра:

<%@ OutputCache Duration="60" VaryByParam="productID"%>

Никаких других атрибутов для этой директивы не предусмотрено (все остальное игнорируется).

Теперь - о том, как кэшировать не всю страницу, а отдельные ее элементы.

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

Чтобы кэшировать отдельный элемент страницы (или группу элементов), вначале их нужно выделить на отдельную страницу в пользовательский элемент управления (см. модуль 8). А затем на странице пользовательского элемента управления нужно разместить ту же директиву OutputCache, например:

<%@ OutputCache Duration="120" VaryByParam="none"%>

Следующая тема - настройка Web-приложений.

Настройка параметров Web-приложений производится через XML-совместимые файлы конфигурации.

За конфигурацию всего Web-сервера отвечает файл machine.config. Настройки уровня Web-приложения и отдельных виртуальных каталогов хранятся в файлах web.config. В каждом Web-приложении (Web-сайте) обязательно есть по крайней мере один файл web.config.

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

Все содержимое файлов конфигурации помещается между корневыми тегами <configuration> и </configuration>.

Файл конфигурации Web-сервера находится по адресу

C:\WINDOWS\Microsoft .NET \Framework\version\CONFIG\Machine.config

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

Использовать настройки в machine.config нужно очень внимательно, поскольку при переносе Web-приложения на другой Web-сервер можно забыть перенести соответствующие настройки из machine.config.

Файл Web.config по умолчанию находится в корневом каталоге вашего Web-приложения.

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

Конфликты настроек, в случае их возникновения, решаются очень просто: кто ниже в иерархии, тот и победил. Главный приоритет, таким образом, у файлов web.config в подкаталогах Web-приложений.

Файлы web.config можно использовать не только для хранения информации о стандартных настройках Web-приложений, но и для хранения общей информации приложения. Например, вместо того, чтобы описывать connection string для подключения к базе данных на каждой странице Web-приложения, вполне можно указать один раз этот параметр в web.config и далее использовать этот параметр на любой странице. Для этой цели используется  раздел AppSettings в web.config. Выглядеть наш пример с помещением параметров (два подключения в базам данных) может так:

<configuration>

            <appSettings>

                        <add key="pubs"

                                   value="data source=localhost;

                                   initial catalog=pubs;

                                   integrated security=SSPI" />

                        <add key="northwind"

                                   value="data source=localhost;

                                   initial catalog=northwind;

                                   integrated security=SSPI" />

            </appSettings>

</configuration>

Получить значение этого параметра в приложении можно очень просто:

Dim strPubs As String = _

ConfigurationSettings.AppSettings("pubs")

Некоторые элементы управления (например, SqlConnection) позволяют хранить значения своих свойств в фале web.config. В некоторых ситуациях это очень удобно: например, мы позволяем администраторам, обслуживающим приложение, без необходимости обращаться к исходным файлам и перекомпилировать приложения, изменять имя сервера, на котором лежит нужная БД, Для того, чтобы произвести эти настройки, нужно открыть строку Dynamic Properties (самая верхняя в окне свойств) и привязать нужное свойство элемента управления к требуемому параметру в Web.config.

Теперь - о развертывании Web-приложения.

ASP.NET изначально задумывалось так, чтобы не нужно было возиться с реестром. Как правило, для развертывания приложения ASP.NET на рабочем сервере достаточно просто скопировать каталог Web-приложения (обычно - при помощи Windows Explorer, по FTP или утилитой командной строки XCOPY, которая позволяет копировать файлы с подкаталогами). Однако при этом необходимо сделать еще несколько действий:

·        на Web-сервере назначения создать нужный каталог в файловой системе и сделать его виртуальным каталогом Web-сервера;

·        перед копированием обязательно сделать Build вашему приложению (конечно, лучше в release);

·        определить, какие файлы вам скопировать не нужно. Обычно не нужно копировать:

o       файлы VS.NET *.vbproj, *.vbproj.webinfo, *.resx;

o       файлы исходного кода *.aspx.vb (если на форме не используется атрибут SRC).

Все остальное - нужно.

Чаще всего в Web-приложении ASP.NET используются файлы DLL двух разновидностей:

·        сборки вашего приложения (они лежат в каталоге Bin в вашем приложении);

·        общие стандартные сборки .NET (они поставляются вместе с .NET Framework).

Однако иногда возникает необходимость создать свою сборку, которая будет использоваться сразу множеством Web (и не обязательно Web) приложений. Такие сборки необходимо просто копировать в Global Assembly Cache - GAC.

При обновлении вашего Web-приложения ASP.NET позволяет перезаписывать все файлы и модули *.dll прямо во время его работы (даже если есть подключенные пользователи). Это - отличие ASP.NET от обычного ASP. Пользователи сразу переходят на использование новой версии приложения и перезапуска IIS не требуется. Правда, какое-то время старая информация может предоставляться пользователям из output cache.

Получить учебные материалы по этому курсу