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”
TYPE=”TypeLib” UUID=”{00000205-0000-0010-8000-00AA006D2EA4}” –>або
<!– METADATA TYPE=”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>

*

*