ASP - Оптимизация сценариев ASP

Оптимизация сценариев ASP

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

Ниже приведен ряд советов, которые помогут уменьшить проблемы быстродействия в ASP-сценариях:

• Кэшируйте объекты и данные, имеющие приложение областью определения, или создавая объекты в Global.asa, или создавая их по требованию в отдельных сценариях и назначая им приложение в качестве области определения.
• Объединяйте вывод, формируемый вызовами Response.Write, используя буферизацию ASP, которая в IIS 5.0 включена по умолчанию. Чтобы увеличить видимое быстродействие приложений, использующих буферизованный вывод, при выполнении операций, требующих много времени, приложение должно периодически использовать Reponse.Flush для поддержания контакта с пользователем.

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

• Используйте теги <OBJECT> вместо Server.CreateObject при создании объектов, имеющих приложение или сеанс областью определения. Смысл этой рекомендации состоит в том, что IIS создает экземпляр объекта, заданного тегами <OBJECT>, только при использовании его. Если используются теги <OBJECT>, а сценарий не использует объект, приложение небудет создавать экземпляр объекта. Server.CreateObject, напротив, вынуждает IIS немедленно создавать экземпляра oбъекта, вне зависимости от использования объекта сценарием.
• Используйте локальные переменные, избегайте общих переменных. Обработчик сценариев ASP получает доступ к локальным переменным быстрее, чем к общим, поскольку для доступа к значению локальной переменной не нужно искать по всему пространству имен.
• Проверяйте сведения, введенные пользователем на стороне клиента, где возможно, это уменьшит требуемый двойной обмен по протоколу HTTP. Если обозреватель является полнофункциональным, используйте его возможности, освобождая ресурсы сервера для более важных задач. Конечно, некоторые проверки целостности следует выполнять на сервере, как предварительные меры предосторожности от повреждения данных..
• Копируйте отдельные значения из семейств в локальные переменные, если значение будет использоваться неоднократно. Это избавит ASP от поиска по семейству для каждого обращения.
• Отключите состояние сеанса для всего приложения, если это возможно. Если приложение не требует использования сеансов IIS, следует использовать оснастку IIS для запрещения состояния сеанса для всего приложения. Сеансы в IIS остаются в памяти, и память выделенная под сеансы не будет освобождена до прерывания сеанса или истечения его времени ожидания. Если приложение используется многими конкурирующими пользователями, ресурсы сервера могут истощиться, что скажется на быстродействии. Если некоторые части приложения не требуют состояния сеанса, yследует запретить состояние сеанса для этих страниц с помощью директивы @ENABLESESSIONSTATE.

Выключение состояния сеанса во всех возможных местах особенно полезно для страниц, содержащих элемент <FRAMESET>. Некоторые обозреватели, включая Internet Explorer, будут использовать отдельные потоки для обработки отдельных рамок в группе рамок. Если состояние сеанса включено для страницы с группой рамок, выигрыш в быстродействии клиентской части за счет использования параллельных потоков будет потерян, поскольку IIS будет вынужден последовательно обрабатывать потоки для отдельных запросов.

• Если используется состояние сеанса, избегайте размещения больших объемов данных в объекте Session и в состоянии сеанса. Сеансы в IIS остаются в памяти, и память выделенная под сеансы не будет освобождена до прерывания сеанса или истечения его времени ожидания. Если приложение используется многими конкурирующими пользователями, ресурсы сервера могут истощиться, что скажется на быстродействии.
• Не оставляйте пустыми Session_OnStart или Session_OnEnd.
• Обратите особое внимание на эффект от изменения конфигураций IIS и ASP. Дополнительные подробности см. Оптимизация конфигурации IIS.
• Если страница ASP выполняется как часть приложения, для отладки укажите приложение как внешнее (out-of-process). Изоляция приложений, введенная в IIS 4.0, является полезной возможностью. Межпроцессная сортировка требуется для поддержки изолирования процессов, однако она может вызвать некоторые накладные расходы обработки ASP. Эта разница в накладных расходах довольно существенна для простых ASP-страниц и менее заметна для более сложных страниц. Чтобы увеличить быстродействие и улучшить масштабируемость, рассмотрите запуск приложения вне процесса, пока оно не отлажено и не работает достаточно устойчиво, чтобы выполняться в одном процессе с IIS.
• Если возможно, избегайте использования оператора ReDim для массива. Более эффективно сразу выделить память под полный объем массива при инициализации массива.