Реальний заробіток webmoney - електронна комерція - комерційний сайт

Практичні аспекти побудови комерційних сайтів

Оптимізація і масштабування сайту

На сторінках цієї книги ми створили численні приклади коду, що демонструють процес побудови електронного магазину, а також розглянули один із прикладів, що входять в поставку Site Server. Однак у такій динамічному середовищі, як Інтернет, можливі непередбачені піки трафіку, що призводять до перевантаження сайту, тому при побудові сайту дуже важливо дотримуватися деяких правил з області масштабованості і швидкодії.

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

ПРИМІТКА
В останньому розділі цієї глави наведені посилання на інші ресурси по даній темі.

У розділі 4 були розглянуті основні принципи планування системної архітектури. По відношенню до оптимізації і масштабованості сайту слід враховувати кілька ключових факторів.

Перший критичний чинник - обладнання, на якому працює сервер. На Web-серверах IIS зазвичай обмежений швидкодією процесора, а не об'ємом пам'яті або жорсткого диска. Отже, установка додаткових процесорів істотно впливає на продуктивність сервера.

У тому, що стосується надійності, система RAID 5 забезпечує максимальну надмірність і здатність відновлення інформації при збоях. Однак на сервері бази даних з великим об'ємом транзакцій ця архітектура призводить до значних витрат ресурсів, пов'язаних з необхідністю запису даних на різні диски. RAID 1 прискорює операції з базою даних, але вам доведеться докласти додаткових зусиль щодо забезпечення надійного відновлення інформації.

Крім того, як згадувалося в розділі 4, розподіл навантаження по декількох серверах також може зіграти вирішальну роль. Якщо обсяг трафіку перевищує можливості одного Web-сервера, навантаження доводиться розподіляти по декількох серверах. При проектуванні комплексу серверів з розподілом навантаження необхідно враховувати кілька критичних чинників. Розглянемо наступний сценарій:

Є чотири Web-сервера, що працюють з одним сервером бази даних.
Кожен Web-сервер може одночасно обслуговувати до 500 користувачів.
У відповідності з поточними правилами розподілу навантаження на кожному сервері одночасно працює до 450 користувачів. В цілому всі сервери можуть обслуговувати до 1800 користувачів.
Один з Web-серверів виходить з ладу.

При втраті одного Web-сервера на кожен з решти серверів доводиться 600 користувачів. Але, як говорилося вище, кожен сервер здатний обслуговувати тільки 500 користувачів. Це означає, що сайт або взагалі перестане працювати, або буде працювати вкрай повільно.

Формально комплекс з N (4) серверів справлявся з піковим навантаженням. Але в плані слід передбачити N + X серверів, де X додаткових серверів забезпечували б безперебійну роботу сайту в разі порушення роботи частини основних серверів.

Крім безпосереднього розподілу навантаження між серверами існують і інші засоби балансування. Зокрема, замість дворівневої архітектури (рівень Web-сервера і рівень бази даних) можна перейти до трирівневої архітектурі.

На третьому рівні виконується код, пов'язаний з бізнес-логікою. Маленький приклад виділення бізнес-логіки в окремий рівень зустрічається і в нашому магазині при обчисленні податку і вартості доставки. Однак насправді будь-яка функціональна частина додатка ASP може виконуватися на іншому сервері. На рис. 18.1 зображена структурна діаграма сайту з додаванням третього рівня.

Додавання третього рівня забезпечує ряд принципових переваг в області масштабованості сайту. Ці переваги перераховані в табл. 18.1.

Таблиця 18.1. Переваги трирівневої архітектури