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

Содержание

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

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

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

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

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

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

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

Среда ASP.NET в действительности поддерживает два типа кэширования. Ваши приложения могут, да и должны, использовать оба типа, т.к. они дополняют друг друга:

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

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

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

Этим кэшированием можно управлять вручную в коде. Чтобы использовать кэширование данных, вы сохраняете в кэше важные части информации, которые требуют значительного времени на повторную реконструкцию (например, объект DataSet, извлеченный из базы данных). Другие страницы могут проверить существование этой информации и пользоваться ею — таким образом, пропуская шаги, обычно подлежащие выполнению для ее получения.

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

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

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

Кэширование источников данных.

Это кэширование, встроенное в элементы управления источниками данных, в том числе SqlDataSource, ObjectDataSource и XmlDataSource. Формально кэширование источников данных использует кэширование данных. Отличие в том, что управлять этим процессом явно не приходится. Вместо этого нужно просто сконфигурировать соответствующие свойства, и элемент управления источником данных будет управлять процессом сохранения и извлечения из кэша.

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

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

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

Декларативное кэширование вывода

Чтобы увидеть кэширование вывода в действии, можно создать простую страницу, отображающую текущее время. На рисунке ниже показан пример. Код для этой страницы достаточно прост. Он устанавливает текущую дату и время в метке Label1 при наступлении события Page.Load:

Существуют два способа добавить страницу в кэш вывода. Наиболее распространенный подход заключается во вставке директивы OutputCache в начало файла .aspx, непосредственно под директивой Page:

В этом примере атрибут Duration инструктирует ASP.NET о том, что страницу нужно хранить в кэше в течение 20 секунд. Атрибут VaryByParam также необходим, но о нем речь пойдет в следующем разделе.

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

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

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

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

Кэширование и строка запроса

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

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

В рассматриваемом примере атрибут VaryByParam устанавливается в None. Это сообщает ASP.NET, что мы хотим хранить только одну копию кэшируемой страницы, которая подходит для всех сценариев. Если запрос к этой странице будет добавлять строку аргументов к URL, это не имеет значения — ASP.NET все время будет использовать тот же самый вывод, пока он не устареет. Вы можете проверить это, добавляя параметр строки запроса вручную в окне браузера (как, например, ?a=b ).

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

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

Чтобы лучше представить, как работает этот процесс, рассмотрим следующую последовательность запросов:

Вы запрашиваете страницу без каких-либо параметров строки запроса и получаете копию страницы A.

Вы запрашиваете страницу с параметром Product >

Другой пользователь запрашивает страницу с параметром Product >

Другой пользователь запрашивает страницу с параметром Product >

Затем пользователь запрашивает страницу без параметров строки запроса. Если копия A не устарела, она извлекается из кэша и отправляется ему.

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

Кэширование со специфичными параметрами строки запроса

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

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

Во многих ситуациях установка VaryByParam=»*» вносит ненужную неопределенность. Обычно лучше специально идентифицировать важную переменную строки запроса по имени. Вот пример:

В этом случае ASP.NET будет проверять строку запроса, пытаясь найти параметр ProductID. Запросы с разными параметрами ProductID будут кэшироваться раздельно, но все остальные параметры будут игнорироваться. В частности, это может оказаться удобным, если страница может принимать дополнительную информацию в строке запроса, которую она не использует. Без вашей помощи ASP.NET не имеет возможности отличить «важные» параметры строки запроса.

Можно указать несколько параметров, разделяя их точками с запятой:

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

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

Настраиваемое управление кэшем

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

Один из способов применения настраиваемого кэширования — хранение разных версий страницы для различных типов браузеров. Таким образом, браузеры Firefox всегда будут получать оптимизированные для Firefox страницы, a Internet Explorer получит HTML-разметку, оптимизированную именно для него. Чтобы настроить такую логику, следует начать с добавления директивы OutputCache к страницам, которые будут кэшироваться. В атрибуте VaryByCustom должно быть указано имя, представляющее тип создаваемого наслаиваемого кэширования. В следующем примере применяется имя браузера, поскольку страницы должны кэшироваться на основе клиентского браузера:

Далее потребуется создать процедуру, которая будет генерировать пользовательскую строку кэширования. Эта процедура должна быть закодирована в файле приложения global.asax, как показано ниже:

Функция GetVaryByCustomString() получает имя VaryByCustom в параметре arg. Это позволяет создавать приложение, которое реализует несколько типов настраиваемого кэширования в одной и той же функции. Каждый отдельный тип должен использовать отличающееся имя VaryByCustom (такое как Browser, BorwserVersion или DayOfWeek). Функция GetVaryByCustomString() должна проверить имя VaryByCustom и вернуть соответствующую строку кэширования. Если строки кэширования для разных запросов совпадают, ASP.NET использует кэшированную копию страницы. Или, если посмотреть с другой стороны, ASP.NET будет создавать и сохранять в кэше отдельные котированные версии страницы для каждой строки кэширования, которую встретит.

Интересно, что базовая реализация GetVaryByCustomString() уже включает логику ориентированного на браузер кэширования. Это значит, что показанный выше метод кодировать не придется. Базовая реализация GetVaryByCustomString() создает строки кэширования на основе имени браузера и главного номера версии. Если вы хотите изменить эту логику работы (например, чтобы выбор кэша зависел от имени, старшего и младшего номеров версии), то для этого нужно переписать метод GetVaryByCustomString(), как в предыдущем примере.

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

Директива OutputCache также включает третий атрибут, который можно использовать для определения кэширования. Этот атрибут — VaryByHeader — позволяет сохранять отдельные версии страницы на основе значения заголовка HTTP, полученного с запросом. Можно указывать один заголовок или целый список заголовков, разделенных точками с запятой. Такой прием можно применять на многоязычных сайтах, чтобы кэшировать разные версии страницы на основе языка клиентского браузера, как показано ниже:

Кэширование с помощью класса HttpCachePolicy

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

Однако есть и другой выбор: можно написать код, использующий специальное встроенное свойство Response.Cache, которое предоставляет экземпляр класса System.Web. HttpCachePolicy. Этот объект содержит свойства, позволяющие включать кэширование для текущей страницы. Это позволяет программно решить, нужно ли включать кэширование вывода.

В следующем примере страница данных переписана так, чтобы автоматически разрешать кэширование при ее первой загрузке. Этот код включает кэширование с помощью метода SetCacheability(), который указывает, что страница будет кэширована на сервере, и что любой другой клиент сможет использовать ее кэшированную копию. Метод SetExpires() определяет время удержания копии страницы в кэше, которое установлено, начиная с текущего момента, плюс 60 секунд:

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

Послекэшевая подстановка и кэширование фрагментов

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

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

Послекэшевая подстановка. В этом случае идентифицируется только динамическая часть содержимого, которую кэшировать нельзя. Затем это содержимое заменяется чем-то другим с использованием элемента управления Substitution.

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

Кэширование фрагментов

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

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

Послекэшевая подстановка

Средство послекэшевой подстановки вращается вокруг единственного метода, добавленного в класс HttpResponse. Этот метод называется WriteSubstitution() и принимает один параметр — делегат, указывающий на метод обратного вызова, который вы реализуете в своем классе страницы. Метод обратного вызова возвращает содержимое этой части страницы.

Трюк состоит вот в чем: когда среда обработки страниц ASP.NET извлекает кэшированную страницу, она автоматически инициирует метод обратного вызова, чтобы получить от него динамическое содержимое. Затем она вставляет это содержимое в кэшированную HTML-разметку страницы. Изящество в том, что даже если страница еще не была помещена в кэш (она генерируется первый раз), ASP.NET все равно вызывает метод обратного вызова для получения динамического содержимого. По сути, идея заключается в том, что вы создаете метод, который генерирует некоторое динамическое содержимое, чем гарантируете, что он всегда будет вызван, и то, что он выдаст, никогда не будет помещено в кэш.

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

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

Проблема этой техники в том, что послекэшевая подстановка работает на более низком уровне, чем остальная часть пользовательского интерфейса. Обычно когда вы проектируете страницу ASP.NET, то вообще не используете объект Response — вместо этого применяются веб-элементы управления, и эти элементы управления используют объект Response для генерации своего содержимого. Сложность в том, что если вы используете объект Response, как показано в предыдущем примере, то теряете возможность позиционировать содержимое относительно остальной части страницы. Единственное реалистичное решение — поместить динамическое содержимое в элемент управления некоторого вида. Таким образом, элемент управления может использовать Response.WriteSubstitution() при визуализации самого себя.

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

Рассмотрим пример, который дублирует предыдущий, используя разметку в .aspx-части страницы:

К сожалению, во время проектирования содержимое элемента управления Substitution не видно.

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

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

Профили кэшей

Одна из проблем кэширования вывода связана с необходимостью встраивания инструкции в страницу — либо в часть разметки .aspx, либо в код класса. Хотя первый вариант (использование OutputCache) относительно ясен, все же он порождает проблемы управления, если создаются десятки кэшированных страниц. Если вы хотите изменить кэширование для всех этих страниц (например, изменив время нахождения объектов в кэше с 30 до 60 секунд), то придется модифицировать каждую страницу. Кроме того, ASP.NET понадобится их все перекомпилировать.

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

Теперь этот профиль можно использовать на странице через атрибут CacheProfile:

Конфигурация кэша

Конфигурировать различные детали поведения кэша ASP.NET можно через файл web.config. Многие из этих опций предназначены для упрощения отладки и могут не иметь смысла в готовом рабочем приложении. Для конфигурирования этих настроек используется элемент внутри описанного ранее элемента . Элемент предоставляет несколько опций для настройки:

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

Применяйте percentagePhysicalMemoryUsedLimit для установки максимального процента физической памяти компьютера, разрешенной для использования в кэше ASP.NET. Когда кэш достигнет этого предела памяти, ASP.NET начинает очистку, удаляя самые старые или наиболее редко используемые элементы. Значение 0 указывает, что под кэш не должно оставляться никакой памяти, и что ASP.NET следует удалять элементы столь же быстро, как они и добавляются. По умолчанию ASP.NET использует для кэширования до 90% физической памяти.

Параметр privateBytesLimit определяет максимальное количество байт, которые специфическое приложение может использовать для своего кэша, прежде чем ASP.NET начнет интенсивную очистку. Этот лимит включает как память, используемую кэшем, так и память, расходуемую при обычной работе приложения. Значение 0 (по умолчанию) указывает, что ASP.NET будет использовать собственный алгоритм для определения момента, когда начнется освобождение памяти. Параметр privateBytesPollTime указывает, насколько часто ASP.NET проверяет используемые приватные байты (private bytes). По умолчанию это значение составляет 2 минуты.

Расширяемость кэширования вывода

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

Однако система кэширования ASP.NET не работает столь же хорошо, если в кэш требуется помещать крупные объемы данных на длительное время. Например, возьмем пополняемый каталог товаров в какой-нибудь гигантской компании электронной коммерции. Предполагая, что каталог товаров изменяется нечасто, может возникнуть желание кэшировать тысячи страниц с данными о товарах во избежание затрат на их создание. Но при таком большом объеме данных использование для этого памяти веб-сервера будет рискованным делом. Поэтому предпочтение следует отдать хранилищу другого типа, которое медленнее памяти, но быстрее процесса воссоздания страниц (и с меньшей вероятностью приводящего к нехватке ресурсов). Возможными вариантами может быть дисковое хранилище, база данных или распределенная система хранения, подобная Windows Server AppFabric.

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

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

ASP.NET не включает никаких заготовленных поставщиков кэширования. Тем не менее, члены команды разработчиков ASP.NET уже продемонстрировали прототипы, которые используют кэширование на основе файлов и Windows Server AppFabric. Они намерены превратить их в отдельные компоненты, доступные для бесплатной загрузки на www.codeplex.com. Вдобавок архитекторы ASP.NET пообещали выпустить примеры, показывающие, как интегрировать кэширование вывода ASP.NET и популярную распределенную систему кэширования memcached с открытым исходным кодом.

Специальные поставщики можно использовать только с кэшированием вывода, но не кэшированием данных.

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

Построение специального поставщика кэша

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

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

Сокращенное использование памяти

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

Илон Маск рекомендует:  Сборник программ для работы с CMS

Создать специальный поставщик кэша довольно просто. Унаследуйте новый класс от OutputCacheProvider из пространства имен System.Web.Caching. Затем переопределите в нем методы, описанные в таблице ниже:

Переопределяемые методы OutputCacheProvider

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

Добавляет элемент в кэш, если такового там не существует. В противном случае метод ничего не должен делать

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

Извлекает элемент из кэша, если таковой там существует. Этот метод должен также принудительно производить очистку кэша от устаревших элементов за счет проверки срока хранения элементов и удаления их при необходимости

Удаляет элемент из кэша

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

После создания этих классов остается только переопределить методы Add(), Set(), Get() и Remove(). Все эти методы получают ключ, который уникально идентифицирует кэшированное содержимое. Ключ основан на имени файла кэшированной страницы. Например, если кэширование вывода используется для страницы по имени OutputCaching.aspx на веб-сайте CustomCacheProvider, код может получить следующий ключ:

Для преобразования этого ключа в действительное имя файла символы \ просто заменяются в коде символами дефиса (-). Кроме того, добавляется расширение .txt, которое позволяет различать это кэшированное содержимое от настоящей страницы ASP.NET и облегчает ее открытие и просмотр во время отладки. Вот пример преобразованного имени файла:

Для выполнения такого преобразования FileCacheProvider использует приватный метод по имени ConvertKeyToPath(). Ниже показано полное определение класса FileCacheProvider и сериализуемого класса CacheItem:

Давайте разберем этот код более подробно. Метод Set() всегда сохраняет свое содержимое, в то время как метод Add() должен сначала проверить его существование. Кроме того, Add() возвращает кэшированный объект. Действительный код сериализации просто использует BinaryFormatter для преобразования визуализированной страницы в поток байтов, которые затем могут быть записаны в файл. Метод Get() столь же прост. Однако он должен проверять дату истечения срока хранения у извлекаемого элемента и отбрасывать его, если срок хранения истек. И, наконец, метод Remove() просто удаляет файл с кэшированными данными.

Использование специального поставщика кэша

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

Здесь предполагается, что FileCacheProvider — это класс в текущем веб-приложении (например, файл в папке App_Code беспроектного веб-сайта). Если бы он являлся частью отдельной сборки, понадобилось бы включить имя этой сборки. Например, класс FileCacheProvider из пространства имен CustomCaching, скомпилированный в сборку по имени CacheExtensibility, потребует следующую конфигурацию:

Лекция 1. Что такое ASP.NET. Инсталляция и тестовый проект.

Введение

Microsoft .NET Framework — это платформа для создания, развертывания и запуска Web-сервисов и приложений. Она предоставляет высокопроизводительную, основанную на стандартах, многоязыковую среду, которая позволяет интегрировать существующие приложения с приложениями и сервисами следующего поколения, а также решать задачи развертывания и использования интернет-приложений. .NET Framework состоит из трех основных частей — общеязыковой среды выполнения (common language runtime), иерархического множества унифицированных библиотек классов и компонентной версии ASP, называемую ASP.NET.

ASP.NET – это часть технологии .NET, используемая для написания мощных клиент-серверных интернет приложений. Она позволяет создавать динамические страницы HTML. ASP.NET возникла в результате объединения более старой технологии ASP (активные серверные страницы) и .NET Framework. Она содержит множество готовых элементов управления, используя которые можно быстро создавать интерактивные web-сайты. Вы также можете использовать сервисы, предоставляемые другими сайтами, прозрачно для пользователей вашего сайта. В общем, возможности ASP.NET ограничены только вашим воображением.

Давайте обсудим, что такое динамические страницы HTML и чем они отличаются от статических. Статическая страница содержит код на языке гипертекстовой разметки HTML. Когда автор страницы пишет ее, он определяет, как будет выглядеть страница для всех пользователей страницы. Содержание страницы будет всегда одинаковым независимо от того, кто и когда решит ее просмотреть. Языка HTML вполне достаточно для отображения информации, которая редко изменяется и не зависит от того, кто ее просматривает. Страница HTML — простой ASCII-текст, следовательно, клиент может работать в любой операционной системе.

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

Но что, если мы хотим отобразить на странице текущий курс евро или прогноз погоды? Если мы написали страницу HTML вчера, сегодня она уже устареет. Следовательно, мы должны уметь создавать динамические страницы. Динамическое наполнение страницы – это информация, содержание которой определяется тем, кому она предназначена, и которая отличается от просмотра к просмотру. Оно позволяет обеспечить двусторонний обмен информацией – от клиента к серверу и обратно.

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

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

Существуют языки, способные динамически изменять содержимое веб-страницы. С одной стороны, это языки скриптов, выполняющиеся непосредственно у клиента. Примеры скриптовых языков — JavaScript и VBScript. Скрипты на этих языках встроены в код HTML, который сервер посылает браузеру. Сценарии, выполняемые на стороне клиента, выделяются тегами и . Браузер интерпретирует этот код и показывает пользователю результат. Сам код можно просмотреть через View Source браузера. Естественно, эти программы не могут быть большими. Например, если нужно выполнить поиск в базе данных, мы не может отправить пользователю все ее содержимое. Но скрипты могут проверить правильность запроса, введенного в форму, тогда не придется перезагружать сервер обработкой неправильных запросов. Некоторые программисты создают на JavaScript анимационные эффекты. Одна студентка intuit.ru желала найти скрипт, который бы отправлял SMS-сообщения. Увы, это невозможно. Выполняемых на стороне клиента сценариев недостаточно для создания полноценных динамических страниц. Даже если на странице используется JavaScript, анимированные картинки .gif, она называется статической.

Динамическая веб-странице должна быть создана «на лету» программой, исполняющейся на интернет-сервере. Широко применяются механизм шлюзов CGI(Common Gateway Interface). Вначале пользователь получает статическую страницу с формой. Вам известно, что в теге FORM существует атрибут ACTION. Именно он задает адрес (URL) исполняемого приложения. На сервере находятся исполняемые файлы программ, написанных, например на C/С++ или Дельфи, которые по протоколу HTTP принимают данные из входного потока или из переменных окружения и записывают в стандартный выходной поток готовую страницу.

Пользователю в ответ на запрос посылается HTML код, который был специально сгенерирован для него. Это может быть, например, результат поиска в поисковой системе. CGI -скрипты могут быть написаны на интерпретируемом языке (Perl) или даже скрипте командной строки. Входной и выходной потоки переназначаются. На вход интернет-сервер принимает данные, введенные пользователем. После обработки полученных данных, пользователю возвращается результирующая страница. При исполнении cgi-программа загружается в память сервера, а при завершении – удаляется. Когда 100 клиентов одновременно обращаются к серверу, в памяти создаются 100 процессов, для размещения кода каждого из которых нужна память. Это отрицательно сказывается на масштабируемости. Напомним, что масштабируемость — это возможность плавного роста времени ответа программной системы на запрос с ростом числа одновременно работающих пользователей.

Для решения это проблемы Microsoft была предложена альтернатива – ISAPI(Internet Server Application Programming Interface)-расширения и фильтры. Вместо исполняемых файлов используются DLL – библиотеки. Код DLL находится в памяти все время и для каждого запроса создает не процессы, а нити исполнения. Все нити используют один и тот же программный код. ISAPI –приложение выполняется в процессе IIS-сервера. Это позволяет повысить производительность и масштабируемость.

ISAPI-расширения можно создавать в Visual Studio C++ 6.0, пользуясь мастером.

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

Скриптовые языки, исполняющиеся на стороне сервера – php и asp. Технология asp была разработана Microsoft в 90-х годах.

Выполнение кода asp поддерживается ISAPI-расширением сервера. В диалоге конфигурации сервера IIS определяются способы обработки файлов с различными расширениями. Для обработки URL-адреса с расширением в установках сервера определен файл asp.dll. Файлы asp отправляются к нему на обработку. На вход поступает asp, а на выходе имеем поток HTML-кода.

Пример файла asp:

Тег сигнализирует asp, что в нем находится код, который он должен обрабатывать на сервере. Выполняется скрипт на языке, который указан в директиве Language. Оператор Response.Write записывает текст в выходной поток сервера, таким образом, он становится частью HTML-страницы, отправленной пользователю.

Технология asp была ограничена по своим возможностям. Он использовал скриптовые языки, которые имеют меньше возможностей, чем полнофункциональные языки программирования. Код asp был встроен в HTML в виде специальных тегов, что создавало путаницу. Кусочки asp были разбросаны по нему, как изюм в булке. Но HTML код обычно создают дизайнеры, которые умеют «делать красиво», а asp – программисты, которые заставляют все это работать. В ASP.NET вы можете держать код asp и HTML в разных файлах.

Скриптовые языки не поддерживают строгую типизацию. Что это значит? Вы можете не описывать переменную до ее использования и можете присваивать ей значения разных типов. Это удобно, но создает почву для ошибок. Например, у вас есть переменная x1, и вы присваиваете ей значение 1, но вы сделали опечатку и по ошибке написали x2=1. Будет создана новая переменная x2, а значение x1 не изменится. В языке со строгой типизацией компилятор заметит, что переменная x2 не описывалась, и выдаст ошибку.

В 2000 году на конференции разработчиков в качестве части новой технологии .NET Microsoft представила ASP+. С выходом .NET Framework 1.0 она стала называться ASP.NET.

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

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

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

Платформа .NET Framework предоставляет приложениям среду выполнения, сама непосредственно взаимодействуя с операционной системой. Выше лежит интерфейс ASP.NET приложений, на котором в свою очередь базируются веб-формы (ASP.NET страницы) и веб-сервисы. Интерфейс .NET Framework позволяет стандартизировать обращение к системным вызовам и предоставляет среду для более быстрой и удобной разработки. CLR обеспечивает единый набор сервисов для всех языков.

ASP.NET использует технологию доступа к данным ADO.NET, которая обеспечивает единый интерфейс для доступа к базам данных SQL Server и файлам XML. Кроме того, усиленная модель безопасности позволяет обеспечивать защиту клиента и сервера от несанкционированного доступа.

В 2004 году появилась версия ASP.NET 2.0(бета-версия, окончательный выход – конец 2005-начало 2006). Как утверждается, эта версия позволяет сократить объем кодирования на 70%. Новые возможности версии 2.0 – например, использование шаблонов дизайна страниц(Master Page), упрощенная локализация Web-приложений, более 50 новых серверных элементов управления. Цели, которые преследовали разработчики новой версии – повысить скорость разработки сайтов, масштабируемость, легкость поддержки и администрирования сайтов, скорость работы сервера. Появилась панель остнастки MMC (консоль управления Microsoft), предоставляющая графический интерфейс для управления настройками ASP.NET. Изменять настройки проекта теперь можно и через web-интерфейс. ASP.NET 2.0 поддерживает работу на 64-битных процессорах. Сервис персонализации (personalization) предоставляет готовое решение для хранения персональных данных, непосредственно характеризующих пользователя сайта, так называемого профиля пользователя (Profile).

Шаблоны дизайна, темы и скины позволяют независимо дизайн всего сайта отдельно от его функциональности, темы включают графику и каскадные таблицы стилей.

Предыдущие версии Visual Studio для проектов ASP.NET требовали наличия на машине разработчика сервера IIS. Теперь сервер встроен в среду разработки.

ASP.NET 2.0 и Visual Studio 2005 предоставляют инструменты для легкого построения локализируемых сайтов, которые определяют предпочитаемый язык пользователя и посылают ему страницы на его языке.

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

В ASP.NET 2.0 встроена технология автоматического обновления кэширования баз данных. Данные, полученные из базы, хранятся на сервере и он не обращается к базе для обработки повторного запроса. При изменении базы данных кэш обновляет свое содержимое.

ASP.NET — это технология, а не язык, и позволяет программировать на разных языках – С#, Visual Basic, J#. В платформе .NET все языки равны, но некоторые равнее(Дж. Оруэлл). Вот таким языком и является С#, потому что он был специально создан для этой платформы. Программирование C# позволяет в полной мере использовать концепции, методы и паттерны объектно-ориентированной разработки. Язык Visual Basic 8.0 наделен почти теми же возможностями. Чтобы научиться ASP.NET, вам нужно знать основы HTML, а знание asp не обязательно. Оно может даже помешать, так как придется менять образ мышления. Также для понимания многих желательно знать CSS и JavaScript.

Процесс инсталляции

ASP .NET 2.0 можно установить на компьютерах с ОС Windows 2000 с Service Pack 4, Windows XP с Service Pack 2 и более поздними версиями Windows. Готовые сайты предпочтительно устанавливать на Windows Server 2003.

Для разработки приложения можно использовать любую среду разработки или даже текстовый редактор, при условии, что у вас есть доступ к IIS. Если же вы хотите воспользоваться всей мощью Microsoft .NET Framework и ASP.NET и при этом, затратить как можно меньше усилий, то нужно воспользоваться средой разработки, специально разработанной для программирования ASP.NET 2.0.

Если вы приобретете Visual Studio .NET 2005, то для работы достаточно будет только его. .NET Framework содержится на дисках. В его состав входит Visual Web Developer, который позволяет создавать профессиональные веб-приложения, а также desktop-приложения на разных языках программирования. Продукты Microsoft выпускаются на DVD, но есть набор из двух CD от «Мегасофт». Visual Studio .NET 2005 требует около 2 Гигабайт дискового пространства. При этом инсталлируется ASP.NET 2.0, среда разработки, SQL Server Express, встроенный веб-сервер, Crystal Reports со специальными элементами управления для ASP.NET 2.0.
Бесплатно распространяемое программное обеспечение.

Visual Web Developer 2005 Express Edition – свободно распространяемая среда предназначенный для новичков и студентов, доступная по адресу http://msdn.microsoft.com/vstudio/express/vwd/. Список отличий VWD от Visual Studio.NET 2005 невелик и для начинающих несущественен, он приведен здесь: http://msdn.microsoft.com/vstudio/products/compare/default.aspx

Инсталлятор VWD имеет объем 2,8 Мб, но в процессе инсталляции он загрузит еще 40 Мб и 80 Мб, если захотите установить документацию. При этом также будет установлен .NET Framework с ASP.NET 2.0.

Системные требования – процессор с минимальной скоростью 600 МГц, 128 МБ памяти и 1.3 ГБ дискового пространства. После инсталляции нужно будет зарегистрировать свою установку, это совершенно бесплатно.

В качестве среды разработки вы можете выбрать WebMatrix. Эта программа совмещает в себе редактор и http-сервер. Ее можно загрузить на http://www.asp.net/WebMatrix.

У WebMatrix инсталлятор размером всего 1.2 Мб, но у него меньше возможностей, чем у VWD. Но, в общем, эти среды разработки похожи. У WebMatrix есть неприятная особенность – она дает запрос на сохранение во время закрытия файлов, которые не редактировались. VWD Express позволяет одним нажатием кнопки открыть Web-интерфейс конфигурирования проекта. В VWD работает технология IntelliSense, которая автоматически предлагает возможные в данном месте элементы кода.

Если вы решили работать с WebMatrix, вы должны установить на своей машине .NET Framework 2.0 и ASP.NET 2.0.

Если у вас операционная система Windows Server 2003, то .NET Framework уже предустановлен. Вы можете проверить, есть ли вас директория %WINSDIR%Microsoft.NETFramework. Если нет, вы можете ее загрузить на сайте Microsoft. Последние версии находятся по адресу http://msdn.microsoft.com/netframework/downloads/updates

На данный момент это .NET Framework 2.0, но к моменту, когда вы будете читать эту лекцию, могут появиться более новые версии. Вы можете скачать новую версию, даже если у вас уже есть другая. Они будут существовать на компьютере одновременно в поддиректориях %WINSDIR%Microsoft.NETFramework, с именем, соответствующим номеру версии. Можно сказать, что каждая версия представляет собой сборку. Система версий поддерживается для всех приложений, созданных с использованием .NET Framework.

Там вы увидите ссылки на .NET Framework для разных архитектур компьютера.

При желании загрузите .NET Framework Version 2.0 SDK, которая содержит наряду с .NET Framework Version 2.0 SDK документацию и примеры, которые могут оказаться полезными.

По адресу http://asp.net/default.aspx можно найти много полезных для разработчиков программных продуктов, примеров кода и статей.

IIS(Internet Information Server) находится на инсталляционном диске Windows 2000/XP, но предустановлен только на серверах. Его можно установить, зайдя в Control Panel->Add or Remove Programs->Add/Remove Windows Components. Компьютер попросит вас вставить инсталляционный диск.

IIS может понадобиться, если вам нужен полноценный сервер для работы в интернет, а не просто на своем компьютере или в локальной сети или вы решили набирать текст в обычном редакторе. Для работы на своем компьютере во все эти среды разработки встроен сервер Cassini, который первоначально появился как часть WebMatrix. Символ WebMatrix – планета Сатурн, а Кассини — известный исследователь Сатурна. Предыдущие версии Visual Studio требовали наличия IIS, но теперь Cassini встроен и в Visual Studio 2005, что позволяет работать даже в Windows XP Home Edition.

Примеры будут даваться как для WebMatrix, так и Visual Studio. Некоторые примеры требуют VWD Express или Visual Studio.
Сообщества разработчиков.

Через меню помощи Visual Web Developer Express можно зайти на сайты форума по ASP.NET. А вот адреса сайтов на русском языке:

* http://www.aspnetmania.com
* http://www.gotdotnet.ru/
* http://www.sql.ru/
* http://dotsite.ru/
* http://www.rsdn.ru/

Вы можете завести пробный хостинг на http://europe.webmatrixhosting.net/russia/default.aspx.

Первый проект

Вначале решите, в какой директории будете создавать страницы. Все файлы, находящиеся в одной директории, считаются единым проектом.Запустите выбранную вами среду разработки. Выберите пункт меню File-New-Website. Появится диалоговое окно. Назначьте в нем имя проекта и выберите язык программирования С#.

По умолчанию проект создается в файловой системе. По желанию его можно создать на HTTP или FTP-сервере. Из файловой системы проект всегда можно скопировать на сервер нажатием одной кнопки в заголовке Solution Explorer.

В проекте будет создана страница default.aspx. Выберите ее, и появится окно редактирования с закладками Design и Source. Не меняя ничего, щелкните на кнопке со стрелкой, чтобы просмотреть страницу в браузере. Появится окно, котором спрашивается, нужно ли добавить в файл web.config возможность отладки. Нажмите OK. На панели задач должен появиться значок веб-сервера. Откроется браузер, показывающий страницу по адресу http://localhost:номерпорта/Website1/default.aspx. localhost обозначает сервер, работающий на вашем компьютере. Встроенный сервер Cassini сам назначает себе номер порта – для каждого проекта он разный. Сервер IIS обычно работает через порт 80(или 8080, если тот занят), и для него номер порта указывать не нужно. При этом ваша страница будет скомпилирована.

Пока что страница в бразере пустая.

Но исходный код этой страницы не пустой. Программа сгенерировала код для вас.

Почему ASP.NET не используют в крупных компаниях?

В настоящий момент С# (asp.net) имеет целый ряд преимуществ над тем, что нам дает Java (в плане удобства и синтаксиса языка). Это правда!

Проблема заключается в том, что Java появился раньше, Java был открытым для использования на Linux. В итоге под сервера на Java написали огромный список уникальных решений, которые сейчас используют топовые команды (посмотри, что такое хадуп, например). В итоге, компании либо не видели смысла переписывать все на C#, так как уже имели билды на Java, либо не хотели тратить время на разработку того, что уже есть на Java.

Именно по этой причине Microsoft сейчас активно начинает спариваться с Linux и везде кричит, что они его любят.

How To Create ASP.NET Core 2.0 Web App Visual Studio Code

In this blog post, I’ll show you how I create and ASP.NET Core 2.0 Web Application using Visual Studio Code on Window 10 machine.

About Visual Studio Core

Visual Studio Code Is a free source code editor for software development and was developed by Microsoft Corp.

First announced at Build 2015 conference and was released a few weeks later, the tool offers development environment for almost all software development languages using add-ins that can be downloaded easily.

Create ASP.NET Core 2.0 Web App

To create an ASP.NET Core 2.0 web application, open VSC and click on Open folder -> and create a new folder or used existing folder to store the new web app.

In my case, I create a folder called App02, next, I’ll open the Integrated Terminal

In the terminal window, I will type the line below to create a new Razor pages web Application

Dotnet new razor

Once the application build Is done, All I have to do to run my Web App Is to run the command below from the folder the application Is stored In.

To view the Web App I will browse to the location listed In run output.

Once run and build all files needed for the application will be created and will be available to be used

Изучение кэширования в ASP.NET

Written on 24 Января 2014 . Posted in ASP.NET

ОГЛАВЛЕНИЕ

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

Введение

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

Что такое кэширование?

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

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

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

Разные места кэширования

Кэширование в веб-приложении можно делать на стороне клиента (браузер клиента), между клиентом и сервером (кэширование в прокси и в обратном прокси), или на стороне сервера (кэширование данных/кэширование вывода страницы). Места кэширования классифицируются следующим образом:
1. Кэширование на клиенте
2. Кэширование в прокси
3. Кэширование в обратном прокси
4. Кэширование на веб-сервере

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

Рис. 1 : Кэширование на клиенте

Плюсы
1. Легкий доступ к данным, кэшированным на локальном клиенте
2. Уменьшает сетевой трафик

Минусы
1. Кэшированные данные полностью зависят от браузера, поэтому они не разделяемы
2. Кэширование в прокси: Основной недостаток кэширования на клиенте заключается в том, что данные, хранящиеся в браузере клиента, являются специфичными для клиента. Кэширование в прокси использует выделенный сервер, хранящий кэшированную информацию между клиентом и веб-сервером в разделяемом месте, так что все клиенты могут использовать одни и те же разделяемые данные. Прокси-сервер (например, прокси-сервер Microsoft) исполняет все запросы к веб-странице без отправки запроса к фактическому веб-серверу через интернет, обеспечивая более быстрый доступ.

Рис. 2: Кэширование в прокси

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

Рис. 3: Кэширующий массив

Плюсы
1. Легкий доступ к данным, кэшированным на прокси-сервере
2. Уменьшает сетевой трафик

Минусы
1. Требует развертывания и издержки инфраструктуры для обслуживания кэширующего прокси-сервера
2. Кэширование в обратном прокси: Можно поместить прокси-сервер перед веб-сервером, чтобы уменьшить количество получаемых им запросов. Это позволяет прокси-серверу отвечать на часто получаемые запросы и передавать веб-серверу только остальные запросы. Это называется обратным прокси.

Рис. 4: Кэширование в обратном прокси

Плюсы
1. Легкий доступ к данным, кэшированным на обратном прокси-сервере
2. Уменьшает количество запросов

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

Рис. 5: Кэширование на веб-сервере

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

Минусы
1. Увеличивает нагрузку на сеть

Преимущества кэширования
1. Уменьшает нагрузку на сервер
2. Уменьшает потребление полосы пропускания

Возможность кэширования в ASP.NET

ASP.NET поддерживает кэширование страницы, неполной страницы (фрагмента) и кэширование данных. Кэширование динамически генерируемой страницы называется кэшированием вывода страницы. При кэшировании страницы, когда кэшируется динамически генерируемая страница, к ней обращаются только в первый раз. Любое последующее обращение к той же самой странице будет возвращаться из кэша. ASP.NET также позволяет кэшировать часть страницы, что называется кэшированием неполной страницы или кэшированием фрагмента. Кэшируются другие данные сервера (например, данные сервера SQL, данные XML), к которым можно легко обратиться без повторного извлечения данных с помощью кэширования данных. Кэширование уменьшает число запросов «туда-обратно» к базе данных и другим источникам данных. ASP.NET предоставляет полноценный механизм кэширования данных, снабженный поддержкой уборки мусора (на базе приоритета кэша), истечения, зависимостей от файла, ключа и времени. Есть два места, где кэширование может использоваться для повышения производительности приложений ASP.NET.

Рис 6: Возможность кэширования в ASP.NET

На рисунке выше (1) используется для возвратного кэширования страницы, то есть он используется в кэшировании вывода, и (2) избавляет от передачи данных туда-обратно путем хранения данных с помощью кэширования данных.

ASP.NET поддерживает два типа политик истечения, определяющих, когда объект истекает или удаляется из кэша.

Абсолютное истечение: Определяет, что истечения происходят в указанное время. Абсолютные истечения задаются в формате полного времени (чч:мм:сс). Объект будет удален из кэша в указанное время.

Разные типы кэширования

ASP.NET поддерживает три типа кэширования:
1. Кэширование вывода страницы [кэширование вывода]
2. Кэширование фрагмента [кэширование вывода]
3. Кэширование данных

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

Чтобы начать кэширование вывода страницы, надо знать процесс компиляции страницы, потому что исходя из генерации страницы можно понять, почему следует использовать кэширование. Процесс компиляции страницы ASPX двухэтапный. Сначала код компилируется в промежуточный язык Microsoft (MSIL). Далее MSIL компилируется в собственный код (оперативным компилятором) при выполнении. Весь код в странице ASP.NET компилируется в MSIL при построении сайтов, но в момент выполнения преобразуется в собственный код только часть MSIL, необходимая пользователю, и выполняются запросы пользователя, что повышает производительность.

Рис. 7: Процесс выполнения страницы ASP.NET

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

Рис. 8: Кэширование вывода страницы

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

Для кэширования вывода директива OutputCache добавляется на любую страницу ASP.NET с заданием длительности (в секундах) кэширования страницы.

Пример

Также можно установить свойство кэширования из отделенного кода:

Надо указать длительность и атрибут VaryByParam. Длительность определяет, как долго кэш будет сохраняться. VaryByParam определяет, меняется ли кэш со значениями параметра.

Рис. 9: Кэширование нескольких страниц на базе параметров

Как показано на рисунке выше, если для страницы используется строка запроса, и надо кэшировать все страницы на базе строки запроса, то придется использовать атрибут VaryByParam кэширования вывода. На базе строки запроса данные должны кэшироваться, и когда пользователь запрашивает страницу со строкой запроса (ID на рисунке), страница извлекается из кэша. Следующий пример описывает использование атрибутов VaryByParam.

Пример:

Следующая таблица показывает самые распространенные и самые важные атрибуты кэша вывода:

Идентификатор ASP.Net 2, двухфакторный код безопасности

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

Есть ли способ настроить это окно времени для кода 2FA?

Думаю, вам нужно изменить срок действия в UserTokenProvider .

Попробуйте выполнить следующие действия в UserManager :

Технология 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-элементы, реализованные на сервере, и встроенные элементы:

Метод Описание
Initialize()
HTML-элементы Встроенные элементы
, ,

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

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

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

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

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

Данные советы вводят в проблему повышения производительности работы приложений, использующих технологии 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-тег

. Так что проверьте ваш браузер на этот счет. Чтобы обойти эту проблему, попробуйте разделить таблицу на несколько более меньших таблиц (с меньшим количеством строк) и вызывать 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). Каждое из перечисленного позволяет улучшить выполнение работы и увеличить надежность.

ASP.Net — App_Data & App_Code folders?

What is the point of having App_code & App_data folders?

Why doesn’t my objectDataSource detect classes unless files are in App_Code?

Please provide as much detail as you can, I’m new to ASP.Net

3 Answers 3

These folders have special purpose. From this article — ASP.NET Web project folder structure.

App_Code contains source code for shared classes and business objects (for example, ..cs, and .vb files) that you want to compile as part of your application. In a dynamically compiled Web site project, ASP.NET compiles the code in the App_Code folder on the initial request to your application. Items in this folder are then recompiled when any changes are detected.

Note : You can add any type of class file to the App_Code folder in order to create strongly typed objects that represent those classes. For example, if you put Web service files (.wsdl and .xsd files) in the App_Code folder, ASP.NET creates strongly typed proxies for those classes.

Code in the App_Code folder is referenced automatically in your application. The App_Code folder can contain sub-directories of files, which can include class files that in different programming languages.

Что такое Web API?

Web API – новая исполяющая среда веб-приложения, построенная на уроках и паттернах, одобренных в ASP.NET MVC. Используя простую парадигму контроллеров, Web API позволяет разработчику создавать простые Web API веб-службы с небольшим по объему кодом и конфигурацией.

Вы можете задать очень разумный вопрос: почему нам нужен новый фреймворк веб-служб? Не входит ли уже в стек разработки компании Microsoft популярная и широко совместимая технология Simple Object Access Protocol (SOAP) (простой протокол доступа к объектам)? И не существовали ли ASMX веб-службы с тех самых пор, как был выпущен ASP.NET? И не поддерживает ли уже Windows Communication Foundation (WCF) самую гибкую и расширяемую архитектуру веб-служб? Веб-службы являются повсеместными, и разработчики понимают их. Почему Web API?

Почему Web API?

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

  • Я верю в то, что существует лучший способ создания веб-служб.
  • Я верю, что веб-службы могут быть простыми и что WCF слишком сложен.
  • Я верю, что в будущем мне нужно будет поддерживать больше HTTP клиентов.
  • Я верю, что основных веб-технологий таких, как GET , POST , PUT и DELETE , достаточно.

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

Чем Web API отличается от WCF?

ASMX веб-службы на протяжении многих лет поддерживали SOAP веб-службы поверх HTTP, но они не без труда поддерживали более простые веб-службы, которым не нужно было наличие способности взаимодействовать и, таким образом, для них не нужен был SOAP. WCF занял место ASMX как самый последний и лучший способ создания веб-служб на стеке .NET. WCF службы для конечных точек HTTP похожи на следующий код.

Листинг 24-1: Для WCF служб требуется интерфейс, класс и множество атрибутов

Строка 2: Интерфейс определяет службу

Строка 4: Атрибуты определяют операции

Строка 11: Отдельный класс реализует логику службы

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

Запуская эту службу в Visual Studio, вы можете использовать тестовый клиент WCF для того, чтобы увидеть запрос и отклик операции GetData , как это продемонстрировано на рисунке 24-1.

Рисунок 24-1: Тестовый клиент WCF может помочь вам протестировать SOAP веб-службу с помощью WCF.

В рамках отрасли многие разработчики прилагают усилия для упрощения WCF HTTP веб-служб. Многие говорят о RESTful-стиле (Representational State Transfer – репрезентативная передача состояния), который был введен для того, чтобы обозначать использование простейших HTTP веб-служб без всяких украшательств.

ASP.NET Web API использует понятие обычного MVC контроллера и базируется на нем для того, чтобы создать для разработчика простое и продуктивное событие. Web API оставляет SOAP в истории как средство, которое используют приложения для взаимодействия. На сегодняшний момент, из-за повсеместного использования HTTP, большинство рабочих сред и систем программирования поддерживают основные принципы HTTP веб-коммуникации. В связи с тем, что вопрос совместимости решается другими способами, SOAP может быть отодвинут в сторону возрастающими технологиями наследования, а разработчики могут быстро создавать простые HTTP веб-службы (web APIs) с помощью ASP.NET Web API фреймворка.

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

Листинг 24-2: Web API обладает очень простым стилем программирования с ApiController

Строка 4: Базовый класс разрешает основную функциональность

Строка 7: Простые методы определяют операции

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

Возврат значения в рамках Web API схож с использованием WCF, но результат совершенно другой. Вы можете увидеть результат, запуская проект в Visual Studio и тестируя его с помощью веб-браузера. Помните, что одним из основополагающих убеждений, касающихся Web API, является тот факт, что веб-службы могут быть простыми. Перейдите с помощью Internet Explorer по адресу http://localhost:/api/values/43 , содержащий средства разработки (нажмите F12 ). На рисунке 24-2 продемонстрировано, что получится в результате.

Рисунок 24-2: Используются HTTP заголовки вместо SOAP конверта.

Вместо того чтобы возвращать SOAP XML , как это делается в WCF, используется более простой формат, JavaScript Object Notation (JSON). Этот формат силен в передаче единичных значений, а также структур сложных объектов. Поскольку язык JavaScript понимает этот формат, jQuery может принимать этот тип данных для использования в AJAX вызовах.

Теперь, когда вы увидели отличие WCF от Web API, давайте начнем добавлять некоторую интересную функциональность поверх приложения «Guestbook» из главы 2.

Илон Маск рекомендует:  scrollbar-track-color в CSS
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL