Что такое код asp appcreate


Содержание

Использование Open >

Одним из преимуществ системы разрешений платформы ASP.NET >системы аутентификации на третьей стороне (Third-Party Authentication), через такие сервисы, как Google, Microsoft, Facebook, Twitter, ВКонтакте и т.д. Вы наверняка видели подобные системы аутентификации на многих сайтах, где не нужно проходить процесс регистрации, а достаточно войти в приложение через свой профиль в социальной сети.

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

В современных приложениях, такие системы аутентификации реализуются на основе протоколов OpenID и OAuth, описывающих взаимодействие приложения со сторонней системой. Ниже кратко описаны оба этих протокола и приведены схемы их работы:

OpenID

Этот протокол используется для аутентификации пользователей через другие интернет-ресурсы и проверяет, действительно ли пользователь тот — за кого себя выдает. На рисунке ниже приведена схема работы OpenID:

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

OAuth

Этот протокол используется для авторизации пользователей через другие интернет-ресурсы и, в отличие от OpenID, позволяет предоставить права на использование какого-то ресурса (например, загрузить аватарку пользователя, его email, поменять его стену Вконтакте или использовать другие API-интерфейсы, доступные у провайдера). На рисунке ниже показана схема работы OAuth:

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

Пример использования аутентификации Google

ASP.NET Identity имеет встроенную поддержку для работы с протоколами OpenID и OAuth для таких сервисов, как Google, Microsoft, Facebook и Twitter, а также содержит более обобщенную поддержку OAuth для интеграции с любыми другими сервисами. В этой статье в качестве примера мы рассмотрим аутентифкацию через учетную запись в социальной сети Google Plus.

Создание приложения в Google Developer

Для начала работы нам необходимо зайти в консоль разработчика Google и создать новый проект, который будет использоваться для авторизации пользователей:

После создания нового проекта вас перенаправит на его начальную страницу, где нужно будет перейти в пункт меню «Учетные данные», после чего перейти во вкладку «Окно запроса доступа Oauth». В этой вкладке указывается ваш email-адрес, название приложения и его логотип (эта информация будет отображаться пользователю при аутентификации на стороне Google).

Нажмите кнопку «Сохранить». Теперь перейдите в левом меню в раздел «Библиотека» и найдите Google+ API, перейдите в меню этого API:

В открывшемся окне необходимо щелкнуть по кнопке «Включить», как показано на рисунке ниже:

После этого отобразится следующее сообщение:

Вам необходимо нажать на кнопку «Создать учетные данные», для настройки доступа OAuth. После этого откроется окно добавления учетных данных, состоящее из трех этапов. На первом этапе указывается тип API (в проекте может использоваться несколько API) и контекст его использования. В нашем примере мы используем Google+ API и вызываем его из веб-браузера (JavaScript):

На втором этапе указываются ограничения по адресу сайта, из которого будет вызываться Google+ API:

Обратите внимание, что я указал ссылки на localhost:4989, в вашем приложении порт будет другим. Также, при развертывании приложения, необходимо будет добавить еще URL-адрес реального веб-сайта. На третьем этапе отобразиться сгенерированный ключ:

Этот ключ является открытым (ClientId). Когда вы нажмете на кнопку «Готово», браузер перенаправит вас на страницу идентификатора клиента в веб-приложении, где отображен также закрытый ключ (ClientSecret). Скопируйте куда-нибудь оба этих ключа, т.к. позже они нам понадобятся.

Настройки приложения

После того, как вы настроили проект OAuth на сайте Google Developer, можно приступить к интеграции сторонней системы аутентификации в своем приложении. Для начала необходимо установить пакет NuGet, добавляющий библиотеки для работы с аутентифкацей Google через Oauth, используя Identity. Выполните следующую команду в окне Package Manager Console:

Есть также еще несколько пакетов NuGet для работы с другими популярными социальными сетями. Они перечислены в таблице ниже:

Пакеты аутентификации NuGet

Проверяет подлинность пользователей через учетную запись Google

Аутентификация пользователей через аккаунт Facebook

Аутентификация пользователей через аккаунт Twitter

Аутентификация пользователей через аккаунт Microsoft

Аутентифкация через любые сервисы, поддерживающие OAuth 2.0

После установки пакета, необходимо включить поддержку аутентификации через стороннее приложение в классе запуска OWIN. Для этого отредактируйте файл IdentityConfig.cs в папке App_Start нашего приложения, как показано в примере ниже:

Каждый из пакетов, которые были перечислены в таблице выше, содержит расширяющий метод, который включает функциональность аутентификации через соответствующий сервис в OWIN. При аутентификации через Google используется метод UseGoogleAuthentication, которому передается объект GoogleOAuth2AuthenticationOptions. В свойствах этого объекта передаются параметры аутентификации. В частности в свойствах ClientId и ClientSecret указываются открытый и закрытый ключи приложения, которые мы сгенерировали ранее.

В свойстве AuthenticationType указывается уникальный идентификатор для экземпляра поставщика аутентификации. Этот идентификатор будет отображаться при запросе свойства Issuer класса утверждения Claim, который мы подробно рассмотрели в предыдущей статье. Благодаря этому параметру можно использовать несколько разных аутентификаций Google, например, используя разные проекты в Google Developer.

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

Теперь давайте добавим кнопку аутентификации через Google в представление Login.cshtml, находящееся в папке /Views/Account:

Новая кнопка отправляет данные формы методу действия GoogleLogin контроллера Account. Ниже я показал, какие изменения необходимо внести в этот контроллер:

Метод GoogleLogin создает экземпляр класса AuthenticationProperties и устанавливает свойство RedirectUri с адресом перенаправления, который вызывает метод действия GoogleLoginCallback в этом же контроллере. Следующая часть кода магическим образом вызывает ASP.NET Identity, чтобы перенаправлять пользователя на страницу аутентификации Google, а не ту, которая определена в приложении:

Это означает, что когда пользователь нажимает кнопку «Войти с помощью аккаунта Google», его браузер будет перенаправлен на страницу аутентификации Google, а затем обратно перенаправлен на страницу GoogleLoginCallback после того, как он пройдет проверку достоверности.

В методе действия GoogleLoginCallback мы получаем данные о пользователе от Google, используя метод GetExternalLoginInfoAsync, вызываемый на реализации интерфейса IAuthenticationManager:

Класс ExternalLoginInfo сожержит следующие свойства:

Пакет Описание
Microsoft.Owin.Security.Google
Microsoft.Owin.Security.Facebook
Microsoft.Owin.Security.Twitter
Microsoft.Owin.Security.MicrosoftAccount
Microsoft.Owin.Security.OAuth
Свойства класса ExternalLoginInfo

Возвращает имя пользователя

Возвращает адрес электронной почты пользователя

Возвращает объект ClaimsIdentity, связанный с идентификатором пользователям

Возвращает объект UserLoginInfo, который описывает данные при внешнем входе в приложением

Мы используем метод FindAsync класса управления пользователями, для поиска на основе свойства ExternalLoginInfo.Login. Этот метод возвращает объект AppUser, если пользователь ранее уже прошел проверку достоверности в приложении:

Если метод FindAsync не возвращает объект AppUser — это означает, что пользователь впервые аутентифицируется в приложении, поэтому мы создаем новый объект AppUser с данными, полученными от Google и сохраняем нового пользователя в базе данных.

Все что остается для аутентификации — добавить утверждения (claims), ассоциированные с данным пользователем и предоставляемые Google, а также создать аутентифицирующий файл cookie, позволяющий использовать учетные данные в приложении между сессиями:

Тестирование Google-аутентификации

Перед тестированием аутентификации через Google необходимо внести еще одно изменение в приложение: нам нужно отключить пользовательскую проверку пароля, которую мы включили в статье «Валидация данных». Для этого закомментируйте следующие строки в файле класса AppUserManager:

Проверку данных пользователя необходимо оставить, т.к. по умолчанию, в ASP.NET Identity в логине можно указывать только буквы английского алфавита. Напомню, ранее мы добавили класс CustomUserValidator, где отключили эту проверку:

Запустите приложение и нажмите кнопку «Войти с помощью аккаунта Google». Браузер откроет вам страницу Google, где необходимо ввести свои учетные данные:

Когда вы завершите процесс аутентификации, браузер перенаправит вас обратно в приложение. Если теперь открыть страницу с данными по утверждениям /Claims/Index, вы сможете увидеть, как утверждения из системы Google были добавлены к личности пользователя Identity:

Блог о технологиях .NET

16 мая 2011 г.

Кэширование в ASP.NET Часть 1. Введение

  1. Класс Cache – архитектура и свойства;
  2. Работа с объектом Cache;
  3. Настройка зависимостей в объекте Cache;

  4. Зависимости от данных XML;
  5. Зависимости от базы данных SQL Server.

Get – возвращает запись из кэша, хранящуюся с указанным ключом. Если такая запись не найдена метод возвращает null;

GetEnumerator – возвращает объект-перечислитель, позволяющий перемещаться по всем элементам коллекции;

Что такое код asp appcreate

Данные советы вводят в проблему повышения производительности работы приложений, использующих технологии Microsoft Active Server Pages (ASP) и Visual Basic Scripting Edition (VBScript). Большинство из них были многократно обсуждены и c успехом проверены на практике и будут интересны как новичкам в программировании ASP и VBScript, так и тем, кто уже имеет опыт работы с этими технологиями. При подготовке советов был использованы материалы c веб-сайта корпорации Microsoft Corp. (http://www.microsoft.com) и материалы конференций Relib.com (http://www.relib.com)

Совет 1: Кэшируйте часто используемые данные на сервере

Типичная ASP-страница получает данные из базы данных и затем выводит их в формате HTML. Независимо от скорости работы вашей базы данных, получение данных из памяти сервера будет намного быстрее, чем обработка sql-запроса к конечной базе данных. Получение данных, сохраненных на локальном жестком диске сервера, также обычно быстрее, чем получение информации из БД. Поэтому одним из основных путей увеличения скорости работы вашей ASP-страницы является кэширование часто используемой информации в памяти или на жестком диске.

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

Данные, которые изменяются не часто, будут хорошим кандидатом для кэширования, потому что вам не надо будет волноваться относительно их синхронизации через какое-то время с конечной базой данных. Выпадающие списки (сombo-box), таблицы ссылок, пункты меню, и переменные конфигурации сайта (включая имена DSN, адреса IP и URL) — первые кандидаты для хранения в кэше. Заметьте, что вы можете кэшировать представление данных много быстрее, нежели данные сами себя. Если ASP-страница изменяется не так часто и ее временный кэш будет весьма внушительным (например, полный каталог изделий фирмы), попробуйте использовать сгенерированные HTML-страницы, чем каждый раз загружать сервер генерацией ASP-страниц.

Совет 2: Кэшируйте часто используемые данные в объектах Application или Session

Объекты Application и Session служат для хранения данных в памяти, значения которых могут быть доступны между несколькими HTTP-запросами (в отличие от обычных переменных, чьи значения доступны только в теле одной ASP-страницы). Данные объекта Session доступны только одному пользователю (в течении его сессии), в то время как данные Application доступны всем пользователям веб-сайта. Поэтому часто перед разработчиком возникает вопрос: в каком из объектов сохранять часто используемые данные. Обычно, для инициализации переменных этих объектов используются процедуры файла Global.asa — Application_OnStart() или Session_OnStart() соответственно. Если в вашем Global.asa еще нет этих процедур, то вы можете добавить их сами или инициализировать переменные, когда это будет необходимо. Примером может быть следующая процедура, использующая Application для хранения значений многократно использующейся переменной EmploymentStatusList. Процедура проверяет существование данных в EmploymentStatusList и при необходимости расчитывает их заново:

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

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

Совет 3: Кэшируйте данные на диске веб-сервера

Иногда в памяти вашего веб-сервера может быть слишком большое количество данных. «Слишком много», конечно, является спорным вопросом — это зависит от того, сколько памяти вы хотите использовать, а также число элементов для кэширования и частота, с которой эти элементы будут запрашиваться. В любом случае, если вы имеете слишком большое количество данных для кэширования в памяти, подумайте о переносе кэша в текстовый или 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. Например, на начальной странице веб-сайта Relib.com (http://www.relib.com/index.asp) приводятся 2 списка последних тем обсуждения двух дискуссионных форумов этого сайта. Отобразить эти списки можно при помощи создания двух наборов записей ADO при каждом обращении к данной странице или, следуя данному совету, сохранить их однажды в виде HTML-файла list.inc, а затем включать в index.asp:

Второй путь работает значительно быстрее.

Совет 4: Избегайте кэшировать медленные компоненты в объектах 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. Вы можете обойти это, используя в Global.asa, но это также не рекомендуется, поскольку это ведет к проблемам (очереди и сериализация), объясняемым ниже.

Что же все-таки неправильно если вы кэшируете непроворные компоненты? Непроворный компонент, кэшируемый в объекте 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 Files\Common Files\System\ADO.

Предупреждение: ADO не должен быть Free-threaded, если вы используете Microsoft Access в качестве БД. Набор записей ADO должен быть также вообще отсоединен, если вы не можете управлять конфигурацией ADO на вашем веб-сайте.

Совет 5: Не кэшируйте соединение БД в объектах Application или Session

Кэширование соединений ADO — обычно является плохой стратегией при разработке ASP-сайта. Если один объект Connection сохранен в объекте Application и используется на всех страницах, то все страницы будут бороться за использование этого соединения. Если объект Connection сохранен в ASP-объекте Session, то соединение БД будет создано для каждого пользователя. Это создает излишнюю загрузку веб-сервера и БД.

Вместо кэширования соединений БД, создавайте и уничтожайте объекты ADO на каждой ASP странице, которая использует ADO. Это эффективно, потому что IIS имеет встроенное подключение БД. Более точно, IIS автоматически допускает объединение подключений OLEDB и ODBC. Это гарантирует, что создание и уничтожение связей на каждой странице будут эффективны.

Так как соединенные наборы хранят ссылки на подключение БД, это следует, что вы должны не кэшировать соединенные наборы в объектах Application или Session. Однако, вы можете безопасно кэшировать отсоединенные наборы, которые не держат ссылку на подключение. Чтобы отсоединить набор записей, сделайте следующие два шага:

Совет 6: Разумное использование объекта 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 не используется, применяйте следующую директиву, помещещаемую вверху страницы:

Одна из основных причин ее применения — то, что Session создает интересную проблему в случае использования фрэймов (frameset). ASP гарантирует, что в любое время будет выполняться только один запрос от Session. Это делается для того, чтобы при одновременном запросе одним пользователем нескольких страниц, только один ASP-запрос был обработан сессией, что помогает избежать проблем многопоточного доступа к объекту Session. К сожалению, в результате этого все страницы в frameset будут загружаться последовательно, а не одновременно, и пользователю придется продолжительное время ждать полной загрузки. Мораль этой истории: если вы не уверены, что с использованием фрэймов и Session ваше приложение правильно работает, то используйте:

Альтернативой использованию объекта Session являются многочисленные параметры управления Session. При передаче малых объемов данных (менее 4 Кб) обычно рекомендуется использовать Cookies, переменные QueryString и скрытые (h >Если в вашем приложении используется много функций VBScript или JScript, то зачастую производительность можно улучшить поместив этот код в откомпилированный COM-объект. Обычно откомпилированная программа выполняется значительно быстрее, чем интерпретируемый код, поэтому откомпилированные COM-объекты будут работать более эффективно, чем вызываемые методы скрипта.

Выделение (инкапсуляция) кода в COM-объект имеет следующие преимущества (не считая производительности):

  • COM-объекты хороши для логического представления структуры приложения.
  • COM-объекты позволяют многократное использование одного кода.
  • Много разработчиков находят код, написанный в VB, C++ или Visual J++ проще в отладке, чем ASP.

Но наряду с, казалось бы, неоспоримыми достоинствами COM-объекты имеют и недостатки, среди которых — время разработки и потребность в различных навыках программирования. Будьте уверены, что инкапсуляция в малых ASP-приложениях может вызвать скорее убытки, чем прибыль. Обычно это случается, когда маленькое количество ASP-кода переносится в объект COM. В этом случае накладные расходы от создания и вызова этого объекта перевешивают выгоду от использования интерпретируемой программы. Определить наиболее выигрышную комбинацию для производительности — использование сценариев ASP или COM-объектов — можно только методом проб и ошибок. Заметим, что Microsoft значительно улучшила ASP-сценарии и производительность ADO в Windows 2000/IIS 5.0 по сравнению с Windows NT 4.0/IIS 4.0. Таким образом, преимущество откомпилированного кода над кодом ASP уменьшилось с введением IIS 5.0 и ваше приложение должно работать быстрее, по сравнению с четвертой версией IIS.

Совет 8: Объявляйте переменные поздно, а удаляйте рано

Данный совет небольшой, но не менее важный в оптимизации ASP, чем все предыдущие. Суть его в следующем: лучше всего объявлять переменные только по мере необходимости и сразу удалять их, как только они становятся ненужными. Это относится и к COM-объектам и к указателям открываемых файлов и другим используемым ресурсам.

Соединения (Connection) ADO и рекордсеты — первостепенные кандидаты для этой оптимизации. Использовав recordset или сonnection для отображения данных сразу же удаляйте эти переменные из памяти, не дожидаясь конца страницы. Не позволяйте рекордсету или соединению остаться незакрытыми.

Например, если вы создаете соединение и открываете набор записей следующим образом:

то закройте их вот так:

Любые другие переменные Microsoft VBScript также лучше устанавливать в Nothing.

Совет 9: Out-of-process как компромисс между производительностью и надежностью

И ASP и MTS/COM+ имеют параметры конфигурации, которые позволяют вам выбрать альтернативу между надежностью и производительностью. Вы должны сделать разумный выбор при разработке ваших ASP-приложений.

Работа ASP-приложений может быть сконфигурирована одним из трех путей. В IIS 5.0 введен термин «уровень изоляции» (isolation level), описывающий эти пути, и который делится на три уровня — Low (низкий), Medium (средний), и High (высокий):

Low Isolation. Поддерживается во всех версиях IIS и самый быстрый. Он выполняет ASP в Inetinfo.exe, который является первичным процессом IIS. Если ASP-приложение дает сбой, то нагрузка ложится на IIS. (Чтобы перезапутить IIS под IIS 4.0 вебмастер должен был вести мониторинг сайта, используя инструменты типа InetMon, и рестартовать его командным файлом, если на сервере произошел сбой. В IIS 5.0 введена более надежная функция рестарта, которая автоматически перезапускает сервер в случае сбоя.)

Medium Isolation. Этот новый уровень, впервые введенный в IIS 5.0, называют out-of-process, т.к. ASP выполняется вне процесса IIS. В Medium Isolation все приложения ASP сконфигурированы для выполнения как среднеразделенный процесс. Это уменьшает число процессов, требуемых для загрузки нескольких ASP-приложений out-of-process. В IIS 5.0 уровень Medium Isolation установлен по-умолчанию.

High Isolation. Поддерживающийся в IIS 4.0 и IIS 5.0 уровень High Isolation также выполняется out-of-process. Если в ASP произошел сбой, то с веб-сервером ничего не случится — ASP-приложение автоматически перезапускается со следующим запросом ASP. В High Isolation, каждое ASP-приложение сконфигурировано для выполнения в собственном участке памяти, что защищает приложения ASP от друг друга (отсюда и название — «высокая изоляция»). Недостаток этого — требование раздельных процессов для каждого ASP-приложения.


Вы спросите, который уровнь лучше? В IIS 4.0 выполнение out-of-process сказывалось довольно негативно на производительности. В IIS 5.0 было проделано много работы для уменьшения последствий от запущенных out-of-process ASP-приложений. Фактически в большинстве испытаний ASP-приложения, запущенные out-of-process под IIS 5.0, выполняются быстрее, чем под IIS 4.0. Независимо от этого, Low Isolation все еще предоставляет лучшую производительность на обеих платформах. Однако, вы не увидите большой выгоды от Low Isolation, если ваш веб-сервер имеет низкую нагрузку. Поэтому, вам не стоит устанавливать этот уровень, до тех пор, пока ваш сервер не будет выполнять запросы в сотни или даже тысячи страниц в секунду. Как всегда, испытание с различными конфигурациями и определяет наиболее лучший выбор.

Заметим, что когда вы выполняете ASP-приложения out-of-process (уровни Medium или High), они выполняются в MTS под NT4 и COM+ под Windows 2000. Т.е. под NT4 они выполняются в Mtx.exe, а под Windows 2000 они выполняются в DllHost.exe. Вы можете увидеть эти процессы запустив Администратор Задач (Task Manager). Вы можете также увидеть как IIS компонует пакеты MTS или приложения COM+ для out-of-process приложений ASP.

Компоненты COM также имеют три параметра конфигурации, хотя они и не полностью аналогичны параметрам настройки ASP. Компоненты COM могут быть: «неконфигурированными» (unconfigured), настроенными как библиотечные или серверные приложения. «Неконфигурированные» — т.е. компонент не зарегистрирован с COM+. Такой компонент будет выполниться в памяти вызывающего процесса, т.е. «in-process» («в процессе»). Библиотечные приложения (Library Applications) также выполняются in-process, но имеют выгоду от сервисов COM+, включая защиту, транзакции и контекстную поддержку. Серверные приложения выполняются в собственной памяти процесса.

Вы сможете увидеть весьма небольшую выгоду неконфигурированных компонентов над библиотечными приложениями. И, вероятно, большую производительность библиотечных приложений над серверными. Это все потому, что библиотечные приложения выполняются в том же самом процессе, что и ASP, в то время как серверные приложения выполняются в их собственном процессе — межпроцессорные запросы более трудоемки, чем работа в in-process (например, при обмене данными recordset между процессами, все данные должны быть скопированы из одного процесса в другой).

Так что же все-таки использовать?

Если вам требуются конфигурации с разумными долями реализации производительности и надежности, то советуем вам следующее: под IIS 4.0 используйте Low Isolation level и MTS Server Packages, под IIS 5.0 используйте Medium Isolation level и COM+ Library Applications. Но учтите, что данный совет — очень общая рекомендация. Например, хостинговые компании обычно устанавливают Medium или High Isolation level, тогда как множество веб-серверов могут работать в Low Isolation. Так что, лучше всего попробовать самому и решить, которая конфигурация непосредственно для вас наилучшим образом выполняет ваши потребности.

Совет 10: Используйте директиву Option Explicit

Используйте директиву Option Explicit в ваших .asp файлах. Расположенная в самом верху .asp файла, она заставляет разработчика объявлять все переменные, которые он использует. Многие программисты считают, что это позволяет быстрее отлаживать приложения, исключая, таким образом, ошибки в написании имен переменных и невнимательное создание новых переменных (например, MyXLMString=. вместо MyXMLString=).

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

Таким образом, использование директивы Option Explicit гарантирует, что все используемые переменные объявлены и доступ к ним будет максимально быстрым.

Совет 11: Используйте локальные переменные в подпрограммах и функциях

Локальные переменные — это переменные, которые объявлены внутри подпрограмм и функций. Доступ к локальной переменной в пределах функции или подпрограммы значительно быстрее, чем доступ к такой же глобальной переменной. Также использование локальных переменных делает ваш код «чище» и понятнее, поэтому используйте их, когда Вы можете.

Совет 12: Копируйте частоиспользуемые данные в переменные

При вызове COM в ASP, вы должны копировать частоиспользуемые данные объекта в переменные ASP-скрипта. Это сократит количество запросов методов COM, которые являются относительно трудоемкими по сравнению с обращением к переменным самого скрипта. При вызове объектов Collection и Dictionary этот совет также сокращает время запросов.

Вообще, если вы пользуетесь объектом данных больше, чем однажды, поместите данные в переменную ASP-скрипта. Главной целью этой оптимизации являются переменные объекта Request (Form и QueryString). Например, на вашем веб-сайте через QueryString передается переменная UserID. Предположите, что этот UserID упомянут дюжину раз на каждой странице. Вместо вызова Request(«UserID») 12 раз, поместите этот UserID в какую-либо переменную наверху ASP страницы и затем используйте эту переменную (а не Request) внутри страницы. Это упразднит 11 COM-запросов!

На практике, доступ к свойствам или методам COM может быть обманчиво дорог. Посмотрите пример, показывающий некоторый обычный код:

Когда этот код выполняется, происходит следущее:

  1. Переменная Foo получена как глобальный объект.
  2. Переменная bar получена как член Foo. Это оказывается запросом COM-метода.
  3. Переменная blah получена как член Foo.bar. Это также оказывается запросом COM-метода.
  4. Переменная qaz получена как член foo.bar.blah. Да, это также оказывается запросом COM-метода.
  5. Вызовите Foo.bar.blah.quaz(1). Еще один запрос COM-метода. Представляете?
  6. Сделайте шаги от 1 до 3 снова, чтобы получить baz. Система не знает, изменил запрос к qaz модель объекта, так что шаги 1 до 3 должны быть выполнены снова, чтобы получить baz.
  7. Получите baz как член Foo.bar.blah.
  8. Сделайте шаги от 1 до 3 снова и получите zaq.
  9. Сделайте шаги от 1 до 3 уже в другой раз и получите abc.

Как видите это ужасно неэффективно (и медленно). Быстрый способ — написать этот код в VBScript: ,pre> Set myobj = Foo.bar.blah ‘Объявляем blah однажды! Myobj.baz = myobj.qaz(1) If Myobj.zaq = Myobj.abc Then ‘.

Если вы используете VBScript 5.0, то можете использовать выражение With:

Совет 13: Избегайте использования переопределяемых массивов

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

Пример ниже показывает использование беспричинного использования Dim и Redim.

Есть ли в этом смысл? Гораздо было бы лучше использовать для инициализации массива изначально известный размер (в этом случае 5), чем каждый раз переопределять его. Определяя массив сразу вы будете тратить впустую небольшое количество памяти (если не все элементы массива используются), но выгодой будет скорость работы вашего скрипта.

Совет 14: Используйте буферизацию Response

Вы можете буферизировать целую страницу, включив «response buffering». Это минимизирует количество записей в браузер и, таким образом, улучшит производительность. Каждая запись имеет много непроизводительных издержек (и в самом IIS и в том количестве данных, посланных по проводам), так что меньшее количество записей будет лучше. TCP/IP работает намного более эффективно когда возможно посылать несколько больших блоков данных, чем при пересылке многочисленных маленьких блоков (из-за медленного начала процесса пересылки и сложных алгоритмов проверки).

Есть два пути использования «response buffering». Первый путь — вы можете включить response buffering для приложения, взятого в целом, используя Internet Services Manager. Это рекомендуемый подход, поэтому response buffering включен по-умолчанию для новых ASP-приложений в IIS 4.0 и IIS 5.0. Второй путь — вы можете активировать буферизацию, поместив следующую линию кода вверху ASP-страницы:

Эта линия кода должна быть выполнена прежде, чем любые данные response был записаны в браузер (т.е. прежде, чем появится любой код HTML в ASP-скрипте и прежде, чем были установлены любые Cookies, используя Response.Cookies). Вообще, лучше включить response buffering, как указано в первом случае. Это позволит вам избежать применения вышеупомянутой линии кода в каждой странице.

Есть только одна общая проблема относительно буферизации Response — то, что пользователи чувствуют ASP-страницы менее «отзывчивыми» (даже при том, что время полного получения готовой страницы получается меньше) потому что они должны ждать полную страницу, которая будет произведена прежде, чем, они начинают видеть что-нибудь. Для длинных страниц, вы можете выключить буферизацию, установив Response.Buffer = False. Однако, лучшей стратегией будет использование метода Response.Flush. Этот метод показывает весь HTML, который был записан ASP в браузер. Например, после записи 100 строк из таблицы с 1000-ю записей, ASP может вызывать Response.Flush, чтобы вынудить показать браузер уже готовые 100 строк; это позволяет пользователю увидеть первые 100 строк таблицы прежде, чем остальные строки будут будут получены.

(Заметьте, что в вышеупомянутом примере таблицы с тысячью записей некоторые браузеры не будут отображать таблицу, пока они не получат заключительный HTML-тег

Свойство Описание
DefaultUserName
ExternalIdentity

. Так что проверьте ваш браузер на этот счет. Чтобы обойти эту проблему, попробуйте разделить таблицу на несколько более меньших таблиц (с меньшим количеством строк) и вызывать Response.Flush после каждой из них. Новые версии Internet Explorer отображают таблицы прежде, чем они полностью закончены и будут показывать их еще быстрее, если вы определите ширину столбцов таблицы — это поможет избежать расчетов, которые требуются браузеру для самостоятельного вычисления ширины столбцов путем измерения длины строк данных в каждой ячейке таблицы.

Другая обычная проблема с буферизацией Response — то, что она может использовать много серверной памяти при генерации очень больших страниц. Если вам необходимо генерировать такие страницы, то совет будет тем же — попробуйте сочетать буферизацию и Response.Flush.

Совет 15: Группируйте однолинейный код и выражения Response.Write

Однолинейная конструкция VBScript записывает значение «выражения» в исходящий ASP-поток. Если буферизация response не включена (см. Совет 14), то при частом использовании таких выражений, каждое из них приведет к записи данных в браузер путем передачи по сети множества маленьких пакетов, что выполняется медленно. Точно также производительность приложения снижается при частом чередовании маленьких кусочков ASP-кода и HTML. Поэтому данный совет состоит в следующем: замените рядом стоящие однолинейные конструкции одним вызовом Response.Write. Например, в следующем примере отображения таблицы БД показано необоснованно частое переключение в каждой строке между однолинейным кодом VBScript и тэгами HTML:

Ниже приводится более эффективный код, содержащийся в едином блоке VBScript и призванный ускорить отображение данных:

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

Совет 16: Используйте Response.IsClientConnected перед получением больших объемов данных

Если пользователь нетерпелив и торопится, он может отказаться от вашей просмотра ASP-страницы прежде, чем вы начнете выполнять его запрос. Если он нажал в браузере Refresh или ушел на другую страницу вашего сервера, вы получите новый запрос, стоящий в конце очереди ASP-запросов и «отсоединенный» запрос, стоящий в середине очереди. Часто это случается когда ваш сервер сильно загружен (имеет длинную очередь запросов с, соответственно, большим временем ответа) и этот новый запрос делает ситуацию еще хуже. Нет никакого смысла выполнять ASP-скрипт (особенно медленный и тяжеловесный), если пользователь больше не соединен со своим запросом. Вы можете проверить это состояние, используя свойство Response.IsClientConnected. Если оно возвращает False вы должны вызвать Response.End и отказаться от получения остальной части страницы. Фактически, IIS 5.0 использует эту практику — всякий раз, когда ASP собирается выполнять новый запрос, он проверяет, чтобы увидеть как долго запрос был в очереди. Если он был там более, чем 3 секунд, ASP проверит, соединен ли все еще клиент и немедленно закончит запрос, если нет. Вы можете использовать AspQueueConnectionTestTime, чтобы установить этот таймаут в 3 секунды.

Если вы имеете страницу, которая требует очень много времени для выполнения, вы можете проверять Response.IsClientConnected на разных стадиях выполнения. Когда буферизация активирована — хорошая идея также вызывать Response.Flush, чтобы дать понять пользователю, что что-что работает.

Обратите внимание, что в IIS 4.0 Response.IsClientConnected не будет правильно работать, если вы сначала не делаете Response.Write. Если буферизация активирована вы будете также должны делать Response.Flush. На IIS 5.0 нет никакой потребности в этом — Response.IsClientConnected работает прекрасно. В любом случае Response.IsClientConnected требует некоторых затрат времени, поэтому используйте ее только перед действием, которое требует, скажем, по крайней мере, не менее 500 миллисекунд (это большой промежуток времени, если у вас большая нагрузка на сервер). Т.е. вы должны отдавать себе отчет в действиях и не вызывать Response.IsClientConnected перед выводом каждой строки таблицы БД, гораздо лучше будет, если такая проверка будет реже, возможно, перед выводом новых 20-ти или 50-ти строк.

Совет 17: Объявляйте объекты используя тег

Если вам нужно обращаться к объектам, которые затем могут быть не использованы в коде (особенно объекты, содержащиеся в объектах Server или Application), попробуйте объявлять их в global.asa используя следующий синтакс:

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

Совет 18: Используйте объявления TypeLib для ADO и других компонентов

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

В IIS 5.0 введена способность связать с библиотекой типов компонента, которая позволяет вам один раз сослаться на библиотеку типов и использовать ее на каждой ASP-странице. Причем в каждой странице не надо будет компилировать файл констант и разработчикам компонентов не надо формировать файлы VBScript #include для использования в ASP.

Чтобы обращаться к ADO TypeLib разместите одно из следующих выражений в Global.asa:

Совет 19: Пользуйтесь преимуществами клиентской проверки правильности данных

Современные браузеры имеют широко развитую поддержку XML, DHTML, java-апплетов и Remote Data Service. Пользуйтесь преимуществами этих возможностей всякий раз, когда можете. Все эти технологии помогают сократить на запросах к серверу и обратно, выполняя клиентскую проверку правильности ввода данных (например, проверку, имеет ли кредитная карта правильную контрольную сумму и т.п.). Сократив на обращениях клиент-сервер, вы снимите дополнительную нагрузку с сервера, тем самым — сократите сетевой траффик (хотя начальная страница, посланная браузеру, скорее всего будет большей), а также снизите нагрузку с любых других конечных ресурсов, к которым обращается ваш север (базы данных и пр.). Кроме того, пользователю не надо будет ждать новую страницу с сообщением об ошибке и предложением вернуться назад. Однако все это не означает, что вам надо просто перенести всю вашу проверку с сервера на клиента, нет. Вы должны всегда делать проверку вводимых данных на сервере, потому что она поможет защитить против хакеров или браузеров, которые не поддерживают ваши клиентские процедуры проверки.

Много было сделано для создания HTML, «независимого от браузера». Это часто препятствует разработчику при извлечении выгоды от популярных особенностей браузеров, которые могли бы приносить пользу. Для высокопроизводительных веб-сайтов, которые беспокоятся о «досягаемости» для браузеров, хорошей стратегией будет оптимизация страниц под наиболее популярные программы просмотра. Особенности браузера могут быть легко обнаружены в ASP используя Browser Capabilities Component («компонент возможностей браузера»). Инструментальные средства типа Microsoft FrontPage могут помочь вам при проектировании кода, который будет работать с теми браузерами и версиями HTML, которые вы хотите.

Совет 20: Избегайте конкатенации строк в циклах

Множество программистов делают образование строк в циклах следующим образом:

В таком подходе есть несколько проблем. Во-первых, неоднократная конкатенация (соединение) строк берет квадратичное время или если сказать менее формально, то — время, которое потребуется на выполнение цикла, пропорционально квадрату количества записей к числу полей. Более простой пример сделает это более понятным.

На первом шаге цикла вы получаете одиносимвольную строку «A». Во второй раз VBScript должен перераспределить строку и скопировать два символа («AB») в s. На третьем шаге нужно перераспределить s снова и скопировать три символа в s. На шаге N (26), нужно перераспределить и скопировать N символов в s. Итого — общее количество 1+2+3+. +N, т.е. N*(N+1)/2 копирований.

Если предположить, что в первом примере было 100 записей и 5 полей, то внутренний цикл будут выполнен 100*5 = 500 раз и время, которое потребуется для копирования и перераспределения строк будет пропорционально 500*500 = 250000, что будет довольно много для копирования набора записей скромных размеров.

В этом примере код мог бы быть улучшен заменой конкатенации строк с Response.Write() или однолинейным скриптом ( ). Если буферизация response включена (как это должно быть), это будет быстро, как Response.Write только добавляет данные к концу буфера response. Никакое перераспределение не выполняется и это очень эффективно.

В отдельных случаях преобразования ADO-рекордсета в HTML-таблицу можно попробовать использование GetRows или GetString.

Если вы соединяете строки в JScript, то там строго рекомендуется использование оператора «+=»; т.е. используйте s += «строка», а не s = s + «строка».

Совет 21: Используйте кэширование страниц в браузере и proxy-сервере

По умолчанию в ASP отключено кэширование в веб-браузере и proxy. Смысл этого заключается в том, что ASP-страница — по своей природе динамическая и обычно содержит информацию, которая изменяется со временем. Если ваша страница содержит постоянные данные и не требует регенерации при каждом запросе, то вы должны включить кэширование для браузера и прокси. Это позволит браузерам использовать «кэшируемую» копию страницы в течение некоторого отрезка времени, которым вы можете управлять. Кэширование может значительно снизить нагрузку на вашем сервере.

Какие из динамических страниц могут быть кандидатами на кэширование? Вот некоторые примеры:

  • Страница с прогнозом погоды, где информация обновляется каждые 5 минут.
  • Начальная страница сайта, которая содержит список материалов на сервере или официальные сообщения для печати, которые модифицируются два раза в день.
  • Другие подобные страницы, где обновления происходят раз в несколько часов.

Заметьте, что с кэшированием в браузере или кэшированием proxy, вы получите меньшее количество хитов, зарегистрированных на вашем сервере. Поэтому, если вы хотите точно измерять количество просмотров страниц или количество показов баннеров, то скорее, всего вы не захотите воспользоваться кэшированием.

Кэширование в браузере управляется свойством «Expires» HTTP-запроса, который посылает веб-сервер браузеру. ASP обеспечивает два простых механизма, чтобы установить это свойство. Чтобы заставить страницу «устареть» через несколько минут — установите свойство Response.Expires. Следующий пример сообщает браузеру, что содержание данной страницы истекает через 10 минут:

Установка Response.Expires в отрицательное значение или 0 отключает кэширование. Использование большого отрицательного числа, например -1000 (немного больше, чем 1 день) будет лучше, в силу несоответствий между временем на сервере и в браузере. Второе свойство Response.ExpiresAbsolute позволяет вам устанавливать точное время, в течении которого содержание «устареет»:

Вместо использования объекта Response для того, чтобы установить истечение срока действия страницы, вы можете использовать HTML-тэг . Большинство браузеров «понимают» эту директиву, хотя proxy ее не используют.

Наконец, вы можете указывать является ли содержание допустимым для кэширования HTTP-proxy используя свойство Response.CacheControl. Установив это свойство в значение «Public» вы разрешите proxy кэшировать содержание страницы.


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

Совет 22: Используйте Server.Transfer вместо Response.Redirect

Метод Response.Redirect сообщает браузеру запросить другую страницу. Этот метод часто используется, чтобы переназначить запрос пользователя, например, к странице идентификации (login) или странице с сообщением об ошибке. Redirect вынуждает сделать новый запрос страницы, результат этого — то, что браузер должен сделать два запроса к веб-серверу и веб-сервер должен обработать дополнительный запрос. В новой версии IIS 5.0 введена новая функция Server.Transfer, которая передает выполнение другой ASP-странице на том же самом сервере. Это помогает избежать дополнительного запроса «браузер-сервер» и в общем и целом приводит к улучшению производительности системы, а также к более короткому времени редиректа и отображения страницы в браузере пользователя.

Следующий скрипт демонстрирует использование Server.Transfer для переназначения запроса в зависимости от значения переменной:

Server.Transfer посылает запрос из одного выполняемого ASP-файла к другому файлу. В течении редиректа выполнение первоначально запрошенного ASP-файла немедленно прекращается без очистки буфера вывода.

Совет 23: Используйте замыкающий слэш в URL каталогов

Этот совет относится не только к ASP-программистам, но и ко всем веб-разработчикам, кто в своей работе создает html-страницы.

Проверьте, всегда ли вы используете замыкающий слэш (trailing slash) — наклонную черту вправо (/) в URL каталогов веб-сайта. Если опустить этот слэш браузер будет делать запрос к серверу, только для того, чтобы сообщить, что он спрашивает о каталоге. Затем браузер будет делать второй запрос, но уже со слэшем на конце URL, и только тогда веб-сервер будет возвращать «главный» (default) документ этого каталога или выдавать список файлов каталога, если в нем нет главного документа и разрешен просмотр каталога. Добавление к URL замыкающего слэша позволяет избежать первого бесполезного запроса к веб-серверу, что, естественно, экономит время, которое требуется для перехода по ссылке. Чтобы подобная ссылка выглядела более приятнее вы можете опустить слэш в названии URL.

Этот совет также относится и к записи ссылок на главную страницу веб-сайта. Используйте

Совет 24: Избегайте использования серверных переменных

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

Также пытайтесь избегать неопределенных вызовов объекта Request (например, Request(«Данные»)). Для элементов, находящихся не в Request.Cookies, Request.Form, Request.QueryString или Request.ClientCertificate, имеется неявный запрос к Request.ServerVariables. Запрос к коллекции Request.ServerVariablesе выполняется намного медленнее, чем доступ к другим коллекциям.

Совет 25: Сделайте upgrade системного программного обеспечения

Системные компоненты постоянно обновляются, поэтому рекомендуется, чтобы вы модернизировали (сделали upgrade) к самой последней версии. Лучше всего установить Windows 2000 (и следовательно, IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1 и JScript 5.1). IIS 5.0 и ADO 2.5 позволяют достичь значительного повышения производительности ваших приложений на мультипроцессорных системах. На серверах под управлением ОС Windows 2000 ASP может респределять нагрузку одновременно на четыре процессора и больше, принимая во внимание, что в предыдущей версии — под IIS 4.0, ASP не делал такого распределения и на два процессора. Насколько много вы используете скриптового кода и ADO в ASP-страницах вашего сайта, настолько больше повышения производительности вы должны увидеть после модернизации к Windows 2000.

Если вы не можете установить Windows 2000 сейчас, вы можете модернизировать ваше системное программное обеспечение к самым последним версиям SQL Server, ADO, VBScript и JScript, MSXML, Internet Explorer и пакета обновления NT 4 (Service Pack). Каждое из перечисленного позволяет улучшить выполнение работы и увеличить надежность.

Использование кэширования в Web-приложениях

Цель лекции: изучить принципы использования кэширования при создании Web-приложений. На практических примерах рассмотреть возможности ASP . NET по организации различных видов кэширования как целых страниц, так и их частей.

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

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

Но применение кэширования не только приводит к повышению производительности и масштабируемости, но и создает ряд проблем, которые необходимо знать и уметь их обходить. Одна из таких проблем — это то, что кэширование задействует оперативную память , которая никогда не бывает лишней. Если попытаться сохранить в оперативной памяти слишком много данных, операционная система сбрасывает лишние данные на диск , что может привести к замедлению работы всей системы в целом. Для управления этим процессом в ASP . NET реализован интеллектуальный механизм определения переполнения кэша, который основан на том, что при попытке записи в кэш данных, объем которых превышает доступный для кэша объем оперативной памяти, ASP . NET выборочно удалит из кэша часть данных для обеспечения максимальной общей производительности системы. Кроме того, при использовании механизмов кэширования необходимо помнить, что должен быть некий принцип, согласно которому будет осуществляться проверка обновления информации в кэше. Если данные таблицы базы данных или файла изменились, это может означать, что данные кэша устарели и их необходимо обновить. ASP . NET 2.0 предоставляет усовершенствованный механизм управления кэшированием , реализуя все необходимые элементы управления политикой кэширования. В частности, он позволяет управлять замещением информации, находящейся в кэше, управлять профилями кэшей, с помощью которых можно определить настройки кэширования для группы страниц, управлять хранением содержимого кэша в оперативной памяти и на жестких дисках, отслеживать изменения в исходных данных и удалять или объявлять недействительными кэшированные элементы.

Основы кэширования в ASP.NET

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

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

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

Упомянутые виды кэширования стали основой для создания еще двух разновидностей.

  • Кэширование фрагментов — позволяет сохранять в кэше лишь часть готового HTML-кода страницы. В основном это относится к пользовательским элементам управления.
  • Кэширование источников данных — встроенный в объекты доступа к данным механизм кэширования данных, который запускается автоматически при использовании соответствующего элемента.

Рассмотрим основные аспекты применения кэширования в ASP . NET

Кэширование вывода

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

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

Создадим новое Web- приложение , откроем редактор кода страницы и введем следующую команду в обработчик события Page_Load :

При запуске на страницу будет выводиться текущая дата и время. Если нажать кнопку «Обновить» в окне браузера, показания времени изменятся в соответствии с текущим значением системных часов.

Добавим данную страницу в кэш . Для этого добавим к файлу страницы директиву

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

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

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

Выше уже отмечались некоторые потенциальные проблемы, связанные с кэшированием страницы вывода. Одним из таких случаев является использование данных, передаваемых странице через строку запроса. При установленном режиме кэширования, рассматриваемом выше, несмотря на ввод в строку адреса значений переменных страница сохраняется в кэше заданные 10 секунд. Однако такое поведение можно изменить, если указать в качестве значения параметра VaryByParam значение «*», которое устанавливает режим кэширования страниц, содержащих строку запроса. При этом ASP . NET начинает кэшировать отдельные копии страницы для разных значений аргументов, указанных в строке запроса.

Использование значения «*» в качестве значения параметра VaryByParam в некоторых случаях способно вызвать дополнительные проблемы. Дело в том, что в некоторых типах приложений достаточно часто применяется передача множества параметров в строке запроса. Если значение хотя бы одного из передаваемых параметров будет отличаться от значения такого же параметра кэшированной страницы, запрашиваемая страница будет кэширована вновь. Например, если в строке запроса передается информация о клиенте, а также о выбранном им товаре, понятно, что количество комбинаций клиента и товара достаточно велико, а следовательно, практически все запрашиваемые страницы будут помещены в кэш , причем их повторное использование будет стремиться к 0. В этом случае целесообразно выявить те параметры, которые наиболее часто нужны для передачи параметров с высокой степенью повторного использования, и указать их в качестве значения параметра VaryByParam . Например, следующая строка дает команду ASP . NET для кэширования только тех страниц, которые содержат параметр ClientID , чье значение , в свою очередь , отличается от уже сохраненного в кэше.

Что такое код asp appcreate

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

Заголовок кэширования — это обычные заголовки, которые определяются спецификацией протокола HTTP и которые позволяют управлять кэшированием. То есть это заголовки Cache-Control , Pragma и Vary .

Основным из них является заголовок Cache-Control , который может принимать следующие значения:

public : ответ будет кэшироваться везде — и на машине клиента, и на промежуточных прокси-серверах

private : ответ будет кэшироваться только на компьютере клиента, но промежуточные прокси-серверы не будут выполнять кэширование

no-cache : ответ нигде не будет кэшироваться

max-age : время кэширования

Для настройки заголовоков ответа атрибут ResponseCacheAttribute определяет следующие свойства:

Duration : устанавливает максимальное время кэширования в секундах. Является обязательным, если свойство NoStore не равно true. Duration добавляет к заголовку Cache-Control значение max-age с устанавливаемым временным промежутком в секундах

Location : определяет место кэширования. Принимает одно из значений из перечисления ResponseCacheLocation :

Any : ответ кэшируется везде (в том числе и на прокси-серверах). Является значением по умолчанию

Client : ответ кэшируется только на компьютере клиента

None : ответ нигде не кэшируется

NoStore : определяет, будет ли ответ кэшироваться. Если равен true , то ответ не кэшируется, а значения свойств Location и Duration игнорируются. Кроме того, заголовку Cache-Control добавляется значение no-store

VaryByHeader : устанавливает заголовок vary

CacheProfileName : определяет имя профиля кэширования

Order : устанавливает порядок данного атрибута при применении к методу контроллера одновременно нескольких атрибутов

Для практического применения создадим новый проект по типу Web Application. И применим к какому-нибудь методу контроллера данный атрибут. Сначала отключим любое кэширование:

Здесь атрибут применяется к стандартному методу Index. Значение NoStore =true добавляет к заголовку Cache-Control значение no-store , а значение Location =ResponseCacheLocation.None добавляет к Cache-Control значение no-cache

Теперь обратимся в браузере к этому методу:

Как видно, браузер клиента получил установленные заголовки:

Мы можем перезагрузить страницу, и опять бует идти обращение к серверу, поскольку кэширование не выполняется. Теперь изменим атрибут:

Теперь будет выполняться кэширование, так как я явным образом использовал значение Location =ResponseCacheLocation.Any (оно применяется по умолчанию, поэтому его можно опускать). Кроме того, срок жизни кэша будет составлять 300 секунд, то есть 5 минут.


Перезапустим приложение, и теперь заголовок Cache-Control будет иметь другое значение:

И если в течение следующих 300 секунд мы снова обратимся к методу Index, то ответ будет извлекаться из кэша браузера:

Профили кэширования

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

Каждый профиль кэширования представлен объектом CacheProfile из пространства имен Microsoft.AspNetCore.Mvc. Для добавления профиля применяется метод options.CacheProfiles.Add() , в который передается название профиля и собственно профиль.

Объект профиля устанавливает все те свойства, что и атрибут ResponseCacheAttribute.

Здесь добавляется два профиля, при необходимости мы можем добавить профилей, сколько нам надо. И затем в атрибуте ResponseCache нам надо указать имя нужного профиля через параметр CacheProfileName :

Введение в Windows Server AppFabric. Сервис Caching Services

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

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

Первый выпуск Windows Server AppFabric содержит две части (сегодня доступна версия 1.1 со множеством нововведений. — Прим. пер.):

  • Сервис AppFabric Caching Services, который позволяет ускорить доступ к часто используемым данным приложений
  • Сервис AppFabric Hosting Services, который позволяет упросить запуск и управление сервисами созданными на базе WCF и особенно созданными на базе Windows Workflow Foundation

Windows Server AppFabric предлагает расширения для роли Application Server и эти расширения бесплатны для использования вместе или раздельно. В этом введении рассматриваются обе части AppFabric.

AppFabric Caching Services

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

Но в случае если все эти сервера зависят от одного сервера БД, доступ к данным может быстро стать узким местом вашей архитектуры. Добавление новых серверов не поможет, когда странице ASP.NET придется ожидать необходимые ей данные. Одно из решений запускать сервер БД на более мощной машине. Это может сработать, но и тут существуют ограничения: вам придется масштабироваться заменяя сервер на все более и более мощные машины и такая замена может стать слишком дорогостоящей. Что нам на самом деле нужно, так это способ масштабирования, при котором часто запрашиваемые данные были доступны на нескольких серверах, что позволит нам избежать узкого места в виде одного сервера.

Эффективный способ достижения этого — это создание распределенного кэша, который распространяет данные среди нескольких компьютеров. Вместо того, чтобы отсылать каждый запрос на один сервер БД, приложение ASP.NET сможет получить необходимые данные от одной из соседних машин. Нагрузка будет распределенной и приложение начнет работать быстрее. Это именно тот функционал, который предлагает сервис AppFabric Caching Services.

Как работает AppFabric Caching Services

Основным компонентом сервиса AppFabric Caching Services является клиент кэша, например страница ASP.NET, которая обращается к кластеру кэша содержащего некоторое количество серверов кэша. Каждый сервер кэша запускает экземпляр сервиса AppFabric Caching Services и поддерживает доступ к некоторому набору закэшированных данных. Каждый клиент кэша может так же поддерживать свой локальный кэш данных, используя специальные компоненты поставляемые вместе с AppFabric Caching Services. На рисунке 1 представлена схема всех компонентов:

Рис.1. Схема организации AppFabric Caching Services

Когда клиент кэша впервые получает некий кусок данных, например информацию переданную пользователем в ASP.NET-приложение или значения прочитанные из БД, клиент может сохранить эту информацию с уникальным именем в кластере кэша AppFabric Caching Services (или как будет рассказано далее, приложения ASP.NET могут сохранять информацию прозрачно через объект Session, так что даже не потребуется переписывать код у имеющегося приложения). Для клиента все остальные сервера кэша в кластере выглядят как одно большое хранилище — клиент никогда не знает и ему не нужно знать на каком из физических серверов хранятся его закэшированные данные. По желанию, клиент может сохранять данные и у себя в локальном кэше.

Когда клиенту снова требуется получить доступ к тем же данным, он запрашивает их через указанное уникальное имя. Этот запрос проверяет локальный кэш (если такой есть). Если данные найдены, то клиент использует их из локального кэша. Если данных нет в локальном кэше, запрос отправляется в кластер кэша. Если данные есть в кластере, клиент использует их. Весь этот процесс прозрачен для клиента, он просто отправляет запрос и AppFabric Caching Services берет на себя все остальное. В случае, если данные не были найдены в кластере кэша, клиенту придется запрашивать данные в БД.

Сервис AppFabric Caching Services на этапе разработки носил кодовое имя «Velocity», имя которое точно определяет что этот сервер делает: он позволяет сделать повторяющиеся запросы к данным быстрее. Вместо того чтобы делать множество однотипных запросов к БД, этот сервис позволяет получить данные прямо из локальной или распределенной памяти. Для приложений, которые часто запрашивают одинаковые данные, а таких очень много, кэширование значительно улучшает производительность и масштабируемость.

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

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

Кэширование полезно при работе с разными типами данных. Например, кэширование весьма полезно при работе с неизменяемыми во времени данными, которые запрашиваются разными клиентами (информация о каталоге онлайн-поставщика). Другой хороший пример использования кэширования — это хранение изменяемых данных, которые однако потребляются только одним клиентом, например, информация о сессии ASP.NET. И снова, этот пример описывает случай когда проблемы управления одновременным доступом к кэшированным данным не возникает.

Но что насчет того, когда данные, которые постоянно изменяются должны одновременно потребляться большим числом клиентов? Кэширование может быть использовано и в этом случае, но с одной оговоркой: необходим контроль за одновременным доступом. Для того, чтобы адресовать эту проблему сервис AppFabric Caching Services поддерживает оба оптимистичный контроль одновременного доступа основанный на назначении номера версии и пессимистичный контроль одновременного доступа использующий явные блокировки.

Сценарий: использование кэширования в приложении ASP.NET

Приложения ASP.NET являются наиболее важными клиентами для сервиса AppFabric Caching Services. Как было сказано ранее, данные хранимые в объекте сессии ASP.NET самый очевидный кандидат для кэширования. На самом деле сервис предлагает встроенную поддержку для этого — разработчику необходимо только задать опции конфигурации и объект сессии будет прозрачно сохраняться в кластере кэша. Обратите внимание: это означает, что разработчики ASP.NET могут получить преимущества распределенного кэширования без модификации кода их приложения. Это позволяет использовать несколько копий веб-серверов с запущенными экземплярами приложения ASP.NET без использования SQL Server для хранения данных сессии. На рисунке 2 показано как этот механизм работает:

Рис.2. Схема работы ASP.NET-приложения с AppFabric Caching Services

Этот простой сценарий начинается с того, что пользователь отправляет некоторую информацию, которую ASP.NET сохраняет в пользовательский объект сессии (шаг 1). Веб-сервер, который обрабатывает запрос, сконфигурирован так, чтобы кэшировать объекты сессии в кластере AppFabric Caching Services и поэтому пользовательские данные записываются в один или более серверов кэша (шаг 2). Следующий запрос от пользователя основывается на данных, сохраненных на шаге 1, но этот запрос обрабатывается уже другим сервером (шаг 3). Код ASP.NET на этом сервере обращается к тому же объекту сессии, что на деле означает прозрачный доступ к кластеру кэша для доступа к данным (шаг 4). Это позволяет информации полученной на шаге 1 быть доступной для приложения. Обратите внимание, что нам не пришлось оперировать с БД для хранения информации, а так же нам не требуется чтобы запросы пользователя обрабатывал один и тот же сервер. Результат работы этой инфраструктуры — повышенная производительность и улучшенная масштабируемость ASP.NET-приложения.

Сценарий: использование механизма высокой доступности

Сервис AppFabric Caching Services сохраняет все данные в памяти — они не записываются на диск. По умолчанию, каждый кэшируемый объект хранится только на одной машине в кластере кэша. Для того, чтобы увеличить надежность, в случаях когда сервер становится недоступным, AppFabric Caching Services предлагает поддержку механизма высокой доступности. Этот механизм позволяет создавать дублируемые копии кэшированных данных на других машинах в кластере кэша. Если сервер кэша, который хранит первичную копию данных, становится недоступным, то данные будут получены из вторичного хранилища. Рисунок 3 демонстрирует всю идею:

Рис.3. Высокая доступность AppFabric Caching Services

В этом примере, механизм высокой доступности выключен, так что каждый элемент кэшируемых данных сохраняется в двух разных серверах кэша. Первичная копия, показанная на рисунке в виде залитой фигуры, принимает все изменения с данными. Эти изменения автоматически реплицируются на вторичную копию, представленную в виде пустой фигуры. Здесь, сервер кэша содержащий первичную копию данных X становится недоступным (запланированно или случайно, шаг 1). Когда клиент кэша запрашивает данные X (шаг 2) кластер кэша скрытно перенаправляет запрос к вторичной копии и возвращает значение (шаг 3).

Этот пример показывает чтение данных, но и запрос на обновление будет точно так же обработано, когда сервер кэша с первичными данными будет недоступным. Как только AppFabric Caching Services определяет, что сервер с первичными данными недоступен, существующий сервер со вторичными данными становится первичным плюс создается новая вторичная копия на одном из доступных серверов. Все это прозрачно для клиента, просто работает так как будто с серверами ничего не происходило.

Независимо от того используется или нет механизм высокой доступности, сервис AppFabric Caching Services позволяет ускорить доступ к часто запрашиваемым данным. Это очень полезный функционал расширяющий имеющую инфраструктуру Windows Server.

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

Технология ASP+

В обзоре платформы Microsoft .NET (см. статью «Microsoft .NET — сервисы Windows нового поколения» в этом номере) мы упомянули о Web-формах и программной модели, основанной на ASP+ — новом поколении активных серверных страниц, представляющем собой эволюцию технологии ASP, знакомой многим Web-разработчикам. Здесь мы хотим остановиться на технологии ASP+ более подробно.

Эволюция ASP

Active Server Pages — технологии создания активных серверных страниц, позволяющей писать скриптовые (JavaScript, JScript, VBScript) программы, выполняемые на сервере, — чуть более трех лет. Объявленная в середине 1996-го (кодовое название Denali) и выпущенная в виде дополнения к Microsoft Internet Information Server 3.0 в декабре того же года, эта технология сразу же привлекла внимание Web-разработчиков.

ASP 2.0 увидела свет в составе Windows NT 4 Option Pack, выпущенного в декабре 1997 года, а ASP 3.0 стала частью Microsoft Internet Information Server 5.0, входящего в состав операционной системы Microsoft Windows 2000, и, таким образом, представляет собой полноценный компонент операционной системы. Отметим, что технология ASP успешно используется и на других платформах (Solaris, Apache — благодаря семейству продуктов Chili!ASP) и послужила основой для создания Java Server Pages и подобных технологий.

Естественно, что технология ASP была разработана не на пустом месте. Для создания динамических Web-страниц традиционно использовались серверные программы на базе серверного интерфейса Common Gateway Interface (CGI). Такие программы могут получать запросы от пользователей и генерировать HTML- и скриптовый код и отсылать его Web-клиенту. Вместо написания исполняемых программ часто используются интерпретируемые языки типа Perl — в этом случае программист составляет последовательность команд, а Web-сервер выполняет ее, используя интерпретатор.

Для своего Web-сервера Internet Information Server Microsoft предложила интерфейс Internet Server Application Programming Interface (ISAPI), который отличался от CGI тем, что позволял выполнять на Web-сервере откомпилированный код, помещенный в DLL. Как и в случае с CGI, программы могут получать запросы от пользователей и генерировать HTML- и скриптовый код и отсылать его Web-клиенту.

Для связи с данными и обеспечения возможности их публикации на Web-страницах сначала был выпущен продукт под названием dbWeb, затем появилась более совершенная технология — Internet Database Connector (IDC), с помощью которой можно было использовать шаблоны для публикации извлекаемых из СУБД данных.

Следующим логическим шагом стало объединение шаблонов, скриптового кода и механизма доступа к данным (ADO) в единое целое — появилась технология ASP.

По мере развития ASP приобрела такие возможности, как использование сторонних серверных компонентов, создание приложений, интеграция с Microsoft Transaction Server (MTS), а в версии 3.0 — интеграция с сервисами COM+.

Таким образом, сегодня ASP представляет собой технологию создания динамических страниц, поддерживающую публикацию данных и возможность использования сторонних серверных компонентов. Для написания скриптового кода используются языки JScript, VBScript или PerlScript. (Практические вопросы использования технологии ASP рассматриваются в статье «ASP на блюдечке», публикуемой в данном номере.)

Освежив в памяти историю развития технологии ASP, перейдем к рассмотрению ограничений, существующих у этой технологии сегодня.

Ограничения ASP

Можно выделить несколько типов существующих в настоящее время ограничений ASP. Первым из них является то, что скриптовый код располагается между HTML-элементами, а потому дизайнер, отвечающий за представление страницы, может легко нарушить ее функциональность. Одним из решений этой проблемы стало введение в Visual Basic 6 понятия Web Classes. Но поскольку эта технология была недостаточно совершенной, она не получила широкого распространения.

Вторым ограничением ASP является то, что для написания кода используются только скриптовые языки. Интерпретация кода приводит к потере производительности, и многие программные элементы приходится реализовывать в виде COM-объектов.

Внедрение таких объектов на Web-сервере подводит нас к третьему существенному ограничению — для того чтобы заменить DLL, нам требуется остановить Web-сервер, а нередко и перезагрузить компьютер. Теперь представьте себе, что будет, если внедрить обновления, например, для Hotmail, где используется около 5000 серверов!

И наконец, четвертое ограничение ASP — поддержка состояний. В настоящее время не существует простого встроенного механизма для передачи данных между страницами.

Технология ASP+, представляющая собой не просто очередную версию ASP — ASP 4.0, а новую, написанную с нуля платформу для создания интерактивных, динамичных Web-приложений, призвана снять описанные выше ограничения и привнести множество новинок, облегчающих создание подобных приложений. К основным новинкам ASP+ относятся: поддержка откомпилированного кода, объектная модель для страницы, серверные компоненты, облегченное внедрение, облегченное конфигурирование и администрирование, кэширование и ряд других.

Технология ASP+

ASP+ разработана таким образом, что ее возможно использовать «параллельно» с традиционными ASP-страницами. ASP+-страницы имеют расширения .aspx, Web-сервисы — .asmx, а новые страничные компоненты (pagelet) — расширение .aspc. Бета-версия ASP+ поддерживает только IIS5 на платформе Windows 2000, финальная версия сможет работать и под IIS4 на платформе Windows NT 4.0, и с Internet Explorer 5.5 (офлайновая версия My Web). Также будут поддерживаться персональные серверы на базе Windows 95/98.

Как мы отмечали выше, ASP+ поддерживает откомпилированный код. Это означает, что код может быть написан на любом языке, поддерживаемом в Microsoft .NET, — Visual Basic, Visual C++, C#, Perl, Pyton, Eiffel, COBOL и т.п. В ASP+ поддерживаются языки со строгой типизацией и ранним связыванием — больше нет необходимости в использовании только вариантных переменных. Поскольку код является откомпилированным, мы получаем более высокую производительность — в среднем на 250%.

В ASP+ введено понятие серверной объектной модели, включающей серверные компоненты (а точнее — серверные интерфейсные элементы). Теперь можно использовать серверные комментарии ( ), вставлять данные ( ) и связывать их с серверными интерфейсными элементами, использовать директивы ( ) для декларативной установки опций страниц. Помимо этого поддерживается и знакомый нам по ASP синтаксис: и .

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

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

В случае использования ASP+ мы более четко отделяем программную логику от HTML-элементов:

Обратите внимание на атрибут RUNAT=SERVER у элемента . Он указывает на то, что интерфейсный элемент (комбинированный список) располагается на сервере. В ASP+ реализованы серверные версии всех HTML-элементов управления, а также дополнительные элементы управления. Всего в состав ASP+ входит 45 встроенных серверных интерфейсных элементов. Ниже показаны HTML-элементы, реализованные на сервере, и встроенные элементы:

HTML-элементы Встроенные элементы
, ,

Если ввести свое имя и нажать кнопку Submit, содержимое формы отправится на сервер, будет обработано и возвращено клиенту. Поле «Имя» будет пустым. Для того чтобы сохранить введенное значение при передаче его назад, с сервера клиенту, нам придется написать ASP-код. В ASP+ введена технология под названием ViewState, позволяющая сохранять введенные значения. Это достигается простым изменением элемента

Если мы посмотрим на HTML-код этой формы, то обнаружим, что ядро ASP+ автоматически вставило скрытое поле, в котором сохраняется содержимое формы.


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

Говоря о серверных элементах, следует упомянуть и о возможности отделения кода от самой страницы. Например:

ASP.Net — папки App_Data & App_Code?

В чем смысл наличия папок App_code и App_data ?

Почему мой объект objectDataSource не обнаруживает классы, если файлы не находятся в App_Code?

Пожалуйста, предоставьте как можно больше деталей, я новичок в ASP.Net

Эти папки имеют особое назначение. Из этой статьи — Структура папок веб-проекта ASP.NET.

App_Code содержит исходный код для общих классов и бизнес-объектов (например. cs и .vb файлы), которые вы хотите скомпилировать как часть вашего приложения. В динамически скомпилированном проекте веб-сайта ASP.NET компилирует код в папке App_Code при первоначальном запросе вашего приложения. Элементы в этой папке затем перекомпилируются, когда обнаружены какие-либо изменения.

Примечание. Вы можете добавить любой тип файла класса в папку App_Code, чтобы создать строго типизированные объекты, которые представляют эти классы. Например, если вы помещаете файлы веб-сервиса (.wsdl и .xsd) в папку App_Code, ASP.NET создает строго типизированные прокси для этих классов.

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

Authentication Using Google In ASP.NET Core 2.0

by Ankit Sharma

Authentication Using Google In ASP.NET Core 2.0

Introduction

Sometimes, we want our users to log in using their existing credentials from third-party applications, such as Facebook, Twitter, Google, and so on. In this article, we are going to look into authentication of an ASP.NET Core app using a Google account.

Prerequisites

  • Install .NET Core 2.0.0 or above SDK from here.
  • Install the latest version of Visual Studio 2020 from here.

Create MVC Web Application

Open Visual Studio and select File >> New >> Project. After selecting the project, a “New Project” dialog will open. Select .NET Core inside the Visual C# menu from the left panel. Then, select “ASP.NET Core Web Application” from the available project types. Put the name of the project as GoogleAuth and press OK. Refer to this image.

After clicking OK, a new dialog will open asking you to select the project template. You can observe two drop-down menus at the top left of the template window. Select “.NET Core” and “ASP.NET Core 2.0” from these dropdowns. Then, select the “Web application(Model-View-Controller)” template. Click on the Change Authentication button, and a “Change Authentication” dialog box will open. Select “Individual User Account” and click OK. Now, click OK again to create our web app.

Before running the application, we need to apply migrations to our app.

Navigate to Tools >> Nuget Package Manager >> Package Manager Console.

It will open the Package Manager Console. Put in the Update-Database command and hit enter. This will update the database using Entity Framework Code First Migrations.

Press F5 to run the application. You will see a homepage, as shown below.

Note the URL from the browser’s address bar. In this case, the URL is http://localhost:51792/. We need this URL to configure our Google app, which we will be doing in the next section.

Create the Google app

We need to create a new Google app on the Google API console. Navigate to https://console.developers.google.com/projectselector/apis/library and log in using your Google account. If you do not have a Google account, you need to create one. You cannot proceed without a Google account. Once you have logged in, you will be redirected to the API Manager Library page, similar to the one shown below.

Click on the Create button to move to the “New Project” page where you need to create a new project. The “Project name” field will be populated automatically with a default name provided by Google. If you want, you can override that with your own custom name. For this tutorial, we will be using the default name. Accept the terms of service and then click on the Create button.

Your project will be created successfully and you will be redirected to the API Library page similar to the one shown below.

Search for the Google+ API in the search bar and select the Google+ API from the search results. Refer to the below image.

After selecting the Google+ API option, you will be redirected to a page as shown below, where you need to click on the Enable button.

After this, the Google+ API will be enabled and you will be redirected to the API home page. Click on Create credentials button on the right side of the page to configure the secrets for your API.

You will see an “Add credentials to your project” form.

This form has three sections.

Fill in the details of the sections as described below.

Section 1 — Find out what kind of credentials you need

  • Which API are you using? — Google+ API
  • Where will you be calling the API from? — Web server (for example, Node.js, Tomcat)
  • What data will you be accessing? — User data

And click on the What credentials do I need button. You will be redirected to section 2

Section 2 — Create an OAuth 2.0 client ID

  • Name — The default value provided by Google.
  • Authorized JavaScript origins — Leave it blank.
  • Authorized redirect URIs — Give the base URL of your application with /signin-google appended to it. For this tutorial, the URL will be http://localhost:51792/signin-google. After entering the URL, press TAB to add the value.

After this, click on the Create client ID button. You will be redirected to section 3.

  • Email address — Select your email address from the dropdown. This value is masked in the above image for privacy.
  • Product name shown to users — Enter any product name. Here we are using “AuthDemo” as the Product name.

Note: Do not use the word “Google” in your product name. You will be prompted with an error and you won’t be allowed to create the app. This means “GoogleAuthDemo” is an invalid name.

Click on continue.

Your credentials have been created successfully. Click Download to download a JSON file to your local machine with all your application secrets, and then click Done to complete the process.

Open the just downloaded client_id.json file and make a note of the ClientId and ClientSecret fields. We will need these values to configure Google authentication in our web app.

Configure your Web App to use Google authentication

We need to store the ClientId and ClientSecret field values in our application. We will use the Secret Manager tool for this purpose. The Secret Manager tool is a project tool that can be used to store secrets such as password, API Key, etc. for a .NET Core project during the development process. With the Secret Manager tool, we can associate app secrets with a specific project and can share them across multiple projects.

Open your web application once again and Right-click the project in Solution Explorer. Select Manage User Secrets from the context menu.

A secrets.json file will open. Put the following code in it:

Now open the Startup.cs file and put the following code into the ConfigureServices method:

In this code section, we are reading ClientId and ClientSecret for authentication purposes. So finally, Startup.cs will look like this:

And with this, our application is ready.

Execution Demo

Launch the application and click Login on the top right corner of the home page.

You will be redirected to http://localhost:51792/Account/Login page, where you can see the option to login using Google on the right side of the page.

Clicking on the Google button will take you to the Google login page. There, you will be asked to fill in your Google credentials and authorize the Google app to use your Google account.

After successful authentication from Google, you will be redirected to a registration page inside your application where you need to fill in an email id to tag with your account. The Gmail id that you have used to login will already be populated in the Email id field. If you want to use another mail id, you can change it here.

Click register, you will be redirected to the home page again. But this time you can also see that your registered email is on the top right corner.

Conclusion

We have successfully created and configured a Google+ app and used it to authenticate our ASP.NET Core application.

You can get the source code from GitHub.

Please note that the secrets.json file contains dummy values. You’ll need to replace the values with the keys of your Google app before executing it.

You can also find this article at C# Corner.

You can check my other articles on ASP .NET Core here

See Also

If this article was helpful, tweet it or share it.

app_code блокирует видимость классов

26.08.2013, 12:19

Как подключить файл из папки App_Code
Вопрос следующего характера: В папке App_Code хранится файл 1.cs В основном проекте в файле.

App_Code/MyClass.cs — работа с классами в asp.net/c#
Люди добрые, помогите в следующем коде: using System; using System.Data; using.

Получить доступ к классам, хранящимся в каталоге App_Code
Привет всем гуру и не только! Собствено вопрос: Почему в web проекте (ASP.NET) с файлов кода.

Как из файлов в папке App_Code вызвать другую страницу
Товарищи Форумчане,помогите пожалуйста разобраться. Суть вопроса: есть приложение ASP .NET C#.

Видимость классов
Здравствуйте. Есть один класс, в конструкторе которого создается текстовое поле, и печатается.

Илон Маск рекомендует:  Создание объемного тумана
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL