25 порад щодо оптимізації ASP-додатків, Різне, Програмування, статті

Введення

Дані поради вводять в проблему підвищення продуктивності роботи додатків, що використовують технології Microsoft Active Server Pages (ASP) і Visual Basic Scripting Edition (VBScript). Більшість з них були багаторазово обговорені і c успіхом перевірені на практиці і будуть цікаві як новачкам у програмуванні ASP і VBScript, так і тим, хто вже має досвід роботи з цими технологіями. При підготовці рад був використані матеріали c веб-сайту корпорації Microsoft Corp. (http://www.microsoft.com) І матеріали конференцій Relib.com (http://www.relib.com)


Порада 1: Кешуйте часто використовувані дані на сервері

Типова ASP-сторінка отримує дані з бази даних і потім виводить їх у форматі HTML. Незалежно від швидкості роботи вашої бази даних, отримання даних з пам’яті сервера буде набагато швидше, ніж обробка sql-запроса до кінцевої базі даних. Отримання даних, збережених на жорсткому диску сервера, також звичайно швидше, ніж отримання інформації з БД. Тому одним з основних шляхів збільшення швидкості роботи вашої ASP-сторінки є кешування часто використовуваної інформації в пам’яті або на жорсткому диску.

Кешування даних – це класичний компроміс “місце або час”. Якщо ви обрали для кешування правильний матеріал, ви можете бачити значне підвищення продуктивності вашої програми. Щоб кешування було ефективним потрібно використовувати для тимчасового зберігання тільки ті дані, які багаторазово використовуються для виведення і щоразу трудомісткі для повторних обчислень. Кеш, повний застарілої інформації, буде марною тратою пам’яті сервера.

Дані, які змінюються не часто, будуть гарним кандидатом для кешування, тому що вам не треба буде хвилюватися щодо їх синхронізації через якийсь час з кінцевою базою даних. Випадають списки (сombo-box), таблиці посилань, пункти меню, і змінні конфігурації сайту (включаючи імена DSN, адреси IP і URL) – перші кандидати для зберігання в кеші. Зауважте, що ви можете кешувати подання даних багато швидше, ніж дані самі себе. Якщо ASP-сторінка змінюється не так часто і її тимчасовий кеш буде досить значним (наприклад, повний каталог виробів фірми), спробуйте використовувати згенеровані HTML-сторінки, ніж кожен раз завантажувати сервер генерацією ASP-сторінок.


Порада 2: Кешуйте часто використовувані дані в об’єктах Application або Session

Об’єкти Application і Session служать для зберігання даних в пам’яті, значення яких можуть бути доступні між декількома HTTP-запитами (на відміну від звичайних змінних, чиї значення доступні тільки в тілі однієї ASP-сторінки). Дані об’єкта Session доступні тільки одному користувачу (протягом його сесії), в той час як дані Application доступні всім користувачам веб-сайту. Тому часто перед розробником виникає питання: в якому з об’єктів зберігати часто використовувані дані. Зазвичай, для ініціалізації змінних цих об’єктів використовуються процедури файлу Global.asa – Application_OnStart () або Session_OnStart () відповідно. Якщо у вашому Global.asa ще немає цих процедур, то ви можете додати їх самі або ініціалізувати змінні, коли це буде необхідно. Прикладом може бути наступна процедура, яка використовує Application для зберігання значень багаторазово використовується змінної EmploymentStatusList. Процедура перевіряє існування даних в EmploymentStatusList і при необхідності розраховує їх заново:

<%
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

Рада 3: Кешуйте дані на диску веб-сервера

Іноді в пам’яті вашого веб-сервера може бути занадто велику кількість даних. “Надто багато”, звичайно, є спірним питанням – це залежить від того, скільки пам’яті ви хочете використовувати, а також число елементів для кешування і частота, з якою ці елементи будуть запитуватися. У будь-якому випадку, якщо ви маєте дуже велику кількість даних для кешування в пам’яті, подумайте про перенесення кеша в текстовий або 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”–>

Другий шлях працює значно швидше.


Рада 4: Уникайте кешувати повільні компоненти в об’єктах Application або Session

Незважаючи на те, що кешірованіe даних в об’єктах Application або Session може бути гарною ідеєю, кешування COM-об’єктів може мати серйозні пастки. Занесення найбільш використовуваних COM-об’єктів у об’єкти Application або Session часто спокушає, але, на жаль, багато COM-об’єктів, включаючи всі, написані в Visual Basic 6.0 або раніше, можуть викликати серйозні критичні проблеми після збереження в об’єктах Application або Session.

Зокрема, будь-який компонент, який виконується повільно, викличе критичні проблеми коли кешується в об’єктах Session або Application. Бистрий (моторний non-agile) компонент – компонент, позначений ThreadingModel = Both, який об’єднаний Free-threaded marshaler (FTM), або – компонент, позначений ThreadingModel = Neutral. (Neutral – нова модель в WindowsR 2000 and COM +). Наступні компоненти не моторні:


В IIS 4.0 компонент, відзначений ThreadingModel = Both виконується швидко. В IIS 5.0 вже не так досить. Компонент не повинен тільки бути відзначений як Both, він повинен також об’єднаний FTM.

IIS виконує перевірку компонентів, але якщо ви хочете її скасувати (тобто хочете дозволити неспритні компонентам бути збереженими в об’єктах Application або Session), ви можете встановити AspTrackThreadingModel в metabase в значення True. Але це (зміна AspTrackThreadingModel) не рекомендується.

IIS 5.0 видасть повідомлення про помилку, якщо Ви намагаєтеся зберегти неспритні компонент, створений з використанням Server.CreateObject, в об’єкті Application. Ви можете обійти це, використовуючи в Global.asa, але це також не рекомендується, оскільки це веде до проблем (черги і сериализация), пояснюється нижче.

Що ж все-таки неправильно якщо ви кешіруете неспритні компоненти? Неспритні компонент, кешируємой в об’єкті Session блокує Session від інших робочих потоків (thread) ASP. ASP обслуговує пул (контейнер) робочих потоків, запитуваних іншими сервісами. Зазвичай, новий запит обробляється першим доступним потоком. Якщо Session блокована, то запит повинен чекати потік, коли він стане доступним. Проведемо аналогію, яка допоможе зрозуміти цю ситуацію: ви йдете в магазин, вибираєте кілька булок, і платите за них в касі # 3. Всякий раз, після того як ви вибрали булки в тому магазині, ви завжди оплачуєте їх у касі # 3, навіть в тому випадку, коли в інших касах коротше чергу або навіть взагалі немає покупців.

Збереження неспритні компонентів в об’єкт Application накладає настільки ж негативний ефект на продуктивність. ASP створює спеціальний потік для виконання меделенних компонентів у межах Application. Це має два наслідки: всі запити шикуються в чергу до цього потоку і всі запити серіалізуются. Вибудовування в чергу означає, що параметри були збережені в загальнодоступній області пам’яті; запити перемикаються до спеціального потоку; метод компонента виконаний; результати шикуються в загальнодоступну область. Серіалізация (перетворення в послідовну форму) означає, що всі методи виконуються в один час. Для двох різних потоків ASP не можливо одночасне виконання методів загальнодоступного компонента. Це знищує багатопотоковості (паралелізм), особливо на мультипроцесорних системах. Найгірше те, що всі неспритні компоненти в межах Application спільно використовують один потік (“Host STA”), так що негативні результати сериализации в наявності.

Збентежені? Є деякі загальні правила. Якщо Ви пишете об’єкти в Visual Basic (6.0 або раніше), не зберігайте їх в об’єктах Application або Session. Якщо ви не знаєте потокову модель об’єкта, не зберігайте його в кеші. Замість кешування де-небудь неспритні об’єктів, ви повинні створити і пересувати їх на кожній сторінці. Об’єкти виконаються безпосередньо в робочому потоці ASP і не буде ніякої черги або сериализации. Вироблене буде адекватна, якщо COM-об’єкти запущені під IIS і якщо вони не використовують багато часу, щоб инициализироваться і знищуватися. Зауважте, що однопотокові (single-threaded) об’єкти не повинні використовуватися цей шлях. Будьте уважним – VB може створювати однопотокові об’єкти! Якщо ви використовуєте однопотокові об’єкти, цей шлях (типу таблиці Microsoft Excel) не розраховує на високу продуктивність.

Набори записів (recordset) ADO можуть безпечно кешуватися коли ADO відзначений як Free-threaded. Щоб зробити ADO як Free-threaded використовуйте файл Makfre15.bat, який зазвичай зафіксований в каталозі \Program FilesCommon FilesSystemADO.

Попередження: ADO не повинен бути Free-threaded, якщо ви використовуєте Microsoft Access як БД. Набір записів ADO повинен бути також взагалі від’єднано, якщо ви не можете управляти конфігурацією ADO на вашому веб-сайті.


Порада 5: Не Кешуйте з’єднання БД в об’єктах Application або Session

Кешування з’єднань ADO – зазвичай є поганою стратегією при розробці ASP-сайту. Якщо один об’єкт Connection збережений в об’єкті Application і використовується на всіх сторінках, то всі сторінки будуть боротися за використання цього з’єднання. Якщо об’єкт Connection збережений в ASP-об’єкті Session, то з’єднання БД буде створено для кожного користувача. Це створює зайву завантаження веб-сервера та БД.

Замість кешування з’єднань БД, створюйте і знищуйте об’єкти ADO на кожній ASP сторінці, яка використовує ADO. Це ефективно, тому що IIS має вбудоване підключення БД. Більш точно, IIS автоматично допускає об’єднання підключень OLEDB і ODBC. Це гарантує, що створення і знищення зв’язків на кожній сторінці будуть ефективні.

Так як сполучені набори зберігають посилання на підключення БД, це випливає, що ви повинні не кешувати з’єднані набори в об’єктах Application або Session. Проте, ви можете безпечно кешувати від’єднані набори, які не тримають посилання на підключення. Щоб від’єднати набір записів, зробіть наступні два кроки:

    Set rs = Server.CreateObject(“ADODB.RecordSet”)
rs.CursorLocation = adUseClient крок 1

Заповніть recordset з даними
rs.Open strQuery, strProv

Тепер від’єднайте recordset від джерела даних
rs.ActiveConnection = Nothing крок 2


Рада 6: Розумне використання об’єкта Session

Тепер, коли в попередніх радах були розкриті гідності кешування даних в об’єктах Applications і Sessions, вам пропонується намагатися уникати використання об’єкта Session. Сесії мають кілька пасток коли використовуються на завантажених сайтах. Під “завантаженими” маються на увазі сайти з сотнями запитуваних сторінок в секунду або тисячами користувачів одночасно. Ця рада також важливий для сайтів, які повинні масштабуватися горизонтально – тобто ті сайти, які використовують кілька серверів для розподілу навантаження і забезпечення відмовостійкості при збоях. Для менших сайтів, типу intranet-сайтів, переваги застосування Sessions все ж переважують.

Узагальнюючи, ASP автоматично створює Session для кожного користувача, який звертається до веб-сервера. Кожна сесія займає приблизно 10 Кб пам’яті (понад будь-яких даних, які зберігаються в Session) і трохи уповільнює виконання всіх запитів. Сесія залишається чинною до закінчення таймауту (timeout), звичайно 20 хв.

Але найбільша проблема при використанні сесій – це не продуктивність, а розширюваність. Сесії не охоплюють усі задіяні веб-сервера; як тільки Session була створена на одному сервері її дані залишаються там. Це означає, що якщо ви використовуєте сесії на мультисерверної веб-сайті, ви повинні придумати стратегію для обробки запитів кожного користувача, які повинні бути завжди направлені на сервер, на якому існує сесія цього користувача. Це називається “застреванием” користувача на сервері (або “липкою сесією”).

Об’єкт Application також не охоплює всі сервера: якщо вам потрібно спільно використовувати та оновлювати дані Application через веб-сервера, вам потрібно використовувати кінцеву базу даних. Однак незмінні (Read-only) дані Application все ж корисні на мультисерверної сайтах.

Найбільш критичні до швидкості сайти зазвичай використовують не менше двох веб-серверів. Тому при проектуванні вашого ASP-додатки ви повинні або використовувати “липкі сесії”, або просто уникати застосування об’єкта Session, також як будь-яких інших методів, що зберігають інформацію користувача на різних веб-серверах.

Якщо ж ви не використовуєте Session, то переконаєтеся, що відключили їх. Це можна зробити за допомогою Internet Services Manager (див. документацію по ISM). Але якщо вам все-таки необхідно використовувати сесії, то є кілька шляхів зменшити їхні удари про продуктивності.

Ви можете перемістити вміст, який не вимагає сесій (наприклад, сторінки help і т.д.) в окреме ASP-додаток, у якого сесії вимкнені. Крім того, на сторінках, де об’єкт Session не використовується, застосовуйте наступну директиву, помещещаемую вгорі сторінки:

<% @EnableSessionState=False %>

Одна з основних причин її застосування – те, що Session створює цікаву проблему у випадку використання фреймів (frameset). ASP гарантує, що в будь-який час буде виконуватися тільки один запит від Session. Це робиться для того, щоб при одночасному запиті одним користувачем декількох сторінок, тільки один ASP-запит був оброблений сесією, що допомагає уникнути проблем багатопотокового доступу до об’єкта Session. На жаль, в результаті цього всі сторінки в frameset будуть завантажуватися послідовно, а не одночасно, і користувачеві доведеться тривалий час чекати повного завантаження. Мораль цієї історії: якщо ви не впевнені, що з використанням фреймів і Session ваш додаток правильно працює, то використовуйте:

<% @EnableSessionState=False %>

Альтернативою використанню об’єкта Session є численні параметри управління Session. При передачі малих обсягів даних (менш 4 Кб) звичайно рекомендується використовувати Cookies, змінні QueryString і приховані (hidden) змінні форм. При використанні великої кількості переданих параметрів (наприклад, корзина вироблених замовлень в он-лайн магазині) найбільш кращий вибір – кінцева база даних.


Порада 7: інкапсулює код в COM-об’єкти

Якщо у вашому додатку використовується багато функцій VBScript або JScript, то найчастіше продуктивність можна поліпшити помістивши цей код в відкомпільований COM-об’єкт. Зазвичай скомпільованій виконується значно швидше, ніж інтерпретується код, тому відкомпілювалися COM-об’єкти будуть працювати більш ефективно, ніж викликаються методи скрипта.


Виділення (інкапсуляція) коду в COM-об’єкт має такі переваги (не вважаючи продуктивності):



  • COM-об’єкти гарні для логічного представлення структури програми.

  • COM-об’єкти дозволяють багаторазове використання одного коду.

  • Багато розробників знаходять код, написаний в VB, C + + або Visual J + + простіше в налагодженні, ніж ASP.

Але поряд з, здавалося б, незаперечними достоїнствами COM-об’єкти мають і недоліки, серед яких – час розробки і потреба в різних навичках програмування. Будьте впевнені, що інкапсуляція в малих ASP-додатках може викликати швидше збитки, ніж прибуток. Зазвичай це трапляється, коли маленька кількість ASP-коду переноситься в об’єкт COM. У цьому випадку накладні витрати від створення і виклику цього об’єкта переважують вигоду від використання інтерпретується програми. Визначити найбільш виграшну комбінацію для продуктивності – використання сценаріїв ASP або COM-об’єктів – можна тільки методом проб і помилок. Зауважимо, що Microsoft значно поліпшила ASP-сценарії і продуктивність ADO в Windows 2000/IIS 5.0 в порівнянні з Windows NT 4.0/IIS 4.0. Таким чином, перевага скомпільованій коду над кодом ASP зменшилося з введенням IIS 5.0 і ваше застосування повинне працювати швидше, порівняно з четвертою версією IIS.


Порада 8: Оголошуйте змінні пізно, а видаляйте рано

Даний рада невеликий, але не менш важливий в оптимізації ASP, ніж всі попередні. Суть його в наступному: найкраще оголошувати змінні тільки в міру необхідності і відразу видаляти їх, як тільки вони стають непотрібними. Це відноситься і до COM-об’єктів і до покажчиків файлів, і іншим використовуваних ресурсів.

З’єднання (Connection) ADO і рекордсети – першорядні кандидати для цієї оптимізації. Використавши recordset або Сonnection для відображення даних відразу ж видаляйте ці змінні з пам’яті, не чекаючи кінця сторінки. Не дозволяйте рекордсету або з’єднанню залишитися незакритими.


Наприклад, якщо ви створюєте з’єднання і відкриваєте набір записів наступним чином:

<%
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.


Рада 9: Out-of-process як компроміс між продуктивністю і надійністю

І 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. Так що, краще всього спробувати самому і вирішити, яка конфігурація безпосередньо для вас найкращим чином виконує ваші потреби.


Рада 10: Використовуйте директиву Option Explicit

Використовуйте директиву Option Explicit в ваших. Asp файлах. Розташована в самому верху. Asp файлу, вона змушує розробника оголошувати всі змінні, які він використовує. Багато програмістів вважають, що це дозволяє швидше налагоджувати програми, виключаючи, таким чином, помилки в написанні імен змінних і неуважне створення нових змінних (наприклад, MyXLMString =… замість MyXMLString =).

Але найбільш важливо те, що робота з оголошеними змінними буде швидше, ніж з неоголошеним. Справа в тому, що у разі неоголошення змінної посилання на неї відбувається по її імені щораз як вона використовується, тоді як після оголошення доступ до змінної відбувається з використанням її унікального покажчика, що значно економить час.


Таким чином, використання директиви Option Explicit гарантує, що всі використовувані змінні оголошені і доступ до них буде максимально швидким.


Рада 11: Використовуйте локальні змінні в підпрограмах і функціях

Локальні змінні – це змінні, які оголошені усередині підпрограм і функцій. Доступ до локальної змінної в межах функції або підпрограми значно швидше, ніж доступ до такої ж глобальної змінної. Також використання локальних змінних робить ваш код “чистіше” і зрозуміліше, тому використовуйте їх, коли Ви можете.


Рада 12: Копіюйте частоіспользуемие дані в змінні

При виклику COM в ASP, ви повинні копіювати частоіспользуемие дані об’єкта в змінні ASP-скрипта. Це скоротить кількість запитів методів COM, які є відносно трудомісткими порівняно зі зверненням до змінних самого скрипта. При виклику об’єктів Collection і Dictionary ця рада також скорочує час запитів.

Взагалі, якщо ви користуєтеся об’єктом даних більше, ніж одного разу, помістіть дані в змінну ASP-скрипта. Головною метою цієї оптимізації є змінні об’єкта Request (Form і QueryString). Наприклад, на вашому веб-сайті через QueryString передається мінлива UserID. Припустімо, що цей UserID згаданий дюжину разів на кожній сторінці. Замість виклику Request (“UserID”) 12 разів, помістіть цей UserID в будь-яку змінну нагорі ASP сторінки і потім використовуйте цю змінну (а не Request) усередині сторінки. Це скасує 11 COM-запитів!


На практиці, доступ до властивостей або методів COM може бути оманливе доріг. Подивіться приклад, який показує деякий звичайний код:

Foo.bar.blah.baz = Foo.bar.blah.qaz(1)
If Foo.bar.blah.zaq = Foo.bar.blah.abc Then …

Коли цей код виконується, відбувається наступне:



  1. Мінлива Foo отримана як глобальний об’єкт.

  2. Мінлива bar отримана як член Foo. Це виявляється запитом COM-метода.

  3. Мінлива blah отримана як член Foo.bar. Це також виявляється запитом COM-метода.

  4. Мінлива qaz отримана як член foo.bar.blah. Так, це також виявляється запитом COM-метода.

  5. Викличте Foo.bar.blah.quaz (1). Ще один запит COM-метода. Уявляєте?

  6. Зробіть кроки від 1 до 3 знову, щоб отримати baz. Система не знає, змінив запит до qaz модель об’єкта, так що кроки 1 до 3 повинні бути виконані знову, щоб отримати baz.

  7. Отримайте baz як член Foo.bar.blah.

  8. Зробіть кроки від 1 до 3 знову і отримаєте zaq.

  9. Зробіть кроки від 1 до 3 вже іншим разом та отримайте abc.

Як бачите це жахливо неефективно (і повільно). Швидкий спосіб – написати цей код в VBScript:, pre> Set myobj = Foo.bar.blah Оголошуємо blah одного разу! Myobj.baz = myobj.qaz (1) If Myobj.zaq = Myobj.abc Then …


Якщо ви використовуєте VBScript 5.0, то можете використовувати вираз With:

With Foo.bar.blah
.baz = .qaz(1)
If .zaq = .abc Then …

End With

Рада 13: Уникайте використання перевизначається масивів

Намагайтеся уникати перевизначається (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), ніж кожен раз перевизначати його. Визначаючи масив відразу ви будете витрачати даремно невелика кількість пам’яті (якщо не всі елементи масиву використовуються), але вигодою буде швидкість роботи вашого скрипта.


Рада 14: Використовуйте буферизацію Response

Ви можете буферізіровать цілу сторінку, включивши “response buffering”. Це мінімізує кількість записів в браузер і, таким чином, поліпшить продуктивність. Кожен запис має багато непродуктивних витрат (і в самому IIS і в тій кількості даних, посланих по проводах), так що менша кількість записів буде краще. TCP / IP працює набагато ефективніше коли можливо посилати кілька великих блоків даних, ніж при пересиланні численних маленьких блоків (через повільне початку процесу пересилання і складних алгоритмів перевірки).

Є два шляхи використання “response buffering”. Перший шлях – ви можете включити response buffering для програми, взятого в цілому, використовуючи Internet Services Manager. Це рекомендований підхід, тому response buffering включений за замовчуванням для нових ASP-додатків в IIS 4.0 та IIS 5.0. Другий шлях – ви можете активувати буферизацію, помістивши наступну лінію коду вгорі ASP-сторінки:

<% Response.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-тег . Так що перевірте ваш браузер на цей рахунок. Щоб обійти цю проблему, спробуйте розділити таблицю на декілька більш менших таблиць (з меншою кількістю рядків) і викликати Response.Flush після кожної з них. Нові версії Internet Explorer відображають таблиці перш, ніж вони повністю закінчені і будуть показувати їх ще швидше, якщо ви визначите ширину стовпців таблиці – це допоможе уникнути розрахунків, які потрібні браузеру для самостійного обчислення ширини стовпців шляхом виміру довжини рядків даних в кожній клітинці таблиці.

Інша звичайна проблема з буферизацією Response – те, що вона може використовувати багато серверної пам’яті при генерації дуже великих сторінок. Якщо вам необхідно генерувати такі сторінки, то рада буде тим же – спробуйте поєднувати буферизацію і Response.Flush.


Рада 15: Групуйте однолінійний код і вирази Response.Write

Однолінійна конструкція 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-додатків.


Рада 16: Використовуйте Response.IsClientConnected перед отриманням великих об’ємів даних

Якщо користувач нетерплячий і квапиться, він може відмовитися від вашої перегляду ASP-сторінки перш, ніж ви почнете виконувати його запит. Якщо він натиснув у браузері Refresh або пішов на іншу сторінку вашого сервера, ви отримаєте новий запит, що стоїть в кінці черги ASP-запитів і “від’єднаний” запит, що стоїть в середині черги. Часто це трапляється коли ваш сервер сильно завантажений (має довгу чергу запитів з, відповідно, великим часом відповіді) і цей новий запит робить ситуацію ще гірше. Немає ніякого сенсу виконувати ASP-скрипт (особливо повільний і великоваговий), якщо користувач більше не з’єднаний зі своїм запитом. Ви можете перевірити це стан, використовуючи властивість Response.IsClientConnected. Якщо воно повертає False ви повинні викликати Response.End і відмовитися від отримання решті частині сторінки. Фактично, IIS 5.0 використовує цю практику – щоразу, коли ASP збирається виконувати новий запит, він перевіряє, щоб побачити як довго запит був у черзі. Якщо він був там більше, ніж 3 секунд, ASP перевірить, з’єднаний чи все ще клієнт і негайно закінчить запит, якщо немає. Ви можете використовувати AspQueueConnectionTestTime, щоб встановити цей таймаут в 3 секунди.

Якщо ви маєте сторінку, яка потребує дуже багато часу для виконання, ви можете перевіряти Response.IsClientConnected на різних стадіях виконання. Коли буферизация активована – гарна ідея також викликати Response.Flush, щоб дати зрозуміти користувачеві, що що-що працює.

Зверніть увагу, що в IIS 4.0 Response.IsClientConnected не буде правильно працювати, якщо ви спочатку не робите Response.Write. Якщо буферизация активована ви будете також повинні робити Response.Flush. На IIS 5.0 немає ніякої потреби в цьому – Response.IsClientConnected працює прекрасно. У будь-якому випадку Response.IsClientConnected потребує певного часу, тому використовуйте її тільки перед дією, яка вимагає, скажімо, по крайней мере, не менше 500 мілісекунд (це великий проміжок часу, якщо у вас велике навантаження на сервер). Тобто ви повинні віддавати собі звіт в діях і не викликати Response.IsClientConnected перед виведенням кожного рядка таблиці БД, набагато краще буде, якщо така перевірка буде рідше, можливо, перед виведенням нових 20-ти або 50-ти рядків.


Рада 17: Оголошуйте об’єкти використовуючи тег

Якщо вам потрібно звертатися до об’єктів, які потім можуть бути не використані в коді (особливо об’єкти, що містяться в об’єктах Server або Application), спробуйте оголошувати їх у global.asa використовуючи наступний Синтакс:

<object runat=server id=objname>

Бо метод Server.CreateObject, який також використовується для цих цілей, створює об’єкт негайно, який буде використовувати ресурси, незалежно від того, чи будете ви використовувати об’єкт надалі чи ні. Тег оголошує objname, але objname фактично не створюється до першого звернення до будь-якого з його методів або властивостей.


Рада 18: Використовуйте оголошення TypeLib для ADO і інших компонентів

При використанні 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”
ENGINE=”TypeLib” UUID=”{00000205-0000-0010-8000-00AA006D2EA4}” –>

або

<!– METADATA ENGINE=”TypeLib”
FILE=”C:Program FilesCommon Filessystemadomsado15.dll” –>


Рада 19: Користуйтеся перевагами клієнтської перевірки правильності даних

Сучасні браузери мають широко розвинену підтримку XML, DHTML, java-аплетів і Remote Data Service. Користуйтеся перевагами цих можливостей кожного разу, коли можете. Всі ці технології допомагають скоротити на запитах до сервера і назад, виконуючи клієнтську перевірку правильності введення даних (наприклад, перевірку, чи має кредитна карта правильну контрольну суму і т.п.). Скоротивши на зверненнях клієнт-сервер, ви зніміть додаткове навантаження з сервера, тим самим – скоротіть мережевий трафік (хоча початкова сторінка, послана браузеру, швидше за все буде більшою), а також знизите навантаження з будь-яких інших кінцевих ресурсів, до яких звертається ваш північ (бази даних тощо). Крім того, користувачеві не треба буде чекати нову сторінку з повідомленням про помилку і пропозицією повернутися назад. Проте все це не означає, що вам треба просто перенести всю вашу перевірку з сервера на клієнта, немає. Ви повинні завжди робити перевірку даних, що вводяться на сервері, тому що вона допоможе захистити проти хакерів або браузерів, які не підтримують ваші клієнтські процедури перевірки.

Багато було зроблено для створення HTML, “незалежного від браузера”. Це часто перешкоджає розробнику при витяганні вигоди від популярних особливостей браузерів, які могли б приносити користь. Для високопродуктивних веб-сайтів, які турбуються про “досяжності” для браузерів, гарною стратегією буде оптимізація сторінок під найбільш популярні програми перегляду. Особливості браузера можуть бути легко виявлені в ASP використовуючи Browser Capabilities Component (“компонент можливостей браузера”). Інструментальні засоби типу Microsoft FrontPage можуть допомогти вам при проектуванні коду, який буде працювати з тими браузерами і версіями HTML, які ви хочете.


Рада 20: Уникайте конкатенації рядків у циклах


Безліч програмістів роблять освіта рядків у циклах наступним чином:

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 + “рядок”.


Рада 21: Використовуйте кешування сторінок в браузері і proxy-сервері

За замовчуванням в ASP відключене кешування у веб-браузері і proxy. Сенс цього полягає в тому, що ASP-сторінка – за своєю природою динамічна і звичайно містить інформацію, яка змінюється з часом. Якщо ваша сторінка містить постійні дані і не вимагає регенерації при кожному запиті, то ви повинні включити кешування для браузера та проксі. Це дозволить браузерам використовувати “кешируємой” копію сторінки протягом деякого відрізка часу, яким ви можете управляти. Кешування може значно знизити навантаження на вашому сервері.


Які з динамічних сторінок можуть бути кандидатами на кешування? Ось деякі приклади:



  • Сторінка з прогнозом погоди, де інформація оновлюється кожні 5 хвилин.

  • Головна сторінка сайту, яка містить список матеріалів на сервері або офіційні повідомлення для друку, які модифікуються два рази на день.

  • Інші подібні сторінки, де оновлення відбуваються раз на кілька годин.

Зауважте, що з кешуванням в браузері або кешуванням 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 може показувати сторінки користувачам з інформацією інших.


Рада 22: Використовуйте Server.Transfer замість Response.Redirect

Метод 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-файла негайно припиняється без очищення буфера висновку.


Рада 23: Використовуйте замикаючий слеш в URL каталогів


Ця рада відноситься не тільки до ASP-програмістам, але й до всіх веб-розробникам, хто у своїй роботі створює html-сторінки.

Перевірте, чи завжди ви використовуєте замикаючий слеш (trailing slash) – похилу риску вправо (/) в URL каталогів веб-сайту. Якщо опустити цей слеш браузер буде робити запит до сервера, тільки для того, щоб повідомити, що він питає про каталог. Потім браузер буде робити другий запит, але вже з слешем на кінці URL, і тільки тоді веб-сервер буде повертати “головний” (default) документ цього каталогу або видавати список файлів каталогу, якщо в ньому немає головного документа і дозволений перегляд каталогу. Додавання до URL замикаючого слеша дозволяє уникнути першого непотрібного запиту до веб-серверу, що, природно, економить час, який потрібний для переходу за посиланням. Щоб подібна посилання виглядала більш приємніше ви можете опустити слеш в назві URL.


Наприклад:

  http://www.relib.com/asp 

Ця рада також відноситься і до запису посилань на головну сторінку веб-сайту. Використовуйте

<a href=”http://www.relib.com/”>

а не

<a href=”http://www.relib.com”>

Рада 24: Уникайте використання серверних змінних

Виклик серверних змінних змушує ваш веб-сайт робити спеціальний запит до сервера і збирати всі серверні змінні, а не тільки ту, яку ви вимагали. Це схоже на ситуацію, коли вам потрібно знайти певний документ у папці, яка лежить на горищі. Коли вам потрібен один документ, ви повинні йти на горище, знайти спочатку всю папку, і тільки потім знайти потрібний документ. Це приблизно те ж саме, що станеться, коли ви запитуєте значення серверної змінної – запит до серверу стане причиною підвищення навантаження на сервер. Хоча подальші запити про інших серверних змінних уже не викличуть великого навантаження.

Також намагайтеся уникати невизначених викликів об’єкта Request (наприклад, Request (“Дані”)). Для елементів, що знаходяться не в Request.Cookies, Request.Form, Request.QueryString або Request.ClientCertificate, є неявний запит до Request.ServerVariables. Запит до колекції Request.ServerVariablesе виконується набагато повільніше, ніж доступ до інших колекціях.


Рада 25: Зробіть upgrade системного програмного забезпечення

Системні компоненти постійно оновлюються, тому рекомендується, щоб ви модернізували (зробили upgrade) до самої останньої версії. Найкраще встановити Windows 2000 (і отже, IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1 і JScript 5.1). IIS 5.0 і ADO 2.5 дозволяють досягти значного підвищення продуктивності ваших додатків на мультипроцесорних системах. На серверах під управлінням ОС Windows 2000 ASP може респределять навантаження одночасно на чотири процесори і більше, беручи до уваги, що в попередній версії – під IIS 4.0, ASP не робив такого розподілу і на два процесори. Наскільки багато ви використовуєте скриптової коду та ADO в ASP-сторінках вашого сайту, настільки більше підвищення продуктивності ви повинні побачити після модернізації до Windows 2000.

Якщо ви не можете встановити Windows 2000 зараз, ви можете модернізувати ваше системне програмне забезпечення до самих останніх версій SQL Server, ADO, VBScript і JScript, MSXML, Internet Explorer та пакету поновлення NT 4 (Service Pack). Кожне з перерахованого дозволяє поліпшити виконання роботи та збільшити надійність.


Висновок

Продуктивність – це особливість будь-якої програми, особливо, якщо мова йде про про інтернет або використанні баз даних. Якщо ваш розробляється веб-сайт щодо популярний і його аудиторія постійно зростає, то не прийнявши до уваги проблеми підвищення продуктивності ще в процесі проектування майбутнього програми, пізніше вам все одно доведеться переписувати вихідний код. Дані поради зачіпають тільки основні часто зустрічаються проблеми, які можна вирішити нескладним образом. Додаткову інформацію російською мовою про програмування з використанням технології Active Server Pages і розробці веб-сайтів ви можете знайти на сайті Relib.com (http://www.relib.com).

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*