Данные советы вводят в проблему повышения производительности работы приложений, использующих технологии 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)
Типичная ASP-страница получает данные из базы данных и затем выводит их в формате HTML. Независимо от скорости работы вашей базы данных, получение данных из памяти сервера будет намного быстрее, чем обработка sql-запроса к конечной базе данных. Получение данных, сохраненных на локальном жестком диске сервера, также обычно быстрее, чем получение информации из БД. Поэтому одним из основных путей увеличения скорости работы вашей ASP-страницы является кэширование часто используемой информации в памяти или на жестком диске.
Кэширование данных - это классический компромисс "место или время". Если вы избрали для кэширования правильный материал, вы можете видеть внушительное повышение производительности вашего приложения. Чтобы кэширование было эффективным нужно использовать для временного хранения только те данные, которые многократно используются для вывода и каждый раз трудоемки для повторных вычислений. Кэш, полный устаревшей информации, будет пустой тратой памяти сервера.
Данные, которые изменяются не часто, будут хорошим кандидатом для кэширования, потому что вам не надо будет волноваться относительно их синхронизации через какое-то время с конечной базой данных. Выпадающие списки (сombo-box), таблицы ссылок, пункты меню, и переменные конфигурации сайта (включая имена DSN, адреса IP и URL) - первые кандидаты для хранения в кэше. Заметьте, что вы можете кэшировать представление данных много быстрее, нежели данные сами себя. Если ASP-страница изменяется не так часто и ее временный кэш будет весьма внушительным (например, полный каталог изделий фирмы), попробуйте использовать сгенерированные HTML-страницы, чем каждый раз загружать сервер генерацией ASP-страниц.
Объекты Application и Session служат для хранения данных в памяти, значения которых могут быть доступны между несколькими HTTP-запросами (в отличие от обычных переменных, чьи значения доступны только в теле одной ASP-страницы). Данные объекта Session доступны только одному пользователю (в течении его сессии), в то время как данные Application доступны всем пользователям веб-сайта. Поэтому часто перед разработчиком возникает вопрос: в каком из объектов сохранять часто используемые данные. Обычно, для инициализации переменных этих объектов используются процедуры файла Global.asa - Application_OnStart() или Session_OnStart() соответственно. Если в вашем Global.asa еще нет этих процедур, то вы можете добавить их сами или инициализировать переменные, когда это будет необходимо. Примером может быть следующая процедура, использующая Application для хранения значений многократно использующейся переменной EmploymentStatusList. Процедура проверяет существование данных в EmploymentStatusList и при необходимости расчитывает их заново:
<%
Function GetEmploymentStatusList
Dim d
d = Application("EmploymentStatusList")
If d = "" Then ' Если значения нет - выполним расчет
d = FetchEmploymentStatusList()
Application("EmploymentStatusList") = d
End If
GetEmploymentStatusList = d
End Function
%>
Подобную функцию можно написать для любой задачи, где не стоит каждый раз заново выполнять тродоемкий расчет. При этом могут быть сохранены данные любого формата (тип variant). Например, вы можете использовать строковые значения, целые числа, массивы или набор записей. Например:
'Сохранить значение recordset в виде массива
Function FetchEmploymentStatusList
Dim rs
Set rs = CreateObject("ADODB.Recordset")
rs.Open "select StatusName, StatusID
from EmployeeStatus", _
"dsn=employees;uid=sa;pwd=;"
'Получить все строки
FetchEmploymentStatusList = rs.GetRows()
rs.Close
Set rs = Nothing
End Function
Если полученный массив будет часто использоваться, тогда лучше хранить его сразу в виде HTML-списка, чем массив, которое каждый раз нужно преобразовывать в HTML:
'Сохранить значение recordset в виде HTML-списка
Function FetchEmploymentStatusList
Dim rs, fldName, s
Set rs = CreateObject("ADODB.Recordset")
rs.Open "select StatusName, StatusID
from EmployeeStatus", _
"dsn=employees;uid=sa;pwd=;"
s = "<select name=""EmploymentStatus">" & vbCrLf
Set fldName = rs.Fields("StatusName")
Do Until rs.EOF
s = s & " <option>" & fldName _
& "</option>" & vbCrLf
rs.MoveNext
Loop
s = s & "</select>" & vbCrLf
rs.Close
Set rs = Nothing
FetchEmploymentStatusList = s
End Function
Иногда в памяти вашего веб-сервера может быть слишком большое количество данных. "Слишком много", конечно, является спорным вопросом - это зависит от того, сколько памяти вы хотите использовать, а также число элементов для кэширования и частота, с которой эти элементы будут запрашиваться. В любом случае, если вы имеете слишком большое количество данных для кэширования в памяти, подумайте о переносе кэша в текстовый или XML-файл на жесткий диск веб-сервера. Вы можете одновременно комбинировать кэширование на диске и в памяти, чтобы сформировать оптимальную стратегию для вашего сайта.
Заметьте, что при измерении производительности одиночной ASP-страницы, получение данных с диска может не всегда быть быстрее, чем получение равноценных данных из БД. Но "файловое" кэширование уменьшает загрузку БД и сети, а при высокой загрузке БД до, значительно улучшит общую производительность после. Кэширование может быть очень эффективно при кэшировании результатов сложных запросов (например, соединение таблиц), трудоемких процедур сохранения, больших наборов записей. Чтобы убедится, насколько выгодным будет это решение требуется протестировать различные схемы сохранения.
ASP и COM обеспечивают несколько инструментальных средств для создания схем кэширования на диске. Функции набора записей ADO Save() и Open() сохраняют и загружают recordset c диска. Используя эти методы вы можете переписать код из прошлого совета, заменяя запись в объект Application на метод Save() для записи в файл.
Есть несколько других компонентов, которые работают с файлами:
Наконец, рассмотрите вопрос принудительного кэширования информации на диске. Сгенерированный 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:
<!--#include virtual="/includes/list.inc"-->
Второй путь работает значительно быстрее.
Несмотря на то, что кэшировани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+). Следующие компоненты не проворны:
В IIS 4.0 компонент, отмеченный ThreadingModel=Both выполняется быстро. В IIS 5.0 уже не так достаточно. Компонент не должен только быть отмечен как Both, он должен также объединен FTM.
IIS выполняет проверку компонентов, но если вы хотите ее отменить (т.е. хотите позволить непроворным компонентам быть сохраненными в объектах Application или Session), вы можете установить AspTrackThreadingModel в metabase в значение True. Но это (изменение AspTrackThreadingModel) не рекомендуется.
IIS 5.0 выдаст сообщение об ошибке, если Вы пытаетесь сохранить непроворный компонент, созданный с использованием Server.CreateObject, в объекте Application. Вы можете обойти это, используя <object runat=server scope=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 на вашем веб-сайте.
Кэширование соединений ADO - обычно является плохой стратегией при разработке ASP-сайта. Если один объект Connection сохранен в объекте Application и используется на всех страницах, то все страницы будут бороться за использование этого соединения. Если объект Connection сохранен в ASP-объекте Session, то соединение БД будет создано для каждого пользователя. Это создает излишнюю загрузку веб-сервера и БД.
Вместо кэширования соединений БД, создавайте и уничтожайте объекты ADO на каждой ASP странице, которая использует ADO. Это эффективно, потому что IIS имеет встроенное подключение БД. Более точно, IIS автоматически допускает объединение подключений OLEDB и ODBC. Это гарантирует, что создание и уничтожение связей на каждой странице будут эффективны.
Так как соединенные наборы хранят ссылки на подключение БД, это следует, что вы должны не кэшировать соединенные наборы в объектах Application или Session. Однако, вы можете безопасно кэшировать отсоединенные наборы, которые не держат ссылку на подключение. Чтобы отсоединить набор записей, сделайте следующие два шага:
Set rs = Server.CreateObject("ADODB.RecordSet")
rs.CursorLocation = adUseClient ' шаг 1
' Заполните recordset с данными
rs.Open strQuery, strProv
' Теперь отсоедините recordset от источника данных
rs.ActiveConnection = Nothing ' шаг 2
Теперь, когда в предыдущих советах были раскрыты достоинства кэширования данных в объектах 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 не используется, применяйте следующую директиву, помещещаемую вверху страницы:
<% @EnableSessionState=False %>
Одна из основных причин ее применения - то, что Session создает интересную проблему в случае использования фрэймов (frameset). ASP гарантирует, что в любое время будет выполняться только один запрос от Session. Это делается для того, чтобы при одновременном запросе одним пользователем нескольких страниц, только один ASP-запрос был обработан сессией, что помогает избежать проблем многопоточного доступа к объекту Session. К сожалению, в результате этого все страницы в frameset будут загружаться последовательно, а не одновременно, и пользователю придется продолжительное время ждать полной загрузки. Мораль этой истории: если вы не уверены, что с использованием фрэймов и Session ваше приложение правильно работает, то используйте:
<% @EnableSessionState=False %>
Альтернативой использованию объекта Session являются многочисленные параметры управления Session. При передаче малых объемов данных (менее 4 Кб) обычно рекомендуется использовать Cookies, переменные QueryString и скрытые (hidden) переменные форм. При использовании большого количества передаваемых параметров (например, корзина произведенных заказов в он-лайн магазине) наиболее лучший выбор - конечная база данных.
Если в вашем приложении используется много функций VBScript или JScript, то зачастую производительность можно улучшить поместив этот код в откомпилированный COM-объект. Обычно откомпилированная программа выполняется значительно быстрее, чем интерпретируемый код, поэтому откомпилированные COM-объекты будут работать более эффективно, чем вызываемые методы скрипта.
Выделение (инкапсуляция) кода в COM-объект имеет следующие преимущества (не считая производительности):
Но наряду с, казалось бы, неоспоримыми достоинствами 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.
Данный совет небольшой, но не менее важный в оптимизации ASP, чем все предыдущие. Суть его в следующем: лучше всего объявлять переменные только по мере необходимости и сразу удалять их, как только они становятся ненужными. Это относится и к COM-объектам и к указателям открываемых файлов и другим используемым ресурсам.
Соединения (Connection) ADO и рекордсеты - первостепенные кандидаты для этой оптимизации. Использовав recordset или сonnection для отображения данных сразу же удаляйте эти переменные из памяти, не дожидаясь конца страницы. Не позволяйте рекордсету или соединению остаться незакрытыми.
Например, если вы создаете соединение и открываете набор записей следующим образом:
<%
Set cmdDC = Server.CreateObject("ADODB.Command")
cmdDC.ActiveConnection = _
"DRIVER={Microsoft Access Driver (*.mdb)};" _
& "DBQ=" & server.mappath("/database.mdb")
cmdDC.CommandText = "SELECT * FROM books;"
Set rsDC = Server.CreateObject("ADODB.Recordset")
rsDC.Open cmdDC
%>
....
то закройте их вот так:
<% rsDC.Close Set rsDC = Nothing Set cmdDC = Nothing %>
Любые другие переменные Microsoft VBScript также лучше устанавливать в Nothing.
И ASP и MTS/COM+ имеют параметры конфигурации, которые позволяют вам выбрать альтернативу между надежностью и производительностью. Вы должны сделать разумный выбор при разработке ваших ASP-приложений.
Параметры 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
Компоненты 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. Так что, лучше всего попробовать самому и решить, которая конфигурация непосредственно для вас наилучшим образом выполняет ваши потребности.
Используйте директиву Option Explicit в ваших .asp файлах. Расположенная в самом верху .asp файла, она заставляет разработчика объявлять все переменные, которые он использует. Многие программисты считают, что это позволяет быстрее отлаживать приложения, исключая, таким образом, ошибки в написании имен переменных и невнимательное создание новых переменных (например, MyXLMString=... вместо MyXMLString=).
Но наиболее важно то, что работа с объявленными переменными будет быстрее, чем с необъявленными. Дело в том, что в случае необъявления переменной ссылка на нее происходит по ее имени каждый раз как она используется, тогда как после объявления доступ к переменной происходит с использованием ее уникального указателя, что значительно экономит время.
Таким образом, использование директивы Option Explicit гарантирует, что все используемые переменные объявлены и доступ к ним будет максимально быстрым.
Локальные переменные - это переменные, которые объявлены внутри подпрограмм и функций. Доступ к локальной переменной в пределах функции или подпрограммы значительно быстрее, чем доступ к такой же глобальной переменной. Также использование локальных переменных делает ваш код "чище" и понятнее, поэтому используйте их, когда Вы можете.
При вызове COM в ASP, вы должны копировать частоиспользуемые данные объекта в переменные ASP-скрипта. Это сократит количество запросов методов COM, которые являются относительно трудоемкими по сравнению с обращением к переменным самого скрипта. При вызове объектов Collection и Dictionary этот совет также сокращает время запросов.
Вообще, если вы пользуетесь объектом данных больше, чем однажды, поместите данные в переменную ASP-скрипта. Главной целью этой оптимизации являются переменные объекта Request (Form и QueryString). Например, на вашем веб-сайте через QueryString передается переменная UserID. Предположите, что этот UserID упомянут дюжину раз на каждой странице. Вместо вызова Request("UserID") 12 раз, поместите этот UserID в какую-либо переменную наверху ASP страницы и затем используйте эту переменную (а не Request) внутри страницы. Это упразднит 11 COM-запросов!
На практике, доступ к свойствам или методам COM может быть обманчиво дорог. Посмотрите пример, показывающий некоторый обычный код:
Foo.bar.blah.baz = Foo.bar.blah.qaz(1) If Foo.bar.blah.zaq = Foo.bar.blah.abc Then ' ...
Когда этот код выполняется, происходит следущее:
Как видите это ужасно неэффективно (и медленно). Быстрый способ - написать этот код в VBScript: ,pre> Set myobj = Foo.bar.blah 'Объявляем blah однажды! Myobj.baz = myobj.qaz(1) If Myobj.zaq = Myobj.abc Then '...
Если вы используете VBScript 5.0, то можете использовать выражение With:
With Foo.bar.blah
.baz = .qaz(1)
If .zaq = .abc Then '...
...
End With
Пытайтесь избегать переопределяемых (Redim) массивов. Если ваш сервер ограничен физическим размером памяти, то намного лучше сразу установить размер массива в наибольшее значение, которое может быть, либо привести размер к оптимальному и переопределять по мере необходимости. Это, конечно, не означает, что вы должны сделать ваш массив размером в пару мегабайтов, если вы знаете, что столько вам никогда не понадобится.
Пример ниже показывает использование беспричинного использования Dim и Redim.
<% Dim MyArray() Redim MyArray(2) MyArray(0) = "привет" MyArray(1) = "пока" MyArray(2) = "прощай" ... Redim Preserve MyArray(5) MyArray(3) = "больше места" MyArray(4) = "еще больше места" MyArray(5) = "еще чуть-чуть больше места" %>
Есть ли в этом смысл? Гораздо было бы лучше использовать для инициализации массива изначально известный размер (в этом случае 5), чем каждый раз переопределять его. Определяя массив сразу вы будете тратить впустую небольшое количество памяти (если не все элементы массива используются), но выгодой будет скорость работы вашего скрипта.
Вы можете буферизировать целую страницу, включив "response buffering". Это минимизирует количество записей в браузер и, таким образом, улучшит производительность. Каждая запись имеет много непроизводительных издержек (и в самом IIS и в том количестве данных, посланных по проводам), так что меньшее количество записей будет лучше. TCP/IP работает намного более эффективно когда возможно посылать несколько больших блоков данных, чем при пересылке многочисленных маленьких блоков (из-за медленного начала процесса пересылки и сложных алгоритмов проверки).
Есть два пути использования "response buffering". Первый путь - вы можете включить response buffering для приложения, взятого в целом, используя Internet Services Manager. Это рекомендуемый подход, поэтому response buffering включен по-умолчанию для новых ASP-приложений в IIS 4.0 и IIS 5.0. Второй путь - вы можете активировать буферизацию, поместив следующую линию кода вверху ASP-страницы:
<% Response.Buffer = True %>
Эта линия кода должна быть выполнена прежде, чем любые данные response был записаны в браузер (т.е. прежде, чем появится любой код HTML в ASP-скрипте и прежде, чем были установлены любые Cookies, используя Response.Cookies). Вообще, лучше включить response buffering, как указано в первом случае. Это позволит вам избежать применения вышеупомянутой линии кода в каждой странице.
Response.Flush
Есть только одна общая проблема относительно буферизации Response - то, что пользователи чувствуют ASP-страницы менее "отзывчивыми" (даже при том, что время полного получения готовой страницы получается меньше) потому что они должны ждать полную страницу, которая будет произведена прежде, чем, они начинают видеть что-нибудь. Для длинных страниц, вы можете выключить буферизацию, установив Response.Buffer = False. Однако, лучшей стратегией будет использование метода Response.Flush. Этот метод показывает весь HTML, который был записан ASP в браузер. Например, после записи 100 строк из таблицы с 1000-ю записей, ASP может вызывать Response.Flush, чтобы вынудить показать браузер уже готовые 100 строк; это позволяет пользователю увидеть первые 100 строк таблицы прежде, чем остальные строки будут будут получены.
(Заметьте, что в вышеупомянутом примере таблицы с тысячью записей некоторые браузеры не будут отображать таблицу, пока они не получат заключительный HTML-тег </table>. Так что проверьте ваш браузер на этот счет. Чтобы обойти эту проблему, попробуйте разделить таблицу на несколько более меньших таблиц (с меньшим количеством строк) и вызывать Response.Flush после каждой из них. Новые версии Internet Explorer отображают таблицы прежде, чем они полностью закончены и будут показывать их еще быстрее, если вы определите ширину столбцов таблицы - это поможет избежать расчетов, которые требуются браузеру для самостоятельного вычисления ширины столбцов путем измерения длины строк данных в каждой ячейке таблицы.
Другая обычная проблема с буферизацией Response - то, что она может использовать много серверной памяти при генерации очень больших страниц. Если вам необходимо генерировать такие страницы, то совет будет тем же - попробуйте сочетать буферизацию и Response.Flush.
Однолинейная конструкция VBScript <% = выражение %> записывает значение "выражения" в исходящий ASP-поток. Если буферизация response не включена (см. Совет 14), то при частом использовании таких выражений, каждое из них приведет к записи данных в браузер путем передачи по сети множества маленьких пакетов, что выполняется медленно. Точно также производительность приложения снижается при частом чередовании маленьких кусочков ASP-кода и HTML. Поэтому данный совет состоит в следующем: замените рядом стоящие однолинейные конструкции одним вызовом Response.Write. Например, в следующем примере отображения таблицы БД показано необоснованно частое переключение в каждой строке между однолинейным кодом VBScript и тэгами HTML:
<table>
<% For Each fld in rs.Fields %>
<th><% = fld.Name %></th>
<%
Next
While Not rs.EOF
%>
<tr>
<% For Each fld in rs.Fields %>
<td><% = fld.Value %></td>
<% Next
</tr>
<% rs.MoveNext
Wend %>
</table>
Ниже приводится более эффективный код, содержащийся в едином блоке VBScript и призванный ускорить отображение данных:
<table>
<%
For each fld in rs.Fields
Response.Write ("<th>" & fld.Name & "</th>" & vbCrLf)
Next
While Not rs.EOF
Response.Write ("<tr>")
For Each fld in rs.Fields %>
Response.Write("<td>" & fld.Value & "</td>" & vbCrLf)
Next
Response.Write "</tr>"
Wend
%>
</table>
Этот совет имеет намного больший эффект когда буферизация response выключена, однако ее включение и следование данному совету будет иметь лучший результат для производительности ваших ASP-приложений.
Если пользователь нетерпелив и торопится, он может отказаться от вашей просмотра 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-ти строк.
Если вам нужно обращаться к объектам, которые затем могут быть не использованы в коде (особенно объекты, содержащиеся в объектах Server или Application), попробуйте объявлять их в global.asa используя следующий синтакс:
<object runat=server id=objname>
Потому что метод Server.CreateObject, который также используется для этих целей, создает объект немедленно, который будет использовать ресурсы, независимо от того, будете ли вы использовать объект в дальнейшем или нет. Тег <object id=objname> объявляет objname, но objname фактически не создается до первого обращения к любому из его методов или свойств.
При использовании ADO разработчики часто включают adovbs.txt чтобы получить доступ к различным константам ADO. Этот файл должен быть включен в каждую страницу, в которой нужно использовать эти константы. Но этот файл констант достаточно большой и увеличивает время трансляции каждой ASP-страницы и размер скрипта.
В IIS 5.0 введена способность связать с библиотекой типов компонента, которая позволяет вам один раз сослаться на библиотеку типов и использовать ее на каждой ASP-странице. Причем в каждой странице не надо будет компилировать файл констант и разработчикам компонентов не надо формировать файлы VBScript #include для использования в ASP.
Чтобы обращаться к ADO TypeLib разместите одно из следующих выражений в Global.asa:
<!-- METADATA NAME="Microsoft ActiveX Data Objects 2.5 Library"
TYPE="TypeLib" UUID="{00000205-0000-0010-8000-00AA006D2EA4}" -->
или
<!-- METADATA TYPE="TypeLib"
FILE="C:\Program Files\Common Files\system\ado\msado15.dll" -->
Современные браузеры имеют широко развитую поддержку XML, DHTML, java-апплетов и Remote Data Service. Пользуйтесь преимуществами этих возможностей всякий раз, когда можете. Все эти технологии помогают сократить на запросах к серверу и обратно, выполняя клиентскую проверку правильности ввода данных (например, проверку, имеет ли кредитная карта правильную контрольную сумму и т.п.). Сократив на обращениях клиент-сервер, вы снимите дополнительную нагрузку с сервера, тем самым - сократите сетевой траффик (хотя начальная страница, посланная браузеру, скорее всего будет большей), а также снизите нагрузку с любых других конечных ресурсов, к которым обращается ваш север (базы данных и пр.). Кроме того, пользователю не надо будет ждать новую страницу с сообщением об ошибке и предложением вернуться назад. Однако все это не означает, что вам надо просто перенести всю вашу проверку с сервера на клиента, нет. Вы должны всегда делать проверку вводимых данных на сервере, потому что она поможет защитить против хакеров или браузеров, которые не поддерживают ваши клиентские процедуры проверки.
Много было сделано для создания HTML, "независимого от браузера". Это часто препятствует разработчику при извлечении выгоды от популярных особенностей браузеров, которые могли бы приносить пользу. Для высокопроизводительных веб-сайтов, которые беспокоятся о "досягаемости" для браузеров, хорошей стратегией будет оптимизация страниц под наиболее популярные программы просмотра. Особенности браузера могут быть легко обнаружены в ASP используя Browser Capabilities Component ("компонент возможностей браузера"). Инструментальные средства типа Microsoft FrontPage могут помочь вам при проектировании кода, который будет работать с теми браузерами и версиями HTML, которые вы хотите.
Множество программистов делают образование строк в циклах следующим образом:
s = "<table>" & vbCrLf
For Each fld in rs.Fields
s = s & " <th>" & fld.Name & "</th> "
Next
While Not rs.EOF
s = s & vbCrLf & " <tr>"
For Each fld in rs.Fields
s = s & " <td>" & fld.Value & "</td> "
Next
s = s & " </tr>"
rs.MoveNext
Wend
s = s & vbCrLf & "</table>" & vbCrLf
Response.Write s
В таком подходе есть несколько проблем. Во-первых, неоднократная конкатенация (соединение) строк берет квадратичное время или если сказать менее формально, то - время, которое потребуется на выполнение цикла, пропорционально квадрату количества записей к числу полей. Более простой пример сделает это более понятным.
s = ""
For i = Asc("A") to Asc("Z")
s = s & Chr(i)
Next
На первом шаге цикла вы получаете одиносимвольную строку "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() или однолинейным скриптом (<% = fld.Value %>). Если буферизация response включена (как это должно быть), это будет быстро, как Response.Write только добавляет данные к концу буфера response. Никакое перераспределение не выполняется и это очень эффективно.
В отдельных случаях преобразования ADO-рекордсета в HTML-таблицу можно попробовать использование GetRows или GetString.
Если вы соединяете строки в JScript, то там строго рекомендуется использование оператора "+="; т.е. используйте s += "строка", а не s = s + "строка".
По умолчанию в ASP отключено кэширование в веб-браузере и proxy. Смысл этого заключается в том, что ASP-страница - по своей природе динамическая и обычно содержит информацию, которая изменяется со временем. Если ваша страница содержит постоянные данные и не требует регенерации при каждом запросе, то вы должны включить кэширование для браузера и прокси. Это позволит браузерам использовать "кэшируемую" копию страницы в течение некоторого отрезка времени, которым вы можете управлять. Кэширование может значительно снизить нагрузку на вашем сервере.
Какие из динамических страниц могут быть кандидатами на кэширование? Вот некоторые примеры:
Заметьте, что с кэшированием в браузере или кэшированием proxy, вы получите меньшее количество хитов, зарегистрированных на вашем сервере. Поэтому, если вы хотите точно измерять количество просмотров страниц или количество показов баннеров, то скорее, всего вы не захотите воспользоваться кэшированием.
Кэширование в браузере управляется свойством "Expires" HTTP-запроса, который посылает веб-сервер браузеру. ASP обеспечивает два простых механизма, чтобы установить это свойство. Чтобы заставить страницу "устареть" через несколько минут - установите свойство Response.Expires. Следующий пример сообщает браузеру, что содержание данной страницы истекает через 10 минут:
<% Response.Expires = 10 %>
Установка Response.Expires в отрицательное значение или 0 отключает кэширование. Использование большого отрицательного числа, например -1000 (немного больше, чем 1 день) будет лучше, в силу несоответствий между временем на сервере и в браузере. Второе свойство Response.ExpiresAbsolute позволяет вам устанавливать точное время, в течении которого содержание "устареет":
<% Response.ExpiresAbsolute = #May 31,2001 13:30:15# %>
Вместо использования объекта Response для того, чтобы установить истечение срока действия страницы, вы можете использовать HTML-тэг <МЕТА>. Большинство браузеров "понимают" эту директиву, хотя proxy ее не используют.
<META HTTP-EQUIV="Expires" VALUE="May 31,2001 13:30:15">
Наконец, вы можете указывать является ли содержание допустимым для кэширования HTTP-proxy используя свойство Response.CacheControl. Установив это свойство в значение "Public" вы разрешите proxy кэшировать содержание страницы.
<% Response.CacheControl = "Public" %>
По умолчанию это свойство всегда установлено в "Private". Обратите внимание, что вы не должны разрешать кэширование для proxy страниц, которые показывают данные, специфичные для каждого пользователя, поскольку в этом случае proxy может показывать страницы пользователям с информацией других.
Метод Response.Redirect сообщает браузеру запросить другую страницу. Этот метод часто используется, чтобы переназначить запрос пользователя, например, к странице идентификации (login) или странице с сообщением об ошибке. Redirect вынуждает сделать новый запрос страницы, результат этого - то, что браузер должен сделать два запроса к веб-серверу и веб-сервер должен обработать дополнительный запрос. В новой версии IIS 5.0 введена новая функция Server.Transfer, которая передает выполнение другой ASP-странице на том же самом сервере. Это помогает избежать дополнительного запроса "браузер-сервер" и в общем и целом приводит к улучшению производительности системы, а также к более короткому времени редиректа и отображения страницы в браузере пользователя.
Следующий скрипт демонстрирует использование Server.Transfer для переназначения запроса в зависимости от значения переменной:
<%
If Session("blnPageCompleted") Then
Server.Transfer("/SalesData/page2.asp")
Else
Server.Transfer("/SalesData/warning.asp")
End if
%>
Server.Transfer посылает запрос из одного выполняемого ASP-файла к другому файлу. В течении редиректа выполнение первоначально запрошенного ASP-файла немедленно прекращается без очистки буфера вывода.
Этот совет относится не только к ASP-программистам, но и ко всем веб-разработчикам, кто в своей работе создает html-страницы.
Проверьте, всегда ли вы используете замыкающий слэш (trailing slash) - наклонную черту вправо (/) в URL каталогов веб-сайта. Если опустить этот слэш браузер будет делать запрос к серверу, только для того, чтобы сообщить, что он спрашивает о каталоге. Затем браузер будет делать второй запрос, но уже со слэшем на конце URL, и только тогда веб-сервер будет возвращать "главный" (default) документ этого каталога или выдавать список файлов каталога, если в нем нет главного документа и разрешен просмотр каталога. Добавление к URL замыкающего слэша позволяет избежать первого бесполезного запроса к веб-серверу, что, естественно, экономит время, которое требуется для перехода по ссылке. Чтобы подобная ссылка выглядела более приятнее вы можете опустить слэш в названии URL.
Например:
<a href="http://www.relib.com/asp/" title="Раздел для ASP-программистов">http://www.relib.com/asp</a>
Этот совет также относится и к записи ссылок на главную страницу веб-сайта. Используйте
<a href="http://www.relib.com/">
а не
<a href="http://www.relib.com">
Вызов серверных переменных заставляет ваш веб-сайт делать специальный запрос к серверу и собирать все серверные переменные, а не только ту, которую вы требовали. Это похоже на ситуацию, когда вам нужно найти определенный документ в папке, которая лежит на чердаке. Когда вам нужен один документ, вы должны идти на чердак, найти сначала всю папку, и только потом найти нужный документ. Это примерно то же самое, что случится, когда вы запрашиваете значение серверной переменной - запрос к серверу станет причиной повышения нагрузки на сервер. Хотя последующие запросы о других серверных переменных уже не вызовут большой нагрузки.
Также пытайтесь избегать неопределенных вызовов объекта Request (например, Request("Данные")). Для элементов, находящихся не в Request.Cookies, Request.Form, Request.QueryString или Request.ClientCertificate, имеется неявный запрос к Request.ServerVariables. Запрос к коллекции Request.ServerVariablesе выполняется намного медленнее, чем доступ к другим коллекциям.
Системные компоненты постоянно обновляются, поэтому рекомендуется, чтобы вы модернизировали (сделали 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). Каждое из перечисленного позволяет улучшить выполнение работы и увеличить надежность.
Производительность - это особенность любого приложения, особенно, если речь идет о об интернет или использовании баз данных. Если ваш разрабатываемый веб-сайт относительно популярен и его аудитория постоянно растет, то не приняв в расчет проблемы повышения производительности еще в процессе проектирования будущего приложения, позже вам все равно придется переписывать исходный код. Данные советы затрагивают только основные часто встречаемые проблемы, которые можно решить несложным образом. Дополнительную информацию на русском языке о программировании с использованием технологии Active Server Pages и разработке веб-сайтов вы можете найти на сайте Relib.com (http://www.relib.com).