Разработчики ASP постоянно стремятся повысить производительность и масштабируемость своих проектов. К счастью, существует множество книг и сайтов, которые дают отличные советы в этой области. Однако эти предложения основаны на выводах, сделанных из структуры работы платформы ASP, и количественного измерения фактического улучшения производительности не существует. Поскольку эти рекомендации требуют более сложного кодирования и делают его менее читабельным, разработчикам приходится взвешивать, стоит ли затраченных средств на улучшение производительности их приложений ASP, не видя реальных результатов.
Эта статья разделена на две части. Я представлю некоторые результаты тестирования производительности, чтобы помочь разработчикам определить, стоит ли та или иная инициатива не только для будущих проектов, но и для обновления исходного проекта. В первой части я рассмотрю некоторые основные вопросы разработки ASP. Во второй части вы узнаете об оптимизации некоторых функций ADO и сравнении их результатов со страницами ASP, которые вызывают объекты VB COM для выполнения тех же функций ADO. Результаты поражают воображение, а иногда и удивляют.
В этой статье мы ответим на следующие вопросы:
* Каков наиболее эффективный способ записи содержимого, сгенерированного ASP, в поток ответов?
* Должен ли быть включен буфер?
* Стоит ли вам рассмотреть возможность добавления комментариев в код ASP?
* Должен ли язык по умолчанию быть явно установлен для страницы?
* Должно ли состояние сеанса быть закрыто, если в этом нет необходимости?
* Следует ли размещать логику сценария в подпрограммах и функциональных областях?
* Каковы последствия использования включаемых файлов?
* Какая нагрузка возникает при обработке ошибок?
* Влияет ли настройка обработчика контекста на производительность?
Все тестирование проводилось с использованием бесплатного инструмента Microsoft Web Application Focus Tool (WAST), который можно найти здесь. Я создал простой тестовый сценарий с использованием WAST, который неоднократно вызывал описанные ниже тесты страниц ASP (более 70 000 раз каждый). Время ответа основано на среднем общем времени последнего байта (TTLB), которое представляет собой время от момента первоначального запроса до момента получения инструментом последнего бита данных с сервера. Наш тестовый сервер — Pentium 166 с 196 МБ ОЗУ, а клиент — Pentium 450 с 256 МБ ОЗУ. Вы можете подумать, что производительность этих машин не очень высока, но не забывайте, мы не тестируем мощность сервера, мы просто тестируем время, необходимое серверу для обработки одной страницы за раз. Во время испытания машины не выполняют никакой другой работы. Сценарии тестирования WAST, отчеты о тестировании и все тестовые страницы ASP включены в ZIP-файл, чтобы вы могли просмотреть и протестировать его самостоятельно.
Каков наиболее эффективный способ записи содержимого, сгенерированного ASP, в поток ответов?
Одной из главных причин использования ASP является создание динамического контента на сервере. Таким образом, очевидной отправной точкой для нашего тестирования является определение наиболее подходящего способа отправки динамического контента в поток ответов. Среди множества вариантов два являются наиболее простыми: один — использовать встроенные теги ASP, а другой — использовать оператор Response.Write.
Чтобы протестировать эти параметры, мы создали простую страницу ASP, на которой определили некоторые переменные, а затем вставили их значения в таблицу. Хотя эта страница проста и не очень практична, она позволяет нам изолировать и тестировать некоторые отдельные проблемы.
Использование встроенных тегов ASP
Первый тест включает использование встроенного тега ASP < %= x % >, где x — присвоенная переменная. Этот метод, безусловно, самый простой в исполнении, и он сохраняет HTML-часть страницы в формате, который легко читать и поддерживать.
＜% ОПЦИЯ ЯВНАЯ
Дим Имя
Димфамилия
Тусклый средний начальный
Тусклый адрес
Дим Сити
Тусклый штат
ДимТелефонНомер
Тусклый номер факса
Тусклый адрес электронной почты
ДимДатаРождения
Имя = Джон
СреднийНачало = Q
Фамилия = Публичный
Адрес = Мейн-стрит, 100.
Город=Нью-Йорк
Штат = Нью-Йорк
Номер телефона = 1-212-555-1234
Номер факса = 1-212-555-1234
Электронная почта = [email protected]
Дата рождения = 01.01.1950
%>
＜HTML＞
＜ГОЛОВА＞
＜ НАЗВАНИЕ ＞Тест ответа ＜ / НАЗВАНИЕ ＞
＜ /ГОЛОВКА ＞
＜ТЕЛО＞
＜ H1 ＞ Тест ответа ＜ /H1 ＞
＜ ТАБЛИЦА ＞
＜ tr ＞＜ td ＞＜ b ＞Имя:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Имя % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Средний начальный:＜ /b ＞＜ /td ＞＜ td ＞＜ %= MiddleInitial % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Фамилия:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Фамилия % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Адрес:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Адрес % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Город:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Город % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Состояние:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Состояние % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Номер телефона:＜ /b ＞＜ /td ＞＜ td ＞＜ %= PhoneNumber % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Номер факса:＜ /b ＞＜ /td ＞＜ td ＞＜ %= FaxNumber % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞＜ %= EMail % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Дата рождения:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Дата рождения % ＞＜ /td ＞＜ /tr ＞
＜/ТАБЛИЦА ＞
＜ /ТЕЛО ＞
＜ /HTML ＞
Полный код /app1/response1.asp
Предыдущий лучший результат (скорость отклика) = 8,28 мс/стр.
Используйте оператор Response.Write в каждой строке HTML.
Многие из лучших учебных документов рекомендуют избегать предыдущего метода. Основная причина этого заключается в том, что в процессе вывода страницы и ее обработки для введения задержки, если веб-серверу приходится переключаться между отправкой обычного HTML и обработкой сценария, возникает проблема, называемая переключением контекста. Когда большинство программистов слышат это, их первой реакцией является обертывание каждой строки необработанного HTML в функцию Response.Write.
…
Response.Write(＜html＞)
Response.Write(＜head＞)
Response.Write(＜title＞Тест ответа＜/title＞)
Response.Write(＜/head＞)
Response.Write(＜тело＞)
Response.Write(＜h1＞Тест ответа＜/h1＞)
Response.Write(＜таблица＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Имя:＜ /b ＞＜ /td ＞＜ td ＞ & Имя & ＜ /td ＞＜ /tr ＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Средний инициал:＜ /b ＞＜ /td ＞＜ td ＞ & MiddleInitial & ＜ /td ＞＜ /tr ＞)
… <
Фрагмент /app1/response2.asp
Предыдущий лучший результат (скорость отклика) = 8,28 мс/стр.
Время отклика = 8,08 мс/стр.
Разница = -0,20 мс (снижение на 2,4%)
Мы видим, что прирост производительности от использования этого подхода очень мал по сравнению с использованием встроенной разметки, возможно, потому, что страница загружает сервер кучей небольших вызовов функций. Самый большой недостаток этого подхода заключается в том, что, поскольку HTML теперь встроен в сценарий, код сценария становится более многословным и трудным для чтения и обслуживания.
Используйте функции-обертки
Возможно, самое обескураживающее открытие при попытке использовать операторный подход Response.Write заключается в том, что функция Response.Write не может поместить CRLF в конец каждой строки. Поэтому, когда вы читаете исходный код из браузера, HTML, который был идеально выложен, теперь представляет собой одну строку без конца. Я думаю, ваше следующее открытие может быть еще более ужасающим: в объекте Response нет родственной функции Writeln. Итак, очевидная реакция — создать функцию-оболочку для функции Response.Write, чтобы добавлять CRLF к каждой строке.
…
writeCR(＜ tr ＞＜ td ＞＜ b ＞Имя:＜ /b ＞＜ /td ＞＜ td ＞ & Имя & ＜ /td ＞＜ /tr ＞)
…
ПОДПИСАНИЕCR(str)
Response.Write(str & vbCRLF)
КОНЕЦ ПОДПИСКИ
Фрагмент /app1/response4.asp
Предыдущий лучший результат (скорость отклика) = 8,08 мс/стр.
Время отклика = 10,11 мс/стр.
Разница = +2,03 мс (увеличение на 25,1%)
Конечно, поскольку этот подход фактически удваивает количество вызовов функций, его влияние на производительность существенно, и его следует избегать любой ценой. По иронии судьбы CRLF также добавляет к реактивному потоку по 2 байта на строку, которые браузеру не нужно отображать на странице. Все, что делает хорошо отформатированный HTML, — это облегчает вашим конкурентам чтение исходного кода HTML и понимание вашего дизайна.
Объединить последовательные ответы. Записать в один оператор.
Независимо от наших предыдущих тестов с функциями-обертками, следующим логическим шагом будет извлечение всех строк из отдельных операторов Response.Write и объединение их в один оператор, что уменьшит количество вызовов функций и значительно улучшит производительность страницы.
…
Response.Write(＜html＞&_
＜ голова ＞ & _
＜title＞Тест ответа＜/title＞ & _
＜ /head ＞ & _
＜тело＞ & _
＜ h1 ＞Тест ответа＜ /h1 ＞ & _
＜ таблица ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Имя:＜ /b ＞＜ /td ＞＜ td ＞ & Имя & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Дата рождения:＜ /b ＞＜ /td ＞＜ td ＞ & Дата рождения & ＜ /td ＞＜ /tr ＞ & _
＜ /таблица ＞ & _
＜ /body ＞ & _
＜ /html ＞)
Фрагмент /app1/response3.asp
Предыдущий лучший результат (скорость отклика) = 8,08 мс/стр.
Время отклика = 7,05 мс/стр.
Разница = -1,03 мс (снижение на 12,7%)
На данный момент это наиболее оптимизированная конфигурация.
Объедините последовательные ответы. Запишите их в один оператор, добавив CRLF в конце каждой строки.
Учитывая тех, кому требуется, чтобы исходный код выглядел в браузере в первозданном виде, я использовал константу vbCRLF, чтобы вставить символы возврата каретки в конце каждой строки в предыдущем тесте, и перезапустил его.
…
Response.Write(＜html＞&vbCRLF&_
＜ голова ＞ & vbCRLF & _
＜ title ＞Тест ответа＜ /title ＞ & vbCRLF & _
＜ /head ＞ & vbCRLF & _
…
Фрагмент /app1/response5.asp
Предыдущий лучший результат (скорость отклика) = 7,05 мс/стр.
Время отклика = 7,63 мс/стр.
Разница = +0,58 мс (увеличение на 8,5%)
В результате происходит небольшое снижение производительности, возможно, из-за дополнительной конкатенации и увеличения количества символов.
Обзор и наблюдение
Некоторые правила можно вывести из предыдущих тестов вывода ASP:
* Избегайте чрезмерного использования встроенного ASP.
* Всегда объединяйте последовательные операторы Response.Write в один оператор.
* Никогда не используйте функции-обертки вокруг Response.Write для добавления CRLF.
* Если вывод HTML необходимо отформатировать, добавьте CRLF непосредственно в оператор Response.Write.
Должен ли быть включен буфер?
Запустить буфер через скрипт
Включив Response.Buffer=True в начало сценария ASP, IIS кэширует содержимое страницы.
＜% ОПЦИЯ ЯВНАЯ
Response.Buffer = правда
Дим Имя
…
Фрагмент /app1/buffer__1.asp
Предыдущий лучший результат (время отклика) = 7,05 мс/страница.
Время отклика = 6,08 мс/стр.
Разница = -0,97 мс (снижение на 13,7%)
Производительность значительно улучшилась. Но подождите, есть что-то получше.
Запуск буфера через конфигурацию сервера
Хотя буфер включен по умолчанию в IIS 5.0, в IIS 4.0 его необходимо включить вручную. Теперь найдите диалоговое окно «Свойства» сайта и нажмите кнопку «Настроить» на вкладке «Домашний каталог». Затем выберите «Включить буферизацию» в разделе «Параметры приложения». Для этого теста оператор Response.Buffer был удален из сценария.
Предыдущий лучший результат = 7,05 мс/страницу.
Время отклика = 5,57 мс/стр.
Разница = -1,48 мс (снижение на 21,0%)
На данный момент это самый быстрый ответ, который у нас когда-либо был: на 21 % меньше, чем в предыдущем лучшем случае. Отныне в наших будущих тестах это время реакции будет использоваться в качестве базового значения.
Обзор и наблюдение
Буферы — отличный способ повысить производительность, поэтому установка буферов на значения по умолчанию сервера необходима. Если по какой-то причине страница не может правильно запустить буфер, просто используйте команду Response.Buffer=False. Одним из недостатков буферов является то, что пользователь ничего не видит с сервера, пока не будет обработана вся страница. Поэтому во время обработки сложных страниц рекомендуется время от времени вызывать Response.Flush для обновления пользователя.
Теперь у нас добавлено еще одно правило: всегда включать буферизацию через настройки сервера.
Стоит ли вам рассмотреть возможность добавления комментариев в ваш код ASP?
Большинство HTML-разработчиков знают, что включать HTML-комментарии — плохая идея, во-первых, они увеличивают размер передаваемых данных, а во-вторых, они просто предоставляют другим разработчикам информацию об организации вашей страницы. А как насчет комментариев на страницах ASP? Они никогда не покидают сервер, но увеличивают размер страницы, поэтому их необходимо разбить с помощью ASP.
В этом тесте мы добавили 20 комментариев по 80 символов каждый, всего 1600 символов.
＜% ОПЦИЯ ЯВНАЯ
'------------------------------------------------ - ---------------------------------
…20 строк…
'------------------------------------------------ - ---------------------------------
Дим Имя
…
/app2/comment_1.asp фрагмент
Базовый уровень = 5,57 мс/стр.
Время отклика = 5,58 мс/стр.
Разница = +0,01 мс (увеличение на 0,1%)
Результаты теста были ошеломляющими. Хотя комментарии почти в два раза длиннее самого файла, их наличие не оказывает большого влияния на время ответа. Итак, мы можем следовать следующим правилам:
При умеренном использовании аннотации ASP практически не влияют на производительность.
Должен ли язык по умолчанию быть явно установлен для страницы?
IIS по умолчанию обрабатывает VBScript, но я вижу, что в большинстве случаев язык явно устанавливается на VBScript с помощью оператора <%@LANGUAGE=VBSCRIPT%>. Наш следующий тест проверит, какое влияние наличие этого объявления оказывает на производительность.
＜ %@ LANGUAGE=VBSCRIPT % ＞
＜% ОПЦИЯ ЯВНАЯ
Дим Имя
…
Фрагмент /app2/language1.asp.
Базовый уровень = 5,57 мс/стр.
Время отклика = 5,64 мс/стр.
Разница = +0,07 мс (увеличение на 1,2%)
Как видите, включение языковых объявлений незначительно влияет на производительность. поэтому:
* Установите языковую конфигурацию сервера по умолчанию, соответствующую языку, используемому на сайте.
* Не устанавливайте объявление языка, если вы не используете язык, отличный от языка по умолчанию.
Следует ли отключить состояние сеанса, если оно не требуется?
Существует множество причин избегать использования контекста сеанса IIS, и им может быть посвящена отдельная статья. Вопрос, на который мы сейчас пытаемся ответить, заключается в том, поможет ли закрытие контекста сеанса, когда он не нужен странице, повысить производительность. Теоретически должно быть да, потому что тогда нет необходимости использовать страницу для создания экземпляра контекста сеанса.
Как и в случае с буфером, существует два способа настройки состояния сеанса: через скрипты и через настройки сервера.
Закрыть контекст сеанса через скрипт
Для этого теста, чтобы закрыть контекст сеанса на странице, я добавил объявление состояния сеанса.
＜ %@ ENABLESESSIONSTATE = FALSE % ＞
＜% ОПЦИЯ ЯВНАЯ
Дим Имя
…
Фрагмент /app2/session_1.asp.
Базовый уровень = 5,57 мс/стр.
Время отклика = 5,46 мс/стр.
Разница = -0,11 мс (уменьшение на 2,0%)
Благодаря таким небольшим усилиям был достигнут хороший прогресс. Теперь посмотрите вторую часть.
Закройте контекст сеанса через конфигурацию сервера.
Чтобы закрыть контекст сеанса на сервере, перейдите в диалоговое окно «Свойства» сайта. Нажмите кнопку «Конфигурация» на вкладке «Домашний каталог». Затем снимите флажок «Включить состояние сеанса» в разделе «Параметры приложения». Мы запускаем тест без оператора ENABLESESSIONSTATE.
Базовый уровень = 5,57 мс/стр.
Время отклика = 5,14 мс/стр.
Разница = -0,43 мс (снижение на 7,7%)
Это еще одно значительное улучшение производительности. Поэтому нашим правилом должно быть: всегда закрывать состояние Session на уровне страницы или приложения, когда оно не нужно.
Изменит ли использование Option Explicit существенно производительность?
Установите параметр Option Explicit в верхней части страницы ASP, чтобы требовать объявления всех переменных на странице перед использованием. Для этого есть две причины. Во-первых, приложения могут быстрее обрабатывать доступ к переменным. Во-вторых, это предотвращает случайное неправильное использование имен переменных. В этом тесте мы удаляем ссылку Option Explicit и объявление переменной Dim.
Базовый уровень = 5,57 мс/стр.
Время отклика = 6,12 мс/стр.
Разница = +0,55 мс (увеличение на 9,8%),
Несмотря на то, что некоторые строки кода были удалены со страницы, время ответа все равно увеличилось. Таким образом, хотя использование явного Option иногда отнимает много времени, оно существенно влияет на производительность. Поэтому мы можем добавить еще одно правило: всегда используйте явный параметр в VBScript.
Следует ли размещать логику сценария в подпрограммах и функциональных областях?
Использование функций и подпрограмм — хороший способ организации кода и управления им, особенно если область кода используется на странице несколько раз. Недостаток заключается в том, что в систему добавляется дополнительный вызов функции, выполняющей ту же работу. Другая проблема с подпрограммами и функциями — область видимости переменных. Теоретически более эффективно указывать переменные внутри функциональной области. Теперь давайте посмотрим, как эти два аспекта вступают в игру.
Переместите оператор Response.Write в подпрограмму.
Этот тест просто перемещает оператор Response.Write в область подпрограммы.
…
ВЫЗОВ WriteTable()
ПОДПИСАНИЕТаблица()
Response.Write(＜html＞&_
＜ голова ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞ & EMail & ＜ /td ＞＜ /tr ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Дата рождения:＜ /b ＞＜ /td ＞＜ td ＞ & Дата рождения & ＜ /td ＞＜ /tr ＞ & _
＜ /таблица ＞ & _
＜ /body ＞ & _
＜ /html ＞)
КОНЕЦ ПОДПИСКИ
/app2/function1.asp фрагмент
Базовый уровень = 5,57 мс/стр.
Время отклика = 6,02 мс/стр.
Разница = +0,45 мс (увеличение на 8,1%)
Как и ожидалось, вызовы подпрограмм создают дополнительные издержки на странице.
Переместите все скрипты в подпрограммы
В этом тесте оператор Response.write и объявления переменных перемещаются в область подпрограммы.
＜% ОПЦИЯ ЯВНАЯ
ВЫЗОВ WriteTable()
ПОДПИСАНИЕТаблица()
Дим Имя
…
ДимДата Рождения
Имя = Джон
…
Дата рождения = 01.01.1950
Response.Write(＜html＞&_
＜ голова ＞ & _
＜title＞Тест ответа＜/title＞ & _
＜ /head ＞ & _
＜тело＞ & _
＜ h1 ＞Тест ответа＜ /h1 ＞ & _
＜ таблица ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Имя:＜ /b ＞＜ /td ＞＜ td ＞ & Имя & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Дата рождения:＜ /b ＞＜ /td ＞＜ td ＞ & Дата рождения & ＜ /td ＞＜ /tr ＞ & _
＜ /таблица ＞ & _
＜ /body ＞ & _
＜ /html ＞)
КОНЕЦ ПОДПИСКИ
Фрагмент /app2/function2.asp
Базовый уровень = 5,57 мс/стр.
Время отклика = 5,22 мс/стр.
Разница = -0,35 мс (снижение на 6,3%)
Очень интересно! Хотя перемещение переменных в область действия функции добавляет дополнительный вызов функции, на самом деле это повышает производительность. Мы можем добавить следующие правила:
* Если на странице код будет использоваться более одного раза, заключите его в функциональную область.
* При необходимости переместите объявления переменных в область действия функции.
Каковы последствия использования включаемых файлов?
Важной особенностью программирования ASP является включение кода с других страниц. Благодаря этой функции программисты могут распределять функции на нескольких страницах, что упрощает поддержку кода. Недостаток — сервер должен собирать страницу из нескольких источников. Ниже приведены два теста с использованием включаемых файлов.
Включить файлы с помощью встроенного кода
В этом тесте небольшой фрагмент кода был перенесен во включаемый файл:
＜% ОПЦИЯ ЯВНАЯ
Дим Имя
…
ДимДата Рождения
Имя = Джон
…
Дата рождения = 01.01.1950
%>
＜ !-- #include file=inc1.asp -- ＞
/app2/include_1.asp фрагмент
Базовый уровень = 5,57 мс/стр.
Время отклика = 5,93 мс/стр.
Разница = +0,36 мс (увеличение на 6,5%)
Это неудивительно. Полезная нагрузка формируется с помощью Include-файлов.
Используйте «Включить файлы» в функциональной области.
Здесь код заключен в подпрограмму во включаемом файле. Ссылка Include расположена в верхней части страницы и вызывает подпрограмму в соответствующем месте сценария ASP.
＜% ОПЦИЯ ЯВНАЯ
Дим Имя
…
ДимДата Рождения
Имя = Джон
…
Дата рождения = 01.01.1950
ВЫЗОВ WriteTable()
%>
＜ !-- #include file=inc2.asp -- ＞
/app2/include_2.asp фрагмент
Базовый уровень = 5,57 мс/стр.
Время отклика = 6,08 мс/стр.
Разница = +0,51 мс (увеличение на 9,2%)
Это оказывает большее влияние на производительность, чем вызовы функций. Итак: используйте включаемые файлы только в том случае, если код используется несколькими страницами.
Какая нагрузка создается при обработке ошибок?
Обработка ошибок необходима для всех реальных приложений. В этом тесте обработчик ошибок вызывается путем вызова функции On Error Resume Next.
＜% ОПЦИЯ ЯВНАЯ
При ошибке Возобновить Далее
Дим Имя
…
/app2/error_1.asp фрагмент
Базовый уровень = 5,57 мс/стр.
Время отклика = 5,67 мс/стр.
Разница = 0,10 мс (увеличение на 1,8%)
Как видите, за обработку ошибок приходится платить. Мы можем предложить следующее: Используйте дескрипторы ошибок только тогда, когда происходит что-то, что вы не можете проверить или контролировать. Базовый пример — использование COM-объектов для доступа к другим ресурсам, таким как объекты ADO или FileSystem.
Влияет ли настройка обработчика контекста на производительность?
При возникновении ошибки установка обработчика контекста на странице позволяет сценарию отменить действие. Это устанавливается с помощью оператора обработки на странице.
＜ %@ ТРАНЗАКЦИЯ = ТРЕБУЕТСЯ % ＞
＜% ОПЦИЯ ЯВНАЯ
Дим Имя
…
Фрагмент /app2/transact1.asp
Базовый уровень = 5,57 мс/стр.
Время отклика = 13,39 мс/стр.
Разница = +7,82 мс (увеличение на 140,4%)
ах! Это действительно самый драматичный результат. Поэтому обратите внимание на следующее правило: используйте контекст обработки только тогда, когда две или более операции выполняются как единое целое.
в заключение
Что важно в первой части этой статьи, так это накопление множества мелочей. Чтобы подчеркнуть эту проблему, я организовал финальный тест, в котором проделал все, что мы тестировали раньше, и это казалось безобидным, но на самом деле имело плохой эффект. Я включил несколько операторов Response.Write, отключил буфер, установил язык по умолчанию, удалил ссылку Option Explicit и инициализировал обработчик ошибок.
＜ %@ LANGUAGE=VBSCRIPT % ＞
<%
При ошибке Возобновить Далее
Имя = Джон
…
Дата рождения = 01.01.1950
Response.Write(＜html＞)
Response.Write(＜head＞)
Response.Write(＜title＞Тест ответа＜/title＞)
Response.Write(＜/head＞)
Response.Write(＜тело＞)
Response.Write(＜h1＞Тест ответа＜/h1＞)
Response.Write(＜таблица＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Имя:＜ /b ＞＜ /td ＞＜ td ＞ &_
Имя & ＜ /td ＞＜ /tr ＞)
…
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Дата рождения:＜ /b ＞＜ /td ＞＜ td ＞ &_
Дата рождения & ＜ /td ＞＜ /tr ＞)
Response.Write(＜/таблица＞)
Response.Write(＜/body＞)
Response.Write(＜/html＞)
%>
/app2/final_1.asp фрагмент
Базовый уровень = 5,57 мс/стр.
Время отклика = 8,85 мс/стр.
Разница = +3,28 мс (увеличение на 58,9%)
Это может показаться очевидным, но важнее понимать, что код, который мы размещаем на странице, влияет на производительность. Небольшие изменения на странице иногда могут значительно увеличить время ответа.
Краткое изложение правил
* Избегайте чрезмерного использования встроенного ASP.
* Всегда объединяйте последовательные операторы Response.Write в один оператор.
* Никогда не используйте функции-обертки вокруг Response.Write для добавления CRLF.
* Если вывод HTML необходимо отформатировать, добавьте CRLF непосредственно в оператор Response.Write.
* Всегда включайте буферизацию в настройках сервера.
* При умеренном использовании аннотации ASP практически не влияют на производительность.
* Установите языковую конфигурацию сервера по умолчанию, соответствующую языку, используемому на сайте.
* Не устанавливайте объявление языка, если вы не используете язык, отличный от языка по умолчанию.
* Всегда используйте явный параметр в VBScript.
* Всегда отключайте состояние сеанса на уровне страницы или приложения, когда в этом нет необходимости.
* Используйте включаемые файлы только в том случае, если код используется несколькими страницами.
* Если на странице код будет использоваться более одного раза, заключите его в функциональную область.
* При необходимости переместите объявления переменных в область действия функции.
* Используйте обработчики ошибок только в том случае, если возникают условия, выходящие за рамки возможностей тестирования или контроля.
* Используйте контекстную обработку только тогда, когда две или более операции выполняются как единое целое.
Оглядываясь назад, можно отметить ряд вопросов, которые могут служить общими рекомендациями:
* Избегайте избыточности — не устанавливайте свойства, которые уже установлены по умолчанию.
* Ограничьте количество вызовов функций.
* Уменьшите объем кода.