Приветствую Вас Гость | RSS

Реальный заработок webmoney

Пт, 29 Марта 2024, 08:19

Практические аспекты построения коммерческих сайтов

Оптимизация и масштабирование сайта

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

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

ПРИМЕЧАНИЕ
В последнем разделе этой главы приведены ссылки на другие ресурсы по данной теме.

Системная архитектура

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

Аппаратная платформа

Первый критический фактор - оборудование, на котором работает сервер. На Web-серверах IIS обычно ограничен быстродействием процессора, а не объемом памяти или жесткого диска. Следовательно, установка дополнительных процессоров существенно влияет на производительность сервера.

В том, что касается надежности, система RAID 5 обеспечивает максимальную избыточность и способность восстановления информации при сбоях. Однако на сервере базы данных с большим объемом транзакций эта архитектура приводит к значительным затратам ресурсов, связанных с необходимостью записи данных на разные диски. RAID 1 ускоряет операции с базой данных, но вам придется предпринять дополнительные усилия по обеспечению надежного восстановления информации.

Распределение нагрузки

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

  1. Имеется четыре Web-сервера, работающих с одним сервером базы данных.
  2. Каждый Web-сервер может одновременно обслуживать до 500 пользователей.
  3. В соответствии с текущими правилами распределения нагрузки на каждом сервере одновременно работает до 450 пользователей. В общей сложности все серверы могут обслуживать до 1800 пользователей.
  4. Один из Web-серверов выходит из строя.

При потере одного Web-сервера на каждый из оставшихся серверов приходится 600 пользователей. Но, как говорилось выше, каждый сервер способен обслуживать только 500 пользователей. Это означает, что сайт либо вообще перестанет работать, либо будет работать крайне медленно.

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

Трехуровневая архитектура

Кроме непосредственного распределения нагрузки между серверами существуют и другие средства балансировки. В частности, вместо двухуровневой архитектуры (уровень Web-сервера и уровень базы данных) можно перейти к трехуровневой архитектуре.

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

Добавление третьего уровня обеспечивает ряд принципиальных преимуществ в области масштабируемости сайта. Эти преимущества перечислены в табл. 18.1.

Таблица 18.1. Преимущества трехуровневой архитектуры
Преимущество
Описание
Сегментация Перемещением части кода на вторичные серверы мы сегментируем большую часть логики и увеличиваем количество контрольных точек
Распределение процессорной нагрузки Интерфейсные Web-серверы в этой модели в основном занимаются предоставлением статического содержания, обращениями к объектам второго уровня и получением ответов
Избыточность Во втором уровне архитектуры можно реализовать дополнительные средства архивации, повышающие надежность системы
Абстрагирование базы данных Отделение баз данных от интерфейсных Web-серверов упрощает проблему масштабирования. Если один из серверов баз данных становится недоступным, объекты второго уровня должны знать, как действовать дальше. При этом Web-серверы продолжают нормальную обработку запросов пользователей
Компиляция кода Перемещение кода из сценарной, интерпретируемой среды в компилируемую обеспечивает существенное повышение быстродействия
Оптимизация серверов Разделение баз данных, Web-серверов и бизнес-логики позволяет оптимизировать каждый сервер и обеспечить наилучшее быстродействие при выполнении конкретного круга задач. Кроме того, сокращение функциональности серверов приводит к уменьшению непроизводительных затрат

Не стоит заблуждаться - добавление нового уровня потребует дополнительной работы и дополнительного планирования. Создание надежного компилируемого кода прибавит работы программистам. Проработка связей между уровнями также означает дополнительное архитектурное планирование. Кроме того, усложняются среды разработки и публикации программного кода. Наконец, хотя появление нового уровня открывает новые возможности для оптимизации, оценка нагрузок и процесс принятия решений также становятся более сложными.

Другие факторы

При оценке масштабируемости и надежности комплекса серверов необходимо принимать во внимание и другие факторы.

Для экономии памяти в NT проследите за тем, чтобы присутствовали только действительно необходимые службы. Если вы не пользуетесь некоторыми службами (особенно при полной установке Site Server) - например, Personalization & Membership - обязательно отключите их.

На производительность и надежность сайта влияют и другие факторы (например, сетевая архитектура, программное обеспечение архивации и т. д.) Например, в некоторых ситуациях наличие отдельного сетевого адаптера для каждого процессора на сервере заметно влияет на быстродействие системы и степень использования процессора.

Оптимизация серверов баз данных

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

В таких средах часто используется Ad Server, и на каждой странице Web-сайта может присутствовать несколько реклам. И, конечно, коммерческие сайты интенсивно работают с базами данных для отслеживания покупателей, загрузки информации о товарах и т. д.

Настройка и использование SQL Server

На сайтах с интенсивным использованием баз данных очень важную роль играет настройка SQL Server. Правильный выбор количества пользовательских подключений, открытых подключений, открытых баз данных и других параметров заметно влияет на работу SQL Server. Дополнительная информация о правильном выборе значений параметров и их настройке приведена в Microsoft TechNet и Microsoft Developer Network (MSDN).

Второе правило, которое также следует соблюдать, - применение хранимых процедур (как на страницах этой книги). Хранимые процедуры представляют собой откомпилированный программный код, очень быстро выполняемый на Web-серверах. Кроме того, если в команде SELECT можно указать конкретные столбцы вместо обозначения *, соответствующего всем столбцам, такой запрос также будет выполняться быстрее.

Разумное использование Microsoft Transaction Server (и Com+ Application Services в Windows 2000) позволит вам извлечь максимум пользы из драгоценных ресурсов баз данных. MTS/COM+ обеспечивает распределение нагрузки между компонентами, находящимися на разных серверах, при этом компонентные службы в любой момент времени будут работать на наименее загруженном сервере.

Наконец, подключения к базе данных могут быть общими ресурсами, что позволяет нескольким программным потокам (threads) приложения работать с базой, при этом каждому потоку не придется физически открывать и закрывать подключение к базе данных.

Избыточность и надежность

Еще одно ключевое правило, используемое при построении сайта, - возможность восстановления при сбоях на серверах баз данных. Если содержимое базы по какой-либо причине становится недоступным (в том числе и из-за планового обслуживания), работоспособность Web-сайта должна сохраниться.

Как упоминалось в главе 4, при использовании таких методов, как репликация, можно организовать теплую архивацию. Второй возможный вариант - использование общей файловой системы на двух группах серверов. Один экземпляр представляет собой резервную копию, создаваемую в реальном времени на случай отказа второго экземпляра. Существуют технологии, обеспечивающие двойную актуализацию данных при всех записывающих транзакциях в пределах одного серверного комплекса и даже на разных серверах, относящихся к разным комплексам.

В примере, созданном в этой книге, использовано регистрационное имя sa без пароля. Конечно, в реальной системе так поступать не следует. Вместо этого следует выбрать регистрационное имя и пароль и ограничить права учетной записи, запретив для нее общее администрирование SQL Server. В идеальном случае пароль должен регулярно изменяться.

Структура базы данных

Существуют различные решения, направленные на ускорение работы базы данных. В простейшем случае для ускорения обработки запросов в базах данных с интенсивным чтением можно воспользоваться индексами.

Даже с применением всех способов, описанных в этой главе, на сайтах с высокой нагрузкой в конечном счете может возникнуть ситуация, когда один сервер SQL, ориентированный на выполнение конкретной функции (например, обслуживание электронного магазина), не сможет обеспечить независимую обработку всех транзакций. В этом случае приходится искать возможность разбиения функций по нескольким серверам.

В электронном магазине первым шагом может быть отделение базы данных товаров от баз корзины и заказа. В результате первый сервер будет специализироваться на чтении, а второй - на записи. Таким образом мы успешно распределяем транзакции по двум серверам.

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

Правила оптимизации

Настройка и оптимизация IIS больше напоминают искусство, нежели ремесло. Дело даже не в многочисленности регулируемых параметров - просто их настройка зависит от большого количества факторов.

В процессе настройки IIS участвуют два ключевых параметра: максимальное количество запросов в очереди и программных потоков. Количество программных потоков в процессе Internet Information Server определяется динамически. Как правило, динамические значения являются оптимальными. В крайних случаях, при слишком активном использовании процессора или наоборот, при его недоиспользовании стоит отрегулировать максимальное количество потоков в процессе Inetinfo. Если вы изменили максимальное количество потоков, тщательно протестируйте систему и убедитесь в том, что изменения привели к повышению производительности. Обычно изменения оказываются весьма незначительными.

Настройка количества потоков IIS связана с эффективностью использования компьютера. Увеличение числа потоков обычно увеличивает интенсивность использования процессора; при малом количестве потоков процессор используется в меньшей степени. Например, если длина очереди необработанных запросов на вашем сайте практически не растет, а степень загрузки процессора невелика, вероятно, вычислительные возможности вашего сайта превышают необходимый уровень. С другой стороны, если длина очереди увеличивается или уменьшается, а степень использования процессора остается небольшой, количество потоков стоит увеличить, поскольку у вас имеются неиспользуемые ресурсы процессора.

Настройка очереди IIS тоже играет важную роль, поскольку для загруженных Web-сайтов характерен большой объем транзакций. В идеальном случае жизненный цикл транзакций очень мал, но при высокой нагрузке могут возникать значительные замедления (блокировка), связанные с тем, что частота обращения к компоненту превышает его возможности по обработке транзакций. В этом случае входящие запросы ставятся в очередь для последующей обработки по принципу FIFO (First In - First Out, то есть "первым пришел - первым ушел"). Если блокировка продолжается лишь несколько секунд, очередь вскоре исчезает, и поступающие запросы обслуживаются своевременно. Но если блокировка длится в течение более долгого периода, может возникнуть эффект переполнения очереди (queue saturation). Переполнение очереди происходит в том случае, когда количество находящихся в очереди запросов превышает максимально допустимое количество (RequestQueueMax), и IIS возвращает сообщение "Server Too Busy".

В любом случае возможности Web-сервера в отношении максимального количества потоков и запросов в очереди ограничены. Внимательно наблюдая за эффектом от изменения этих параметров, вы сможете добиться от сервера максимальной производительности.

Другой возможный вариант - сократить ведение журналов (logging) на Web-сервере до абсолютного минимума (или полностью отключить его). В этом случае вам удается избавиться от затрат по регистрации запросов на транзакции, но это отрицательно скажется на объеме накапливаемой Web-статистики.

Обычно при использовании IIS можно улучшить быстродействие и сократить загрузку процессора, заменив динамические Web-страницы статическими и устранив большие растровые изображения. За дополнительной информацией по этой теме и конкретными рекомендациями обращайтесь к документации IIS от Microsoft.

Программирование

И все же программист во многих отношениях оказывает наибольшее влияние на работу Web-сайта и располагает самыми широкими возможностями для улучшения производительности и масштабируемости (см. табл. 18.2).

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

Таблица 18.2. Приемы оптимизации программного кода
Прием
Описание
Кэширование Кэширование постоянно используемых данных позволяет избежать частых операций чтения или записи в базу данных и улучшает быстродействие. Кроме того, кэширование в сочетании с отсоединенными наборами записей может использоваться для управления базами данных на Web-серверах или серверах бизнес-объектов. Подобная методика обычно применяется для данных, ориентированных на чтение (например, база данных товаров в электронном магазине) или на запись (например, щелчки по рекламным баннерам)
Подключение к базе данных В программном коде этой книги большинство подключений к базе данных открывалось непосредственно перед использованием данных. Подключения к базам данных должны оставаться открытыми в течение как можно меньшего времени. На сайтах с высоким уровнем трафика рекомендуется немедленно закрывать соединение после обработки запроса
Обработка ошибок Даже при самой совершенной архитектуре системы и при самом тщательном программировании ошибки все же случаются. Хорошо организованная обработка ошибок при восстановлении от пиковых нагрузок, временной недоступности базы данных и т. д. избавляет пользователя от уродливых сообщений об ошибках и выводит более удобную информацию
Сеансовые переменные Поручая серверу управлять сеансовыми данными каждого пользователя Web-сайта, вы тем самым взваливаете на него дополнительную нагрузку. Сеансовые переменные можно заменить параметрами URL, но это потребует значительной работы и отслеживания дополнительной информации
Option Explicit Используя объявления Option Explicit в начале каждого модуля или класса вашей программы, вы облегчаете нахождение неиспользуемых переменных, которые могут быть удалены из программы
Переменные уровня приложения Стандартные данные, к которым обращаются все пользователи, гораздо эффективнее хранить в переменной уровня приложения, чем во множестве сеансовых переменных
Компиляция кода Как упоминалось при обсуждении трехуровневой архитектуры, перемещение сценарного кода в откомпилированный код Visual Basic или Visual C++ существенно улучшает быстродействие программы. Кроме того, использование конвейеров и коммерческих объектов Site Server обеспечивает распределение программного кода
Хранимые процедуры Всегда используйте хранимые процедуры для хранения кода SQL в откомпилированном виде на серверах баз данных
Статические страницы По возможности делайте ваши страницы статическими. Если потребуется передать данные между страницами, воспользуйтесь передачей параметров в URL
Группировка кода Старайтесь размещать как можно больший объем кода ASP в одном блоке. Это сократит количество переключений контекста между HTML и сценарным кодом
Тег OBJECT Вместо Server.CreateObject применяйте тег <OBJECT>. При вызове Server.CreateObject объект создается немедленно, а при использовании тега <OBJECT> - только при необходимости
Локальные и глобальные переменные Там, где возможно, используйте локальные переменные. Обычно локальные переменные создаются в процедурах и функциях, но также могут создаваться командой Set

Конечно, хороший стиль программирования также улучшит работу вашего приложения. В мире Интернета и загруженных сайтов помогает каждая мелочь.

Дополнительные ресурсы

В World Wide Web существует много ресурсов, посвященных настройке комплексов Web-серверов. В табл. 18.4 приведены ссылки на различные ресурсы, к которым вы можете обратиться за дополнительной информацией и поддержкой.

Таблица 18.4. Дополнительные ресурсы
Название
Ссылка
TechNet http://www.microsoft.com/technet/
MSDN http://msdn.microsoft.com/default.asp
ASP Conventions http://msdn.rnicrosoft.com/workshop/server/asp/aspconv.asp

IIS 4.0 Tuning

http://msdn.microsoft.com/workshop/server/feature/tune.asp

Создание Web-сайта с высокой степенью доступности

http://technet.microsoft.com/cdonline/default-f.asp?target= http://technet.microsoft.com/cdonline/content/complete/ windows/winnt/winntas/technote/crhasite.htm

15 рекомендаций по программированию ASP

http://www.microsoft.com/workshop/server/asp/asptips.asp

VCRocket

http://www.microsoft.com/siteserver/commerce/DeployAdmin/ VolcanoCoffee.htm

Site Server

http://www.microsoft.com/siteserver

Быстродействие Commerce Server

http://www.microsoft.com/siteserver/commerce/DeployAdmin/ VolcanoCoffee.htm

SQL Server

http://www.microsoft.com/sql/

IIS http://www.microsoft.com/ntserver/web/default.asp
Windows NT 4 http://www.microsoft.com/ntserver/nts/default.asp
Windows 2000 http://www.microsoft.com/windows/server/default.asp

Руководство по установке Site Server (Windows NT)

http://support.microsoft.com/support/siteserver/install_ss3.asp

Руководство по установке Site Server (Windows 2000)

http://support.microsoft.com/support/kb/articles/q241/8/33.asp

Компания Microsoft неплохо потрудилась над оптимизацией своих сайтов в домене com. В приведенной документации вы найдете приблизительные параметры быстродействия, а также рекомендации по настройке.

Итоги

Оптимизация комплекса Web-серверов является очень важной задачей. Вы должны тщательно спланировать, изучить и внимательно настроить каждый элемент проектируемой системы. Кроме того, очень важно организовать тщательное отслеживание ресурсов серверов и баз данных при пиковой нагрузке.