28 правил оптимизации производительности ASP, рекомендованных Microsoft

Производительность — это особенность. Вам необходимо заранее спроектировать производительность, иначе вам придется переписывать приложение позже. Тем не менее, каковы хорошие стратегии для максимизации производительности приложений Active Server Pages (ASP)?

В этой статье описываются методы оптимизации приложений ASP и Visual Basic® Scripting Edition (VBScript). В этой статье рассматривается ряд подводных камней. Предложения, перечисленные в этой статье, были протестированы на http://www.microsoft.com и других сайтах, и результаты оказались весьма значительными. В этой статье предполагается, что у вас уже есть базовое понимание разработки ASP, включая VBScript и/или JScript, приложение ASP, сеанс ASP и другие встроенные объекты ASP (запрос, ответ и сервер).

Обычно производительность ASP зависит в первую очередь от многих факторов, помимо самого кода ASP. Вместо того, чтобы перечислять всю информацию в одной статье, мы перечисляем ресурсы, связанные с производительностью, в конце статьи. Эти ссылки охватывают темы ASP и не-ASP, включая объекты данных ActiveX® (ADO), объектную модель компонентов (COM), базы данных и конфигурацию информационного сервера Интернета (IIS). Это некоторые из наших любимых ссылок — обязательно просмотрите их.

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

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

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

Данные, которые изменяются нечасто, являются хорошими кандидатами для кэширования, поскольку вам не нужно беспокоиться о синхронизации этих данных с базой данных с течением времени. Списки полей со списком, справочные таблицы, фрагменты DHTML, строки расширяемого языка разметки (XML), элементы меню и переменные конфигурации сайта (включая имена источников данных (DSN), адреса интернет-протокола (IP) и веб-пути) — все это хорошие кэши. содержание. Обратите внимание, что вы можете кэшировать «представление» данных, не кэшируя сами данные. Если страница ASP меняется редко и ее кэширование требует больших затрат (например, весь каталог продуктов), вам следует рассмотреть возможность создания HTML заранее, а не повторно отображать его в ответ на каждый запрос.

Где следует кэшировать данные и какие существуют стратегии кэширования? Обычно данные кэшируются в памяти или на диске веб-сервера. Следующие два совета охватывают оба метода.

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

Объекты ASP Application и Session предоставляют удобные контейнеры для кэширования данных в памяти. Вы можете назначить данные объектам «Приложение» и «Сессия», и данные останутся в памяти между вызовами HTTP. Данные сеанса хранятся отдельно для каждого пользователя, а данные приложения доступны всем пользователям.

Когда данные следует загружать в приложение или сеанс? Обычно данные загружаются при запуске приложения или сеанса. Чтобы загрузить данные во время запуска приложения или сеанса, добавьте соответствующий код в Application_OnStart() или Session_OnStart() соответственно. Эти функции должны быть в Global.asa, если нет, вы можете их добавить. Эти данные также можно загрузить при первой необходимости. Для этого добавьте на страницу ASP некоторый код (или напишите функцию сценария многократного использования), чтобы проверить, существуют ли данные, и, если нет, загрузить данные. Это традиционная техника повышения производительности, называемая «ленивой оценкой»: не вычислять значение до тех пор, пока не поймете, что оно вам нужно. Например:

<%
Функция GetEmploymentStatusList
Дим д
d = Приложение(?EmploymentStatusList?)
Если d = ??Тогда
' Функция FetchEmploymentStatusList (не показана)
' извлекает данные из БД, возвращает массив
d = FetchEmploymentStatusList()
Приложение(?EmploymentStatusList?) = d
Конец, если
GetEmploymentStatusList = d
Конечная функция
%>
Аналогичные функции могут быть написаны для каждого требуемого блока данных.

В каком формате следует хранить данные? Можно сохранить любой тип варианта, поскольку все переменные сценария являются вариантными типами. Например, вы можете хранить строки, целые числа или массивы. Обычно содержимое набора записей ADO сохраняется в одном из этих типов переменных. Чтобы получить данные из набора записей ADO, вы можете вручную скопировать данные в переменные VBScript по одному полю за раз. Быстрее и проще использовать одну из функций сохранения набора записей ADO GetRows(), GetString() или Save() (ADO 2.5). Подробности выходят за рамки этой статьи, но вот пример функции, которая использует GetRows() для возврата массива данных набора записей:

' Получить набор записей, вернуть как массив
Функция FetchEmploymentStatusList
Димры
Установите rs = CreateObject(?ADODB.Recordset?)
rs.Open ?выберите StatusName, StatusID из статуса сотрудника?, _
?dsn=сотрудники;uid=sa;pwd=;?
FetchEmploymentStatusList = rs.GetRows() Возвращать данные в виде массива
rs.Close
Setrs=Ничего
End Function

дополнительно улучшает приведенный выше пример, кэшируя HTML в виде списка, а не массива. Вот простой пример:

'Получить набор записей, вернуть как список параметров HTML
Функция FetchEmploymentStatusList
Dim rs, fldName, s
Установите rs = CreateObject(?ADODB.Recordset?)
rs.Open ?выберите StatusName, StatusID из статуса сотрудника?, _
?dsn=сотрудники;uid=sa;pwd=;?
s = ?<select name=??EmploymentStatus??> & vbCrLf
Set fldName = rs.Fields(?StatusName?) ' Привязка поля ADO
Делать до rs.EOF
' Следующая строка нарушает правило Don't Do String Concats,
' но это нормально, потому что мы создаем кеш
s = s & ? <опция>? & имя_файла & ?</опция>?
rs.MoveNext
Петля
s = s & ?</select> & vbCrLf
rs.Close
Set rs = Nothing 'См. ранний выпуск
FetchEmploymentStatusList = s ' Возвращает данные в виде строки
Конечная функция
При соответствующих условиях сам набор записей ADO может быть кэширован в области приложения или сеанса. Есть два предостережения:

ADO должен быть помечен как свободнопоточный и необходимо использовать отключенные наборы записей.
Если эти два требования не гарантируются, не кэшируйте набор записей ADO. В следующих советах «Негибкие компоненты» и «Не кэшируйте соединения» мы обсуждаем опасности хранения COM-объектов в области приложения или сеанса.

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

<%
'обработка ошибки не отображается...
Const UPDATE_INTERVAL = 300 'Интервал обновления, в секундах

' Функция для возврата списка статуса занятости
Функция GetEmploymentStatusList
Обновление статуса занятости
GetEmploymentStatusList = Приложение(?EmploymentStatusList?)
Конечная функция

'Периодическое обновление кэшированных данных
Sub UpdateEmploymentStatusList
Dim d, strLastUpdate
strLastUpdate = Приложение(?LastUpdate?)
Если (strLastUpdate = ??) Или _
(UPDATE_INTERVAL < DateDiff(?s?, strLastUpdate, Now)) then

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

' Функция FetchEmploymentStatusList (не показана)
' извлекает данные из БД, возвращает массив
d = FetchEmploymentStatusList()

' Обновляем объект Application. Используйте Application.Lock().
', чтобы обеспечить согласованность данных
Приложение.Блокировка
Приложение(?EmploymentStatusList?) = События
Приложение(?LastUpdate?) = CStr(сейчас)
Приложение.Разблокировка
Конец, если
Конец субтитра
См. «Самый быстрый в мире список с данными приложения», где также есть пример.

Имейте в виду, что кэширование больших массивов в объектах сеанса или приложения не является хорошей практикой. Синтаксис языка сценариев требует, чтобы весь массив был временно скопирован перед доступом к любому элементу массива. Например, если вы кэшируете массив строк из 100 000 элементов, который сопоставляет почтовые индексы США с местными метеостанциями в объекте приложения, ASP должен сначала скопировать все 100 000 метеостанций во временный массив. Только после этого можно извлечь строку. В этом случае было бы лучше создать собственный компонент с собственным методом для хранения метеостанции или использовать компонент словаря.

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

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

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

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

ASP и COM предоставляют инструменты для настройки решений дискового кэширования. Функции набора записей ADO Save() и Open() сохраняют и загружают наборы записей с диска. Вы можете использовать эти методы, чтобы переписать пример кода в описанном выше методе кэширования данных приложения, используя Save() файла вместо записи кода в объект Application.

Есть еще несколько компонентов, которые работают с файлами:

Scripting.FileSystemObject позволяет создавать, читать и записывать файлы.
Анализатор XML Microsoft® (MSXML), входящий в состав Internet Explorer, поддерживает сохранение и загрузку документов XML.
Объект LookupTable (используемый, например, в MSN) — лучший выбор для загрузки простых списков с диска.
Наконец, рассмотрите возможность кэширования представления данных на диске, а не самих данных. Предварительно преобразованный HTML-код можно хранить на диске в файлах .htm или .asp, а гиперссылки могут указывать непосредственно на эти файлы. Вы можете использовать коммерческие инструменты, такие как XBuilder или функцию публикации в Интернете Microsoft® SQL Server®, чтобы автоматизировать процесс создания HTML. Альтернативно вы можете поместить фрагмент кода HTML в файл .asp. Вы также можете использовать FileSystemObject для чтения файлов HTML с диска или использовать XML для их раннего преобразования.

Совет 4. Избегайте кэширования негибких компонентов в объектах приложения или сеанса.

Хотя кэширование данных в объектах приложения или сеанса является хорошей практикой, кэширование COM-объектов имеет серьезные недостатки. Обычно люди склонны кэшировать часто используемые COM-объекты в объекты Application или Session. К сожалению, многие COM-объекты (включая все объекты, написанные на Visual Basic 6.0 или более ранних версиях) вызывают серьезные узкие места при хранении в объектах Application или Session.

В частности, когда какой-либо негибкий компонент кэшируется в объекте сеанса или приложения, это приводит к снижению производительности. Гибкий компонент — это компонент, отмеченный ThreadingModel=Both, который объединяет упаковщик с свободной резьбой (FTM), или компонент, отмеченный ThreadingModel=Neutral; (Нейтральная модель является новой для Windows® 2000 и COM+.) Следующие компоненты не являются гибкими:

Компоненты со свободным потоком (если они не объединяют FTM).
Компоненты квартирной резьбы.
Однопоточный компонент.
Настроенные компоненты (библиотеки Microsoft Transaction Server (MTS)/COM+ и серверные пакеты/приложения) не являются гибкими, если они не являются нейтральными потоками. Компоненты с многопоточной структурой и другие негибкие компоненты лучше всего подходят на уровне страницы (то есть они создаются и уничтожаются на одной странице ASP).

В IIS 4.0 компоненты, отмеченные ThreadingModel=Both, считаются гибкими. В IIS 5.0 одного этого недостаточно. Компоненты должны быть не только отмечены как «Оба», но также должны быть агрегированы FTM. В статье об гибкости описывается, как агрегировать FTM с компонентами C++, написанными в библиотеке активных шаблонов. Имейте в виду, что если компонент кэширует указатели интерфейса, сами эти указатели должны быть гибкими или должны храниться в таблице общего интерфейса COM (GIT). Если вы не можете перекомпилировать компонент «Оба потока» для агрегирования FTM, вы можете пометить компонент с помощью ThreadingModel=Neutral. Альтернативно, если вы не хотите, чтобы IIS выполнял проверки гибкости (поэтому вы можете разрешить сохранение негибких компонентов в области приложения или сеанса), вы можете установить для AspTrackThreadingModel значение True в метабазе. Изменение AspTrackThreadingModel не рекомендуется.

IIS 5.0 выдаст ошибку, если вы хотите сохранить негибкий компонент, созданный с помощью Server.CreateObject, в объекте приложения. Эту ошибку можно избежать, используя <object runat=serverscope=application ...> в Global.asa, но это не рекомендуется, поскольку это может привести к объединению в пулы и сериализации, описанным ниже.

Что произойдет, если вы кэшируете негибкие компоненты? Негибкие компоненты, кэшированные в объекте сеанса, привязывают сеанс к рабочему потоку ASP. ASP поддерживает пул рабочих потоков для обработки запросов. Обычно новый запрос всегда обрабатывается первым доступным рабочим потоком. Если сеанс привязан к потоку, запрос должен дождаться, пока соответствующий поток не станет доступен. Вот аналогия, которая может вам помочь: вы идете в супермаркет, выбираете какие-то товары и платите на кассе №_3. После этого всякий раз, когда вы платите за товар в этом супермаркете, вам всегда придется платить на кассе №_3, даже если на других кассах очередей меньше или вообще нет.

Хранение негибких компонентов в области приложения оказывает еще худшее влияние на производительность. ASP должен создать специальный поток для запуска негибких компонентов, хранящихся в области приложения. Это имеет два последствия: все вызовы должны направляться в этот поток и все вызовы помещаются в очередь. «Объединение» означает, что параметры должны храниться в общей области памяти; выполнить дорогостоящее переключение контекста в специальный поток; выполнить метод компонента; объединить результаты в общую область; выполнить еще одно дорогостоящее переключение контекста, возврат управления; в исходную ветку. «Сериализация» означает, что одновременно запускается только один метод. Два разных рабочих потока ASP не могут одновременно выполнять несколько методов для общего компонента. Это исключает параллелизм, особенно на многопроцессорных компьютерах. Что еще хуже, все компоненты, не относящиеся к Agile-приложению, используют один поток (хост STA), поэтому влияние сериализации еще более значительно.

Что я могу сделать? Вот некоторые общие правила. Если вы пишете объекты с использованием Visual Basic (6.0) или более ранней версии, не кэшируйте их в объектах Application или Session. Если вы не знаете модель потоков объекта, не кэшируйте его. Не кэшируйте негибкие объекты, а создавайте и выпускайте их на каждой странице. Объекты выполняются непосредственно в рабочем потоке ASP, поэтому объединение в пул или сериализация отсутствуют. Если COM-объекты выполняются на сервере IIS, производительность приемлема, если их инициализация и удаление не занимают много времени. Обратите внимание, что однопоточные объекты не следует использовать таким образом. Будьте осторожны — VB может создавать однопоточные объекты! Если вам необходимо использовать такой однопоточный объект (например, электронную таблицу Microsoft Excel), не ждите высокой пропускной способности.

Если ADO помечен как многопоточный, наборы записей ADO можно безопасно кэшировать. Чтобы пометить ADO как свободнопоточный, используйте файл Makfre15.bat, который обычно находится в каталоге \Program FilesCommonSystemADO.

Предупреждение. Если в качестве базы данных вы используете Microsoft Access, вам не следует помечать ADO как многопоточную. Набор записей ADO также необходимо отключить. В общем, если вы не контролируете конфигурацию ADO на своем сайте (например, вы являетесь независимым поставщиком программного обеспечения [ISV] и продаете веб-приложения клиентам, которые сами управляют своими конфигурациями), лучше не кэшировать наборы записей.

Компоненты словаря также являются гибкими объектами. LookupTable загружает свои данные из файла данных и может использоваться для данных поля со списком и информации о конфигурации. Объект PageCache в Duwamish Books обеспечивает синтаксис словаря, как и словарь Caprock. Эти объекты или их производные объекты могут составить основу эффективной стратегии кэширования. Обратите внимание, что объекты Scripting.Dictionary не являются гибкими и не должны храниться в областях приложения или сеанса.

Совет 5. Не кэшируйте соединения с базой данных в объекте «Приложение» или «Сессия»

. Кэширование соединений ADO, как правило, является плохой стратегией. Если объект «Соединение» хранится в объекте «Приложение» и используется на всех страницах, то все страницы будут конкурировать за это соединение. Если объект Connection хранится в объекте ASP Session, для каждого пользователя будет создано соединение с базой данных. Это сведет на нет преимущества объединения в пул соединений и создаст ненужную нагрузку на веб-сервер и базу данных.

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

Поскольку подключенный набор записей хранит ссылку на подключение к базе данных, не следует кэшировать подключенный набор записей в объекте «Приложение» или «Сеанс». Однако вы можете безопасно кэшировать отключенные наборы записей, которые не содержат ссылки на подключение к данным. Чтобы отключить набор записей, выполните следующие два шага:

Установите rs = Server.CreateObject(?ADODB.RecordSet?)
rs.CursorLocation = adUseClient ' шаг 1

' Заполнение набора записей данными
rs.Open strQuery, strProv

' Теперь отключите набор записей от поставщика и источника данных.
rs.ActiveConnection = Ничего ' шаг 2
Более подробную информацию о пуле соединений можно найти в справочном материале по ADO и SQL Server.

Совет 6: Правильно используйте объекты сеанса

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

Короче говоря, ASP автоматически создает сеанс для каждого пользователя, обращающегося к веб-серверу. Каждая сессия требует около 10 КБ накладных расходов памяти (главное, чтобы данные хранились в сессии), что замедляет все запросы. Сеанс остается действительным до истечения настроенного периода ожидания (обычно 20 минут).

Самая большая проблема Session — не производительность, а масштабируемость. Сеанс не может охватывать несколько веб-серверов. После создания сеанса на одном сервере его данные остаются там. Это означает, что если вы используете сеанс в ферме веб-серверов, вы должны разработать политику, которая всегда отправляет каждый пользовательский запрос на сервер, на котором расположен сеанс пользователя. Это называется «приклеиванием» пользователя к веб-серверу. Отсюда произошел термин «липкая сессия». В случае сбоя веб-сервера «застрявшие» пользователи потеряют состояние своего сеанса, поскольку сеанс не закрепился на диске.

Стратегии достижения липких сеансов включают в себя аппаратные и программные решения. Такие решения, как балансировка сетевой нагрузки в Windows 2000 Advanced Server и Cisco Local Director, могут реализовать закрепленные сеансы за счет некоторой степени масштабируемости. Эти решения несовершенны. В настоящее время не рекомендуется развертывать собственное программное решение (раньше мы использовали фильтры ISAPI, преобразования URL-адресов и т. д.).

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

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

Если вы не используете сеансы, обязательно закройте их. Вы можете сделать это для приложения через Internet Services Manager (см. документацию ISM). Если вы решите использовать сеансы, есть способы смягчить их влияние на производительность.

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

<% @EnableSessionState=False %>

Хорошая причина для использования этого Директива заключается в том, что у этих сессий есть интересная проблема с наборами фреймов. ASP гарантирует, что в каждый момент времени в сеансе выполняется только один запрос. Это гарантирует, что если браузер запрашивает несколько страниц для пользователя, только один запрос ASP затрагивает сеанс одновременно, что позволяет избежать проблем многопоточности, возникающих при доступе к объекту сеанса. К сожалению, все страницы в наборе фреймов будут отображаться последовательно, одна за другой, а не одновременно. Пользователям, возможно, придется долго ждать, чтобы увидеть все кадры. Мораль этой истории: если некоторые страницы набора фреймов не полагаются на сеанс, обязательно сообщите об этом ASP, используя директиву @EnableSessionState=False.

Существует множество способов управления состоянием сеанса, которые могут заменить использование объектов сеанса. Для небольших объемов состояния (менее 4 КБ) мы обычно рекомендуем использовать файлы cookie, переменные QueryString и неявные переменные. Для больших объемов данных, таких как корзины покупок, серверная база данных является наиболее подходящим выбором. Много было написано о методах управления состоянием в фермах веб-серверов. Дополнительные сведения см. в разделе Справочник по состоянию сеанса.

Совет 7. Инкапсулируйте код в COM-объекты.

Если у вас много VBScript или JScript, вы часто можете повысить производительность, переместив свой код в скомпилированные COM-объекты. Скомпилированный код обычно работает быстрее, чем интерпретируемый. Скомпилированные COM-объекты могут получать доступ к другим COM-объектам посредством «раннего связывания», которое является более эффективным методом вызова COM-объектов, чем «позднее связывание», используемое сценариями.

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

COM-объекты помогают отделить логику представления от бизнес-логики.
COM-объекты обеспечивают повторное использование кода.
Многие разработчики считают, что код, написанный на VB, C++ или Visual J++, легче отлаживать, чем ASP.
COM-объекты также имеют недостатки, в том числе время начальной разработки и необходимость различных навыков программирования. Обратите внимание, что инкапсуляция небольшого количества ASP может привести к снижению производительности без улучшения производительности. Такая ситуация обычно возникает, когда небольшой объем кода ASP инкапсулируется в COM-объект. В этом случае затраты на создание и вызов COM-объекта перевешивают преимущества скомпилированного кода. Методом проб и ошибок следует определить, какая комбинация сценария ASP и объектного кода COM обеспечивает наилучшую производительность. Обратите внимание, что производительность сценариев и ADO в Windows 2000/IIS 5.0 существенно улучшена по сравнению с Microsoft Windows NT&reg; Таким образом, с появлением IIS 5.0 преимущество в производительности скомпилированного кода над кодом ASP уменьшилось.

Подробное обсуждение преимуществ и недостатков использования COM в ASP см. в разделе Рекомендации по компонентам ASP и программирование распределенных приложений с помощью Microsoft Visual Basic 6.0. Если вы развертываете COM-компоненты, особенно важно тестировать их под нагрузкой. Фактически, все приложения ASP должны подвергаться нагрузочному тестированию как нечто само собой разумеющееся.

Совет 8: Получите ресурсы позже и освободите их раньше.

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

Этот метод оптимизации в основном используется для соединений и наборов записей ADO. Когда вы закончите работу с набором записей, скажем, после отображения таблицы и ее данных, вам следует освободить его немедленно, а не ждать конца страницы. Лучше всего установить для переменной VBScript значение Nothing. Не позволяйте набору записей выходить за рамки. Кроме того, освободите все связанные объекты Command или Connection (не забудьте вызвать Close() перед тем, как установить для набора записей или соединения значение = Nothing). Это сокращает время, необходимое базе данных для подготовки ресурсов, и максимально быстро освобождает соединение базы данных с пулом соединений.

Совет 9: Внепроцессное исполнение меняет производительность на надежность

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

Параметры ASP настраивают приложения ASP для запуска одним из трех способов. В IIS 5.0 для описания этих параметров был введен термин «уровень изоляции». Три уровня изоляции: низкий уровень, средний уровень и высокий уровень:

изоляция низкого уровня. Это поддерживается во всех версиях IIS и является самым быстрым. Он запускает ASP в Inetinfo.exe, который является основным процессом IIS. Если приложение ASP выйдет из строя, то же произойдет и с IIS. (Чтобы перезапустить IIS под IIS 4.0, администратор веб-сайта должен контролировать сайт с помощью такого инструмента, как InetMon, и включить пакетный файл для перезапуска сервера в случае сбоя сервера. В IIS 5.0 введен надежный перезапуск, который позволяет автоматически перезапускать вышедший из строя сервер. ).
Промежуточная изоляция. В IIS 5.0 появился этот новый уровень, который называется уровнем вне процесса, поскольку ASP работает вне процесса IIS. При промежуточной изоляции все приложения ASP, настроенные для работы в режиме промежуточной изоляции, совместно используют пространство процесса. Это уменьшает количество процессов, необходимых для запуска нескольких внепроцессных приложений ASP на одном сервере. Средняя изоляция — это уровень изоляции по умолчанию в IIS 5.0.
Расширенная изоляция. Этот уровень поддерживается в IIS 4.0 и IIS 5.0, а расширенная изоляция также осуществляется вне процесса. Если ASP выйдет из строя, веб-сервер не выйдет из строя. Приложение ASP автоматически перезапустится при следующем запросе ASP. При расширенной изоляции каждое приложение ASP, настроенное для работы в режиме расширенной изоляции, выполняется в собственном пространстве процессов. Это защитит приложения ASP от взаимодействия друг с другом. Недостаток заключается в том, что для каждого приложения ASP требуется отдельный процесс. Когда множество приложений должно работать на одном сервере, накладные расходы системы значительно возрастают.
Какой вариант лучше? В IIS 4.0 исчерпание процесса значительно снижает производительность. В IIS 5.0 было внесено множество улучшений, направленных на минимизацию накладных расходов, вызванных запуском приложений ASP вне процесса. Фактически, в подавляющем большинстве тестов внепроцессные приложения ASP в IIS 5.0 работали быстрее, чем внутрипроцессные приложения в IIS 4.0. В любом случае, на обеих платформах лучше всего работает внутрипроцессный процесс (низкий уровень изоляции). Однако если скорость доступа относительно низкая или максимальная пропускная способность низкая, преимущества низкого уровня изоляции менее очевидны. Таким образом, установка низкого уровня изоляции может быть необходима только в том случае, если вам требуются сотни или тысячи страниц в секунду на каждый веб-сервер. Как всегда, протестируйте несколько конфигураций, чтобы определить, на какой компромисс вы хотите пойти.

Обратите внимание, что когда вы запускаете внепроцессные приложения ASP (средняя или высокая изоляция), они запускаются в MTS в NT4 и в COM+ в Windows 2000. То есть в NT4 они запускаются в Mtx.exe, в Windows 2000 — в DllHost.exe; Вы можете увидеть эти процессы в диспетчере задач. Вы также можете увидеть, как IIS настраивает пакет MTS или приложение COM+ для внепроцессного приложения ASP.

Параметры COM Компоненты COM также имеют три параметра конфигурации, хотя они не совсем похожи на параметры ASP. Компоненты COM могут быть «ненастроенными», настроенными как библиотечные приложения или как серверные приложения. «Ненастроено» означает, что компонент не зарегистрирован в COM+. Компоненты будут выполняться в пространстве процесса вызывающей программы, то есть они находятся «в процессе». Библиотечные приложения также находятся в процессе разработки, но используют службы COM+, включая безопасность, транзакции и поддержку контекста. Серверные приложения настроены для работы в собственном пространстве процессов.

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

ловушка! При использовании приложения сервера COM, если вы передаете объекты между ASP и COM, убедитесь, что объекты выполняют «объединение по значению» или MBV. Объекты, выполняющие MBV, копируют себя из одного процесса в другой. Это лучше, чем подход, при котором объект все еще находится в процессе создателя, а другой процесс повторно вызывает процесс создания, чтобы использовать объект. Отключенный набор записей ADO будет «кластеризован по значению», а подключенный набор записей — нет. Scripting.Dictionary не выполняет MBV и не передается между процессами. Наконец, примечание для программистов VB: MBV не получается путем передачи параметра ByVal. MBV выполняется автором оригинального компонента.

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

В IIS 4.0 используйте низкий уровень изоляции ASP и используйте пакет сервера MTS.
В IIS 5.0 используйте средний уровень изоляции ASP и приложение библиотеки COM+.
Это очень общие принципы; хостинговые компании обычно используют ASP на среднем или высоком уровне изоляции, тогда как специализированные веб-серверы могут работать на низких уровнях изоляции. Взвесьте все «за» и «против» и решите сами, какая конфигурация лучше соответствует вашим потребностям.

Совет 10: Используйте

опцию явного параметра. Эта директива находится в верхней части файла .asp и заставляет разработчика объявить все переменные, которые будут использоваться. Многие программисты считают этот метод полезным для отладки приложений, потому что он позволяет избежать возможности ошибок имен переменных и случайного создания новых переменных (например, myxmlstring =) вместо myxlmstring = ....

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

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

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

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

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

В общем, если вы планируете получить доступ к данным объекта более одного раза, вам следует поместить данные в переменные сценария. Основной целью этой оптимизации являются переменные запроса (переменные формы и запроса). Например, ваш сайт может передать переменную QueryString с именем userId. Допустим, это указано в пользовательском имиде 12 раз на конкретной странице. Вместо вызова запроса (? UserId?) 12 раз вы можете назначить userID переменной в верхней части страницы ASP. Затем используйте эту переменную на всей территории страницы. Это сохраняет 11 вызовов метода COM.

На самом деле, доступ к свойствам или методам COM не так дорого. Вот пример некоторого довольно распространенного кода (синтаксически):

foo.bar.blah.baz = foo.bar.blah.qaz (1)
Если foo.bar.blah.zaq = foo.bar.blah.abc тогда '...
Когда этот код запускается, вот что происходит:

переменная Foo разрешается для глобального объекта.
Переменная планка разрешена как член Foo. Это на самом деле вызов метода COM.
Переменная BLAH решается как член Foo.Bar. Это еще один вызов метода COM.
Переменная QAZ разрешена как член Foo.Bar.blah. Правильно, это все еще вызов метода COM.
Позвоните foo.bar.blah.quaz (1). Еще один вызов метода COM. Понятно?
Выполните шаги с 1 по 3 снова, чтобы проанализировать Баз. Система не знает, изменяет ли вызов QAZ модель объекта, поэтому должны быть выполнены шаги с 1 по 3 снова для разрешения BAZ.
Разрешить Baz как член Foo.Bar.blah. Назначить атрибуты.
Выполните шаги с 1 по 3 снова, чтобы проанализировать ZAQ.
Выполните шаги с 1 по 3 снова, чтобы проанализировать ABC.
Как видите, эффективность довольно плохая (и медленная). Быстрый способ написать этот код в VBScript:

установить myobj = foo.bar.blah 'сделать разрешение Blah один раз
Myobj.baz = myobj.qaz (1)
Если myobj.zaq = myobj.abc, тогда '...
Если вы используете VBScript 5.0 или выше, вы можете написать этот код, используя оператор WAT:

с foo.bar.blah
.baz = .qaz (1)
If .zaq = .abc there '...
...
Закончите

, что этот метод также относится к программированию VB.

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

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

Следующий код показывает вам неуместное использование DIM и REDIM.

<%
Dimmyarray ()
Redimmyarray (2)
Myarray (0) =? Привет?
Myarray (1) =? Прощание?
Myarray (2) =? Прощай?
...
'Какой -то другой код, где вам нужно больше места, происходит, тогда ...
Redim сохранить Myarray (5)
Myarray (3) =? Больше вещей?
Myarray (4) =? Еще больше вещей?
Myarray (5) =? Еще больше вещей?
%>

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

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

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

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

< % response.buffer = true %>
Эта строка кода должна быть выполнена до того, как какие -либо данные ответа будут записаны в браузер (то есть до того, как какой -либо HTML появится в сценарии ASP, и до того, как любые файлы cookie будут установлены с использованием коллекции response.cookies). В целом, лучше всего включить буферизацию ответов для всего приложения. Таким образом, вам не нужно писать вышеуказанную строку кода в верхней части каждой страницы.

Ответ.Flush
Распространенная жалоба на буферизацию ответа заключается в том, что пользователи воспринимают страницы ASP, чтобы медленно реагировать (даже если общее время отклика улучшается), потому что им приходится ждать, пока вся страница не будет сгенерирована, прежде чем они смогут что -либо увидеть. Для продолжительных страниц вы можете установить ответ. Buffer = false, чтобы отключить буферизацию ответа. Тем не менее, лучшей стратегией является использование метода ответа. Flush. Этот метод отправляет все HTML, преобразованные ASP в браузер. Например, после преобразования первых 100 рядов таблицы 1000 строк ASP может вызвать ответ. FLUSH, чтобы вызвать результаты преобразования в браузер, что позволяет пользователю увидеть первые 100 строк, прежде чем оставшиеся ряды будут готовы. Этот метод идеально сочетает в себе буферизацию ответа с браузером, постепенно отображающим данные.

(Обратите внимание, что в приведенном выше примере таблицы 1000 строк многие браузеры не начнут отображать таблицу, пока не увидят закрытие тега </table>. Проверьте, поддерживает ли ваш целевой браузер. Чтобы избежать этого, разделите таблицу на несколько таблиц с Меньше рядов и вызова. Flush после каждой таблицы. Ширина контента каждой ячейки.)

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

Совет 15: Встроенные сценарии и ответ

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

<Таблица>
< % Для каждого FLD в RS.Fields %>
<th> < % = fld.name %> </th>
<%
Следующий
Хотя не рупий
%>
<тр>
< % Для каждого FLD в RS.Fields %>
<td> < % = fld.value %> </td>
<% Далее
</tr>
<% rs.movenext
Венд %>
</таблица>
Приведенный ниже код более эффективен, с одной записи в поток ответов на строку. Весь код содержится в блоке VBScript:

<Таблица>
<%
Для каждого FLD в RS.Fields
Response.write (?
Следующий
Хотя не рупий
Response.write (? <tr>?)
Для каждого FLD в RS.Fields %>
Response.write (? <td>? & Fld.value &?
Следующий
Response.write? </Tr>?
Венд
%>
</таблица>
Этот трюк работает особенно хорошо, когда буферизация ответа отключена. Это хорошая идея, чтобы включить буферизацию ответа и посмотреть, помогает ли пакетный ответ.

(В этом конкретном примере вложенная петля, которая строит тело таблицы (хотя и не Rs.EOF ...) может быть заменена тщательно построенным вызовом GetString.)

Совет 16: Если страница занимает много времени для завершения, Если пользователи будут нетерпеливы перед использованием recsion.isclientConnected

, они могут отказаться от страницы ASP, прежде чем вы начнете выполнять их запрос. Если они нажимают обновить или переходить на другую страницу на сервере, в конце очереди запроса ASP появится новый запрос, и отключенный запрос в середине очереди. Это часто случается, когда нагрузка на сервер высока (и, следовательно, очередь запросов является длинным, а время отклика соответственно длится), что только усугубляет ситуацию. Нет смысла выполнять страницы ASP (особенно медленные, большие страницы ASP), если пользователь больше не подключен. Вы можете проверить это, используя свойство oucts.isclientconnnected. Если он возвращает false, следует вызвать ответ. На самом деле, IIS 5.0 запрограммировано в поведение - каждый раз, когда ASP собирается выполнить новый запрос, он проверяет, как долго запрос ждал в очереди. Если он ждал там более 3 секунд, ASP проверит, будет ли клиент все еще подключен, а если нет, немедленно прекратите запрос. Вы можете настроить тайм -аут с 3 секунд на другое значение, используя настройку AspqueueConnectionTesttime в метабазе.

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

Обратите внимание, что на IIS 4.0 response.isclientConnected не будет работать должным образом, если ответ. Перепись сначала. Если буферизация включена, вы также должны выполнить response.flush. На IIS 5.0 нет необходимости делать это - response.isclientconcect работает нормально. В любом случае, ответ. Опыт показывает, что вы не должны вызывать его каждый раз, когда неоднократно выполняется плотный цикл, например, при отображении многих рядов таблицы - называть его каждые двадцать или пятьдесят рядов может быть уместным.

Совет 17: Используйте тег <object> для создания создания объектов,

если вы хотите ссылаться на объект, который не используется во всех путях кода (особенно объекты с сервером или приложениями), используйте <Object Runat = Server ID = objName> Tag Объявление в Global.asa их вместо использования метода Server.createObject. Server.createObject создает объекты немедленно. Если вы не будете использовать объект в будущем, вы потратили впустую ресурсы. TAG <Object ID = objName> объявляет ObjName, но ObjName не создается до тех пор, пока его метод или свойство не будут использованы в первый раз.

Это еще один пример ленивой оценки.

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

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

IIS 5.0 представил возможность связываться с библиотеками типа компонентов. Это позволяет ссылаться на библиотеку типа один раз и использовать ее на каждой странице ASP. Для каждой страницы нет накладных расходов на постоянные файлы, и разработчикам компонентов не нужно создавать файлы vbscript#_include для использования в ASP.

Чтобы получить доступ к Ado Typelib, поместите следующее заявление на Global.asa.

<!- ​​Имя метаданных =? Microsoft Activex Data Objects 2.5 Библиотека?
Type =? Typelib?
или

<!- тип метаданных =? Typelib?
File =? C: Program Files Common Files System Ado

MSADO15.DLL

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

Большая часть работы пошла на разработку «независимого от браузера» HTML. Из -за этой проблемы разработчики неохотно используют популярные функции браузера, которые могут повысить производительность. Для некоторых по-настоящему высокопроизводительных сайтов необходимо решить проблемы с «доступом» браузера, и хорошая стратегия состоит в том, чтобы оптимизировать страницу, чтобы адаптировать ее к популярным браузерам. Возможности браузера могут быть легко обнаружены в ASP, используя компонент возможностей браузера. Инструменты, такие как код разработки справки Microsoft FrontPage, который подходит для браузера и конкретной версии HTML. Посмотрите, когда лучше? Взвешивание технологических компромиссов для дальнейшего обсуждения.

:

Избегайте использования конкатенации строки в

петле

Для каждого FLD в RS.Fields
S = S &?
Далее

, пока не rs.eof
s = s & vbcrlf &?
Для каждого FLD в RS.Fields
S = S &?
Следующий
S = S &?
rs.MoveNext
Wend

s = s & vbcrlf &? </Table>?
Response.write s
Некоторые проблемы возникают с этим подходом. Первая проблема заключается в том, что неоднократно объединяющие строки требуют времени на силу двух. Более простой пример проиллюстрирует эту проблему более четко.

s = ??
Для i = asc (? A?) Для ASC (? Z?)
S = S & Chr (I)
Следующий
В первой итерации вы получаете строку с одним символом? A?. Во второй итерации VBScript должен перераспределить строку и копировать два символа (? AB?) В S. На третьей итерации она также должна перераспределить S и скопировать три символа в s. На n (26 -е) итерации он должен перераспределить и копировать n символов в с. Общая сумма составляет 1+2+3+...+n, то есть n*(n+1)/2 копии.

В приведенном выше примере записи, если есть 100 записей и 5 полей, внутренний цикл будет выполнен 100*5 = 500 раз, а время, потраченное на все копирование и перераспределение, пропорционально 500*500 = 250 000. Это слишком много операций копий для набора записей умеренного размера.

В этом случае код может быть улучшен с использованием response.write () или встроенных сценариев (< % = fld.value %>) вместо конкатенации строки. Если буферизация ответа включена (это должно), это будет быстрее, потому что ответ. Перепись только добавляет данные к окончанию буфера отклика. Там нет перераспределения, так что это очень эффективно.

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

Если вы объединяете строки в JScript, особенно рекомендуется использовать оператор += использовать S +=? Строка?

Совет 21: Включите браузер и прокси -кэширование

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

Какую динамическую страницу можно использовать в качестве страницы для кэширования? Вот несколько примеров:

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

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

< % response.expires = 10 %>

Настройка ответа. Экспенса на отрицательное число или 0 отключает кеширование. Обязательно используйте большое отрицательное число, например -1000 (чуть больше, чем день), чтобы избежать несоответствия между часами сервера и браузера. Второе свойство, response.expiresabsolute, позволит вам установить конкретное время, когда содержится истекать:

< % response.expiresabsolute = #May 31,2001 13: 30: 15 # %>
Вместо использования объекта ответа, чтобы установить время истечения срока действия, вы можете записать тег <eta> в HTML, обычно в разделе <head> файла HTML. Некоторые браузеры будут уважать эту директиву, а доверенные лица - нет.

<Meta http-eving =?
Наконец, вы можете использовать свойство response.cachecontrol, чтобы указать, может ли его контент кэшировать HTTP -прокси. Установка этого свойства для «публичного» позволяет прокси кэшировать этот контент.

< % Response.cachecontrol =? Public? %>
По умолчанию это свойство установлено на «частное». Обратите внимание, что кэширование прокси не должно быть включено для страниц, которые отображают данные, специфичные для пользователя, поскольку прокси может обслуживать пользовательские страницы, принадлежащие другим пользователям.

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

. RedieCeect, когда это возможно. Эта функция обычно используется для перенаправления пользователя на страницу входа в систему или ошибки. Поскольку перенаправление заставляет запрос на новую страницу, результатом является то, что браузер должен совершать две круглые поездки на веб -сервер, а веб -сервер должен обрабатывать еще один запрос. IIS 5.0 представляет новый функциональный сервер. Transfer, который передает выполнение на другую страницу ASP на том же сервере. Это позволяет избежать избыточного браузера-Web-Server в обратном порядке, улучшая общую производительность системы и время отклика пользователя. Проверьте «новое направление» в «перенаправлении», это должно быть Server.transfer и Server.execute.

См. Также Использование ASP в IIS 5.0 для полного списка новых функций в IIS 5.0 и ASP 3.0.

Совет 23: Используйте Backslash в URL -адресах каталога.

Связанный совет - убедиться, что вы используете BackSlash (/) в URL -адресах, которые указывают на каталоги. Если вы опустите след утроивания, браузер сделает запрос на сервер, чтобы сказать серверу, что он запрашивает каталог. Браузер выполняет второй запрос, добавляя чертову на URL, и только тогда сервер может ответить с помощью документа или списка каталога каталога (если не включен документ по умолчанию и просмотр документов по умолчанию). Добавление чернила устраняет первое, бесполезное возвращение. Чтобы пользователям было проще читать, запекание в имени дисплея может быть опущено.

Например, напишите:

<a href =? Http: //msdn.microsoft.com/workshop/? Title =? MSDN Web
Семинар?> Http://msdn.microsoft.com/workshop </a>
Это также относится к URL -адресам, указывающим на домашнюю страницу на веб -сайте: Используйте следующее: <a href =? Http: //msdn.microsoft.com/?> Вместо <a href =? Http: //msdn.microsoft .

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

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

Никогда не получайте доступ к Unkalified Request Object (например, запрос («Data»)). Request.servervariables называется неявно для элементов, которые не находятся в запросе. Cookies, request.form, request.querystring или request.clientcertificate. Коллекция request.servervariables намного медленнее, чем другие коллекции.

Совет 25: Обновление до последних и лучших

системных компонентов является постоянной, и мы рекомендуем вам обновить их до последних и лучших конфигураций. Лучше всего перейти на 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 не масштабируется выше двух процессоров. Чем больше кода сценариев и ADE вы используете в своем приложении, тем больше улучшений производительности вы будете испытывать после обновления до Windows 2000.

Если вы еще не можете перейти на Windows 2000, вы можете перейти на последние версии SQL Server, ADO, VBScript и JSCRICT, MSXML, Internet Explorer и NT 4 Service Packs. Они оба улучшают производительность и надежность.

Совет 26: Оптимизируйте веб -сервер.

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

Для хорошей ссылки см. Оптимизация IIS ниже.

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

Совет 27: Проводите тестирование производительности

, как мы уже говорили ранее, производительность является характеристикой. Если вы хотите повысить производительность вашего сайта, установите цель производительности и постепенно улучшитесь, пока не достигнете его. Нет, тестирование производительности не будет выполнено. Часто, к концу проекта, уже слишком поздно вносить необходимые структурные изменения, и ваш клиент будет разочарован. Проведите тестирование производительности как часть вашей процедуры тестирования. Вы можете выполнять тестирование производительности на отдельных компонентах индивидуально, таких как страницы ASP или COM -объекты, или на сайте в целом.

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

Как правило, для точного тестирования производительности вам нужна специальная среда тестирования. Эта среда должна включать аппаратное обеспечение, которое аналогично производственной среде с точки зрения скорости процессора, количества процессоров, памяти, дисков, конфигурации сети и т. Д. Во -вторых, вы должны указать рабочую нагрузку клиента: сколько одновременных пользователей есть, как часто они выполняют запросы, на какие типы страниц они нажимают и т. Д. Если у вас нет данных об реальном использовании сайта, вы должны оценить использование. Наконец, вам нужен инструмент, который может моделировать ожидаемые рабочие нагрузки клиентов. С этими инструментами вы можете начать отвечать на такие вопросы, как «Если у меня есть N -одновременные пользователи, сколько серверов мне понадобится?» Вы также можете определить причины узких мест и оптимизировать против них.

Ниже перечислены некоторые хорошие инструменты тестирования веб -нагрузки. Мы особенно рекомендуем инструментарий Microsoft Web Application Press (был). Был разрешено записывать тестовые сценарии, а затем моделировать сотни или тысячи пользователей, получающих доступ к веб -серверу. Был отчеты ряд статистических данных, включая запросы в секунду, распределение времени ответа и количество ошибок. Был доступен как в богатом клиентском интерфейсе, так и в веб-интерфейсе, который позволяет провести удаленное тестирование.

Обязательно прочитайте руководство по настройке IIS 5.0.

Совет 28: Читать ссылки на ресурсы

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

Оптимизация

ресурсов

ASP

масштабируемых

веб

-приложений

Ресурсы скорости и оптимизации

от Нэнси Винник Cluts

оптимизируя

IIS

Carroll

The Art and Science of Sever Server с интернет -информационными службами 5.0.

Производительность сервера от Майкла Стивенсона

навигационная лабиринт настроек для оптимизации производительности веб -сервера

от

Mike Moore

управления интернет -информационным сервером 4.0 для производительности Todd Wanke,

Ado и SQL Server

Top Des

Производительность вашего приложения MDAC от

JD Meier

объединяющего в компонентах Microsoft Data Access Suresh Kannan,

SQL Server: контрольные показатели производительности и руководства

улучшающие производительность компонентов доступа к данным с помощью

компонентов Microsoft Data Data ( MDAC) и советы ActiveX Data Data (ADO) от Leland Ahlbeck,

Microsoft

SQL Server 7.0 Практическая настройка и оптимизацию производительности - перспектива сервера от Leland Ahlbeck,

Microsoft SQL Server 7.0 Практическая настройка производительности и оптимизация - перспектива сервера Damien Lindauer - The Перспектива приложения Дэмиена Линдауэра

Доступ к Recordsets через Интернет от Dino Esposito

Руководства по компонентам

ASP

Q243548: Информация: Рекомендации по проектированию для компонентов VB в рамках

моделей

объясненных Nancy Winnick Cluts,

так счастлив вместе

Активные компоненты сервера с ATL от

Nancy Winnick Cluts Cluts

создание высокопроизводительных компонентов среднего уровня с C ++ от

Neil Allain

Active Server Pages и Com от Jon Flanders Apartments, Don Box,

House of Com: Активные страницы серверов, от Don Box,

House of Com: Contexts, Don Box,

House of Com: компромиссы производительности в среде выполнения компонентов Windows 2000, Don Box,

создание компонентов COM, которые в полной мере пользуются Visual Basic and Scripting , от IVO Salmre

Princips Design для

компонента словаря

Создание объекта кэша страниц, Роберт Коулридж,

сокращающий объект словаря: команда ASP создает объект поиска с таблицей, от Robert Carter

Caprock Dictionary

Sever Server Edition включает в себя словарь

сессии компонента.

значения

без сессий

Q157906

:

Howto: Как поддерживать состояние на разных страницах с VBScript

XML.

,

использующие Microsoft Windows DNA Platerd

и

убийцы масштабируемости, от George Reilly

Microsoft Visual Studio Center Center

Fitch & Mather Stocks 2000

высокопроизводительных приложений

FMStocks Application

И как предотвратить их от Gary Geiger и Jon Pulsipher

Building от статического HTML до высокопроизводительных веб-ферм от Shawn Bice

Microsoft Web Application Tool

Я

не могу подчеркнуть его-загрузить приложение ASP, от JD Meier

Windows ДНК

наборов производительности

в распределенных приложениях с использованием анализатора Visual Studio, Mai-Lan Tomsen

Bibliography

Professional Active Server Pages 3.0, Wrox Press (особенно глава 26: Оптимизация производительности ASP, Джордж Рейли с Мэтью Гиббсом).

Microsoft Internet Information Services 5.0 Руководство по ресурсам (с Windows 2000 Server Resource Kit), Microsoft Press.

Microsoft Internet Information Server Kit (для IIS 4.0), Microsoft Press.

Программирование распределенных приложений с Com и Microsoft Visual Basic 6.0, Ted Pattison, Microsoft Press.

Эффективно, Дон Бокс, Кит Браун, Тим Эвальд и Крис продают;

Разработка веб -юзабилити: практика простоты, от Jakob Nielsen, New Higders.

ASP Web SiteSmicrosoft

Technet для iIS

Learnasp.com

4GuysFromRolla.com

15Seconds.com

asptoday.com

asp101.com

asplists.com. Многие профессиональные списки рассылки включают в себя:

быстрый код!
ASP Advanced
Не новичок
Масштабируемость
Визуальные базовые компоненты
XML
C ++/ATL Компонентное здание
USEIT.com: веб -удобство использование

ASP Style

Best Practices от George Reilly

ASP Quick Musones By Charles Carroll

Planning для ASP John Meade

Xml

от JD Meier

Inside XML Performance от Chris Lovett

Inside MSXML3 Performance от Chris Lovett