Эта книга для веб-мастеров, системных администраторов, системных архитекторов, системных интеграторов, программистов веб-приложений, редакторов сайтов. Она поможет повысить производительность веб-сервера, оценить требования проектируемого сайта к оборудованию и программному обеспечению, а также расскажет о вопросах масштабирования сайтов. Производительность рассматривается с точки зрения обычного пользователя — насколько быстро веб-сервер может удовлетворить его запрос. Нередко внимание системного администратора концентрируется на веб-сервере, хотя узким местом может быть не сам сервер, а низкоскоростное подключение клиента к сети, динамическое формирование веб-страницы или производительность базы данных. Лучший путь к повышению производительности веб-системы лежит через хорошее понимание его архитектуры и порядка работы каждого из его элементов. В книге рассматриваются приложения, работающие под управлением как операционной системы Unix, так и Windows. Предполагается наличие у читателя общего знакомства с техническими аспектами работы веб-сайтов.
Содержание
Предисловие
Для чего нужна эта книга?
Для кого предназначена эта книга?
Сделанные предположения
Как устроена эта книга
Шрифты
Как с нами связаться
Другие книги и ресурсы
Книги
Веб-сайты, посвященные производительности
Группы новостей, имеющие отношение к производительности веб
Ограничение гарантий
Благодарности ко второму изданию
Часть I. Предварительные сведения
Глава 1. Быстрый и мертвый
Проверка браузера
Проверка сервера
Основные рекомендации
Глава 2. Архитектура веб-сайта
Компромиссы
Сохранение информации и масштабируемость
Дублирование и простота
Синхронность и асинхронность
Связь без логического соединения
Планирование и разработка
Процедурное и объектно-ориентированное программирование
Основы
Браузер
Система балансировки нагрузки
Веб-сервер
Связующие программы
База данных
Пример архитектуры веб-сайта
Один компьютер
Стековая архитектура
Уровни
Linux на мейнфрейме
Реальный масштаб времени
Тенденции
Программы, используемые на широко известных сайтах
Примеры конфигураций
Низкая нагрузка
Средняя нагрузка
Большая нагрузка
Какие сайты являются наиболее загруженными?
Основные рекомендации
Глава 3. Планирование мощностей
Займитесь подсчетами…
…но верьте своим глазам больше, чем цифрам
Вопросы, которые нужно себе задавать
Какая вам нужна пропускная способность?
Время ожидания важнее пропускной способности
О пропускной способности
Оценка пропускной способности сети веб-сервера
Насколько быстрый сервер вам нужен?
Сколько памяти нужно серверу?
Память для операционной системы
Память для httpd
Память для содержимого
Память для CGI
Основные рекомендации
Глава 4. Контроль производительности
Параметры производительности
Время ожидания и пропускная способность
Время ожидания для сети
Измерение времени ожидания и пропускной способности сети
Коэффициент использования
Эффективность
Использование сценариев интерпретатора
Использование С
Использование Perl
Контроль производительности сети с помощью Perl
Отображение результатов с помощью gnuplot
Пример сценария на Perl
Компоненты
Автоматическая генерация сценариев для контроля с помощью sprocket
Использование реляционной базы данных для сохранения данных о производительности
Помещение данных в базу
Получение данных из базы
Контроль коэффициента использования с помощью rstat
Сохранение данных rstat в реляционной БД
Использование данных rstat
Получение данных из БД в стандартный поток вывода
Построение графиков данных, хранящихся в БД
Контроль статистики процессов
Использование CGI для запуска программных средств
Включение подробного анализа с помощью rstat
Работа с Telnet в языке Perl
Генерация графиков из результатов работы ps
Контроль прочих параметров
Контроль с помощью Java
Приборная панель на веб-странице
Внимание! Избыток контроля вреден для здоровья вашего сайта!
SNMP
RMON
ARM
Прочие ресурсы
Основные рекомендации
Глава 5. Тестирование на нагрузку
Подготовка к тестированию
Опасайтесь переустановки часов
Почему реальная производительность отличается от тестовой?
Средства тестирования нагрузки
Написание собственных тестовых программ
Проблемы с таймером
Тестирование на нагрузку при избыточном контроле
Синхронизация теста на нагрузку
Хаотическое тестирование на нагрузку
Как остановить тестирование?
Создание нагрузки на сеть
Спецификации и эталонные тесты
WebStone
SPECweb99
TPC-C и TPC-D
Тесты прокси-серверов
Тесты производителей
CaffeineMark
Прочие ресурсы
Основные рекомендации
Глава 6. Анализ производительности
Поиск "узких мест" с помощью analysis.cgi
Подслушивание HTTP с помощью sprocket
Изучение соединений
Анализ файлов журналов
Средний объем передачи
Распределение размеров файлов
Хиты в секунду
Переменная нагрузка и длина очереди
Когда конкретно записываются хиты?
Кто ваш самый частый пользователь?
Который из процессов мой?
Кто работает с этим файлом?
Какие файлы используются моими процессами?
Что происходит при зависании БД?
Еще немного советов
Основные рекомендации
Глава 7. Надежность
Типичные отказы
Переполнение диска
У процесса закончились файловые дескрипторы
Ошибки при работе с указателями на С
Утечки памяти
Блокировка потоков
Блокировка ресурса завершившимся процессом
Перегрузка сервера
Система балансировки нагрузки не может обнаружить отказавший компьютер
Перегружена подсеть
Израсходованы терминалы
В базе данных закончились указатели
Плохой драйвер устройства
Отказы оборудования
Отказ питания
Администратор перепутал сервер
Ошибочное включение файла в шаблон
Проблемы с разрешениями
Ошибки в путях
Проблемы с заплатами
Каскадное распространение перегрузки
Отказы из-за контроля
Повторные обращения вызывают новые отказы
Случайная блокировка важных таблиц
Использование БД там, где можно обойтись файлами
Программа не может подключиться к БД после отказа
Программа не перезапускается после перезагрузки
"Раздвоение личности"
Брандмауэр блокирует важную службу
Чтение данных с экрана не работает из-за того, что меняется дизайн
Зависимости
Борьба с последствиями отказа
Основные рекомендации
Глава 8. Безопасность
HTTPS и SSL
Брандмауэры
Узлы-бастионы
Chroot
Основная рекомендация
Глава 9. Разбор ситуаций
Неограниченный рост таблицы
Обратный поиск в DNS замедляет работу с журналом
Перекрученный кабель
Рост пула базы данных ограничивает производительность
Основная рекомендация
Глава 10. Принципы и схемы
Принципы повышения производительности
Иногда приходится проигрывать
Измерение меняет объект
Знания важнее всего
"Бесплатных обедов" не бывает
Доходы сокращаются
Переносимость уменьшает производительность
Абстрагирование уменьшает производительность
Защищенность уменьшает производительность
Память имеет иерархическую структуру
Кэширование зависит от локальности ссылок
Операции ввода-вывода всегда медленны
Информация относительна
Оборудование дешево, программы дороги
Целью оптимизации является одновременность выхода из строя компонентов
Хорошее относительно
Биты - это деньги
Производительность Интернета падает нелинейно
Глобальная оптимизация дает наилучшие результаты
Что произошло однажды, скоро произойдет снова
Правило 80/20
Люди часто важнее знаний
Схемы улучшения производительности
Амортизация
Кэширование
Профилирование
Параллельная обработка
Используйте то, что знаете
Простота
Основные рекомендации
Часть II. Подробно об оптимизации
Глава 11. Браузеры
Как работают браузеры
Виды браузеров
Netscape
Internet Explorer
Opera
Neoplanet
WebTV
Cello
Mosaic
lynx
Amaya
Tango
Идеальный браузер
Скорость браузера
Советы по настройке браузеров
Общие рекомендации
Советы для Internet Explorer
Советы для Netscape
Прочие веб-клиенты
Gnutella и одноранговые сети
Основные рекомендации
Глава 12. Операционная система клиента
Microsoft Windows
Устраните беспорядок в системе
Специальные драйверы экрана
Память и диски
Системный монитор
Сетевые утилиты
MTU
Macintosh
Эмуляция 68К
Сеть
Память и диск
Расширения
Unix
Основные рекомендации
Глава 13. Аппаратное обеспечение клиента
Процессор
ОЗУ
Кэш
Шина
Диск
IDE
SCSI
Фрагментация
Видео
MMX
Цвета и разрешение
Драйверы
3D и видеоклипы
Тесты для видеоадаптеров
Ввод-вывод
UART
Аппаратное сжатие может приводить к переполнениям
BIOS
Основные рекомендации
Глава 14. Линии связи и оконечные устройства
Пересылка и время ожидания
Модем - выезд на информационную магистраль
Время ожидания и пропускная способность от модема к модему
Синхронизация
Аппаратное сжатие
Коррекция ошибок
Качество линии
Внутренние модемы быстрее
Переполнение буферов UART
Команды AT и время набора номера
Объединение каналов
ISDN
Кабельные модемы
xDSL
Еще более скоростные линии
56K, T1 и T3
Frame Relay
АТМ
Спутники
Интрасети
Сегментирование
Оборудование для сегментирования
Ethernet
Перехват пакетов
Буферы сетевых адаптеров
Быстрый Ethernet
Коммутируемый Ethernet
Кабели Ethernet
Шум
Средства моделирования сетей
Интернет
В обход Интернета
Точки доступа к сети
Провайдеры
Выбор провайдера
Дублирование
Маршрутизаторы
Кто виноват?
Будущее Интернета
ПTT
Основные рекомендации
Глава 15. Сетевые протоколы
Власть и протоколы
Факторы, влияющие на производительность сетевых протоколов
Пакеты, кадры и ячейки переменного и фиксированного размеров
Совмещенная отправка
Конвейер и подтверждение отдельных пакетов
Односторонние и двусторонние протоколы
Ошибки
Количество прыжков
Уровни
Протоколы веб
ARP
PPP
Протоколы маршрутизации
Протокол Интернета
TCP
T/TCP
UDP
HTTP
FTP
NNTP
CORBA
X
Основные рекомендации
Глава 16. Аппаратное обеспечение сервера
Коробка с проводом
Хорошая подсистема ввода-вывода
Несколько шин
Быстрые диски
Много памяти
Масштабируемость
Сетевой адаптер
Шина
Оперативная память
Характеристики ОЗУ
Процессор
Архитектура процессора
Многопроцессорные компьютеры
Тестирование масштабируемости Sun SMP
Жесткий диск
Архитектура и параметры дисков
IDE
EIDE
SCSI
Fibre Channel
RAID
Производительность типичных дисков
Фрагментация
Активность дисков и идентификаторы процессов
Основные рекомендации
Глава 17. Операционная система сервера
Unix и рождение Сети
Версии Unix
Solaris
AIX
Digital Unix
Linux
Irix
BSD
Mach OS
Устройство Unix
Системные и библиотечные вызовы
Процессы и ядро
Планирование
Контекст ядра
Unix и httpd
Уменьшение нагрузки на операционную систему
Создание процессов
Адресное пространство
Копирование областей памяти
Освобождение памяти
Файловая система
Оконный интерфейс
Версии и заплаты
Настраиваемые параметры операционных систем
Количество дескрипторов файлов
Частота очистки буферов файловой системы
Средства контроля Unix
ps
perfbar
perfmeter
perfmon
rstat
rup
hstat
top
xload
Трассировщики системных вызовов
Программы прослушивания сети
netstat
vmstat
sar
Сколько соединений может обслужить мой веб-сервер?
Сколько процессов может одновременно выполняться на моем сервере?
Насколько быстро может мой сервер породить новый процесс?
Unix и Windows NT в качестве ОС для веб-серверов
Достоинства и недостатки NT
Достоинства и недостатки Unix
Проект Exokernel
Основные рекомендации
Глава 18. Программное обеспечение сервера
Эволюция веб-серверов
Серверы, порождавшиеся демоном inetd
Серверы, порождающие процессы
Многопоточные серверы
Серверы с постоянными соединениями
Системные вызовы веб-сервера
Как происходит сбой сервера
Утечки памяти
Настройка Apache и Netscape
Короткие пути
Не преобразуйте время
Буферизуйте запись в журнал
Настройка Apache
Настройка Netscape
Прочие серверы
Недостающие функции
Прокси-серверы
Иерархическое кэширование
Основные рекомендации
Глава 19. Содержимое
Важен размер
Лучше не бывает
Кэширование и отличия
HTML и сжатие
gzip
Советы HTML-разработчикам
Полегче на сервере!
Полегче в сети!
Полегче с браузером!
Полегче с пользователем
Берегитесь предвзятых HTML-редакторов
Идите в ногу с миром
Используйте средства проверки HTML
Объектная модель документа
Графика
Анимация
VRML
Аудио
Видео
Основные рекомендации
Глава 20. Специализированные приложения
Программисты
CGI-программы
Внутреннее устройство CGI и вопросы производительности
Основные рекомендации
Бесконечные циклы
Неудержимо растущие CGI-программы
Защита от зацикливания CGI-программ
Не заставляйте клиента ждать
Переложите обработку на браузер
Файлы cookie
Java
Обрабатывайте запросы заранее и кэшируйте результаты
Короткая - значит красивая
Вопросы масштабирования
Разделяйте большие формы на несколько маленьких
Поиск в DNS на сервере
Отладка и оптимизация
Оптимизация CGI
Сценарии интерпретатора
Perl
C
Демонизация
Производительность при обращении к БД
Ведение журналов
NSAPI и ISAPI
Объектная модель документа
JSP, ASP, PHP
Основные рекомендации
Глава 21. Java
Язык Java никогда не будет достаточно быстрым для пользовательских интерфейсов
Java достаточно быстр для серверных приложений
Внутренние проблемы с производительностью, присущие Java
Проверка границ массивов
Блокирующий сетевой ввод-вывод
Интерпретация байт-кода
Верификация байт-кода
Динамическая привязка методов
Сбор мусора
Косвенная адресация
Интернационализация и локализация
Объектная ориентированность
Стековая ориентация
Синхронизация
Многопоточное программирование
Советы программистам
Используйте хорошие алгоритмы
Делайте цепочки наследования короткими
Используйте стековые переменные
Объединяйте классы
Используйте библиотеки Java
Не опрашивайте
"Финализируйте" методы
Создавайте поменьше объектов
Опасайтесь утечек объектов
Попробуйте не пользоваться методами для работы с переменными
Используйте сложные операторы
Используйте шаг типа int
Следите за скоростью доступа к различным переменным
Локальные переменные быстрее, чем переменные класса
Переменные класса быстрее, чем массивы
Используйте собственные методы
Используйте тайм-ауты сетевой подсистемы
Буферизуйте ввод-вывод
Используйте сокеты вместо URL
Используйте UDP
Используйте потоки
Используйте notify
Используйте синхронизацию как можно реже
Не помещайте синхронизируемые методы внутрь циклов
Следите за родительским потоком
Обратный отсчет бывает быстрее прямого
Уменьшайте количество строк
Используйте строчные буферы или массивы
Берегитесь медленных шрифтов
Упрощайте метод Paint
Двойная буферизация обеспечит плавность анимации
Пусть система отлавливает ошибки за вас
Не преобразуйте даты и время
Берегитесь RMI, EJB и CORBA
Компиляторы
Оптимизация
Профилируйте свой код
JVMPI
Декомпиляторы
Средства профилирования на уровне операционной системы
JIT-компиляторы
Статические компиляторы
Виртуальные машины
Параметры времени выполнения
-verbosegc
-noverify
-Xmsn и -Xmxn
Сделайте Рай побольше
-train
Используйте собственные потоки
Используйте архивы .jar
Подключаемый модуль Java
-start_ java
Java-процессоры
Тесты для Java
Недостатки тестов
Веб-сайты, где размещены сведения о производительности Java
Основные рекомендации
Глава 22. Базы данных
Нужна ли вам реляционная база даных?
Как узнать, что вам нужна база данных?
Альтернативы
Повышение производительности
Подготовленные операторы и связанные переменные
Денормализуйте таблицы
Не создавайте курсоры в циклах
Прямые соединения
Базы данных в основной памяти
Многоярусные системы
Конфигурация пула соединений
Запросы
Индексы
Блокировка на уровне строк
Объединение веб-сервера и базы данных
Сколько соединений может обслужить ваша база данных?
Когда база данных перегружена
Анализ
Основные рекомендации
Приложение. Обзор продуктов, предназначенных для оптимизации веб-сайта
Недостатки коммерческих средств
Средства контроля
Средства создания нагрузки
Упреждающие загрузчики
Оптимизаторы сетей
Оптимизаторы МТU
Optimal Application Expert
Контроль трафика на уровне IP
Системы сжатия содержимого
Гибриды средств разработки и баз данных
Профилировщики и оптимизаторы Java
Службы кэширования
Профессиональные услуги
Средства балансировки нагрузки
Средства моделирования
Алфавитный указатель
ОТРЫВОК
Архитектура веб-сайта
Разработчикам веб-сайтов часто приходится идти на компромиссы. Им нужно подбирать оптимальную конфигурацию и выбирать нужные компоненты из множества существующих. Все зависит от того, к чему вы стремитесь, - нет решения, которое подошло бы всем. В этой главе мы рассматриваем фундаментальные проблемы, с которыми может столкнуться любой.
Компромиссы
В процессе разработки архитектуры сайта часто возникает необходимость жертвовать одним ради другого, выбирать между сохранением информации о пользователях и масштабируемостью, между дублированием и простотой, между синхронностью и асинхронностью, между соединениями и их отсутствием, между скоростью разработки и тщательным планированием и, наконец, между процедурным и объектно-ориентированным программированием.
Сохранение информации и масштабируемость масштабируемость веб-сервер;информация о состояниивеб-сервер;масштабируемостьСам по себе веб-сайт неспособен сохранять информацию об индивидуальных пользователях в промежутках между веб-транзакциями. Пользователи таких сайтов не могут хранить на них никакой информации о себе. Сайт ничего не "помнит" о ваших предыдущих посещениях. Он отправляет вам запрошенную страницу независимо от того, запрашивали ли вы ее раньше, и независимо от того, с какой страницы вы на нее попали.
У таких веб-сайтов не бывает проблем с масштабируемостью. Сайты без сохранения состояния могут легко дублироватьсявеб-сайт;дублирование, что вместе с распределением нагрузки обеспечивает масштабирование даже в случае работы с динамическим содержимым (если, конечно, это содержимое допускает дублирование). Примером может являться сайт, на котором размещается информация о котировках акций или прогноз погоды. Поскольку функциональность всех веб-серверов одинакова, пользователь может без всяких проблем получить заглавную страницу сайта с одного сервера, затем щелкнуть ссылку на этой странице и получить другую страницу с другого сервера.
Совсем иначе обстоят дела на сервере транзакциймасштабируемость;транзакционных серверов, где необходимо сохранение информации о состоянии пользователей, например о входе и выходе из системы, о содержимом покупательской корзины или пользовательского счета. Необходимость сохранения информации о состоянии пользователей является источником большей части проблем с производительностью на сайтах с поддержкой транзакций, ограничивает масштабируемость скоростью получения и обновления информации о пользователях, заставляет серверы постоянно обмениваться этой информацией. Система записей представляет собой базу данных, в которую записываются транзакции, и неизбежно является узким местом. Существует несколько способов уклониться от конфликта между необходимостью сохранения информации о пользователях и необходимостью масштабирования сайтамасштабируемость;рекомендации.
Храните сведения о состоянии в явном и компактном виде, например в одном файле cookie, чтобы состояние транзакции помещалось в один пакет.
Не разделяйте сведений о состоянии между браузером, промежуточным сервером и базой данных, чтобы небольшие ошибки не приводили к огромному беспорядку.
Обеспечьте атомарность операции записи состояния в систему записей и проверку успешности выполнения этой операции.
Уменьшение объема сведений о состоянии также весьма благоприятно влияет на производительность, поскольку меньший объем данных приходится записывать в базу данных или считывать из нее. Если вы планируете масштабирование сайта с поддержкой транзакций путем дублирования данных о состоянии между серверами, малый объем этих данных облегчит их дублирование.
синхронизацияРаспределение обработки данных о состоянии между несколькими процессорами потребует интенсивного обмена данными для синхронизации - как в случае с несколькими машинами в кластере, так и в случае с одной многопроцессорной машиной. В первом случае это затронет сетевое соединение между парами компьютеров, а во втором будет производиться синхронизация кэшей процессоров. В обоих случаях количество пар процессоров, нуждающихся в синхронизации, будет экспоненциально расти с ростом числа процессоров.
То же относится и к сотрудничеству людей. Чрезмерное увеличение числа работников в группе может привести к падению эффективности из-за роста затрат на общение (например, проведение деловых совещаний). Мне вспоминается один исполнительный директор, который утверждал, что лучший способ ускорить затормозившийся проект - это начать увольнять участвующих в нем сотрудников, поскольку чаще всего проекты тормозятся из-за слишком большого количества задействованного персонала. По-моему, он прав.
Дублирование и простота
Да, веб-сайты можно масштабировать, копируя данные с одного сервера на другой каждую ночьвеб-сайт;дублирование. Однако масштабирование через репликацию усложняет администрирование сайта, а чрезмерное усложнение для сайтов смертельно опасно. Гораздо проще реализовать схему с одним авторитетным источником данных.
С другой стороны, без репликации масштабируемость будет ограничена скоростью центрального источника данных, которым может являться, например, сервер NFS или реляционная база данных. Особенно сильно это ограничение действует при попытке записи в центральную базу данных, поскольку транзакции с базами данных должны удовлетворять так называемому ACIDACID, критерий-критерию (Atomicity, Consistency, Isolation, Durability - Атомарность, Непротиворечивость, Изоляция и Долговечность). Для обеспечения непротиворечивости (согласованности) и долговечности транзакции до ее начала необходимо заблокировать данные, с которыми вы собираетесь работать (это и будет изоляция). Это делается для того, чтобы никакой другой процесс не мог изменить и, возможно, разрушить данные в процессе транзакции, которая либо выполняется целиком до успешного завершения, либо полностью отклоняется (атомарность). Поскольку вы работаете с единственным набором данных и обращаетесь к ним строго последовательно, скорость выполнения транзакций будет огр
аничена тем, как быстро вы можете заблокировать, изменить и разблокировать данные в базе. Блокирование других процессов уменьшает производительность. Согласованность данных требует также синхронизации кэшей с системой записей. Долговечность означает, что данные сохраняются после перезагрузки компьютера. согласованность данныхЧасто забывают о том, что постоянная полная внутренняя согласованность базы данных не является обязательным требованием. Вполне допустима некоторая несогласованность, то есть противоречивость данных в течение некоторого промежутка времени. Это не приводит к слишком большому риску. Представим себе банк, у которого есть центральная база данных о состоянии счетов и кассовые терминалы с локальным кэшем. За один час с одного счета с одного терминала ATM можно снять не более 200 долларов, и при этом немедленного обращения к базе данных не произойдет: изменения будут кэшированы АТМ до конца часа. Это значительно ускоряет транзакцию с точки зрения пользователя. База данных синхронизируется в тече
ние часа с момента транзакции, причем для этого могут использоваться более медленные (но и более дешевые) линии связи. Банк подвергается некоторому риску, потому что за один час пользователь может обойти много терминалов и снять с каждого по 200 долларов, но этот риск считается пренебрежимо малым по сравнению с выигрышем для пользователя и для банка, особенно если банк предъявляет какие-либо требования к минимальному остатку на счете. Служащие банка всегда знают, сколько денег было на каждом счете час назад, но про текущий момент они не могут сказать ничего. Это компромисс между временем ожидания для пользователя, риском для банка, стоимостью передачи информации и сложностью программирования. масштабируемость;кластеризацияВсе более популярной становится кластеризациякластеризация - объединение нескольких компьютеров в один более мощный. Масштабирование веб-сайтоввеб-сайт;кластеризация методом кластеризации также ограничено возможностями передачи сведений о состоянии между отдельными компьютерами кластера. По
этой причине некоторые программные средства для кластеризации, такие как WebLogic, разделяют сведения о состоянии в любой конкретный момент лишь между двумя компьютерами кластера. При этом входящее подключение пользователя должно направляться на одну из двух машин, хранящих данные о нем, что усложняет схему. Такое решение иллюстрирует фразу Джеймса Гослинга о том, что решение проблемы обычно заключается в перемещении ее в другую часть системы.
Репликация медленно меняющихся данных обычно выполняется гораздо легче, чем репликация состояния одной конкретной транзакции. Существует множество готовых решений такой задачи - команды Unix rdistrdist, программа и rsyncrsync, программа, кэширующие прокси-серверы, программное обеспечение от компаний типа MarimbaMarimba, компания, а также коммерческие службы кэширования, такие как AkamaiAkamai, служба распространения данных и InktomiInktomi, служба распространения данных.
Синхронность и асинхронность
вызов;синхронныйСинхронные вызовы блокируются до возвращения результата. Большая часть веб-страниц заставляет вас бездельничать до тех пор, пока на экране не появится ответ на ваш запрос. Асинхронные вызовывызов;асинхронный возвращают управление немедленно. Некоторые асинхронные веб-страницы помещают ваш запрос в очередь, после чего немедленно отправляют вам сообщение о том, что ответ будет выдан позже (возможно, отправлен вам по электронной почте). Все зависит от того, готовы ли вы ждать в бездействии до получения ответа или же хотите заняться другими делами.
Другой пример синхронного вызова - запрос к базе данных JDBC, блокирующий вызвавший его программный поток до получения результата. При этом масштабируемость ограничивается скоростью базы данных. Если у вас в какой-то момент появится больше запросов, чем потоков, все потоки окажутся заблокированы, и сайт перестанет обслуживать пользователей. С другой стороны, асинхронные системы работы с сообщениями, такие как TibcoTibco, система передачи сообщений и MQMQ, система передачи сообщений, дают вам возможность отправлять сообщение с запросом и заниматься чем-то другим.
Зачем же вообще нужны в таком случае синхронные вызовы? Они обладают тем преимуществом, что вы узнаете результат вызова до продолжения работы. При асинхронном вызове сообщение об ошибке может быть доставлено существенно позже либо не доставлено вовсе. Синхронные вызовы использовать проще, поскольку они не требуют отдельной обработки результатов.
Связь без логического соединения
соединение;логическоеПротоколы без логического соединения не требуют поддержания соединения в промежутках между запросами. Протокол HTTPHTTP, протокол использует логические соединения TCPсоединение;TCP, но для очередного запроса не обязательно использовать то же соединение, которое использовалось для предыдущего, поэтому его можно назвать протоколом без соединения.
Хотя HTTPHTTP, протокол;эффективность неэффективен в том смысле, что для передачи небольших объемов данных этот протокол требует установки и завершения соединения по TCP, именно короткое время жизни соединений обеспечивает масштабируемость HTTPHTTP, протокол;масштабируемость. Вероятность одновременного существования множества соединений достаточно мала, потому что эти соединения чрезвычайно коротки. Соединениям не приходится делить между собой ресурсы сервера. Например, вероятность того, что пул сокетов будет исчерпан, невелика, потому что соединения сразу же закрываются после использования.
Поскольку протокол HTTPHTTP, протокол;информация о состоянии не сохраняет информацию о состоянии, пользователи никак не могут определить, какой именно сервер отвечает на их конкретный запрос. Это облегчает динамическое добавление дублирующих серверов при работе со статическим содержимым и является фундаментальным преимуществом веб перед, к примеру, архитектурой "клиент-сервер".
Планирование и разработка
планирование программразработка программЕсть вещи, которые нельзя использовать, пока они не будут готовы полностью. Это самолеты, мосты и ядерные электростанции. В программировании все не так. Можно быстро написать небольшую программку, которая будет делать что-то полезное, выложить ее в сеть, получить отзывы и заняться ее улучшением. Это самый эффективный способ написания программ с точки зрения стоимости. О том, почему дела обстоят именно так, рассказывается на сайте eXtreme Programmingэкстремальное программированиеeXtreme ProgrammingXP См. eXtreme Programming (http://www.xprogramming.com/what_is_xp.htm). Основная мысль состоит в том, что в быстро меняющемся мире (например, Интернет) нет смысла писать большие программы "на будущее", поскольку неизвестно, каким будет это будущее. Важно придерживаться основных принципов, делая программы простыми и гибкими, чтобы иметь возможность быстро реагировать на изменения в окружающем мире.
К сожалению, последовательное усовершенствование программ и постоянное изменение требований лишают вас возможности четко сказать руководству, чего именно оно может ожидать на вложенные деньги. Начальству нравятся четкие проекты с фиксированным бюджетом и жестким расписанием, но какой смысл пытаться упорядочить то, в основе чего лежит хаос? Вы лишь погрязнете в сложных науках о нормализованных унифицированных процессах и тому подобных вещах. К тому времени, когда вы что-нибудь разработаете, оно наверняка устареет.
Есть еще один пример избыточного планирования. Не стоит создавать математическую модель системы, чтобы с ее помощью пытаться предсказать, какова будет мощность вашей системы. Небольшие изменения в коде могут весьма существенно влиять на производительность, но учесть все мелочи в модели невозможно. Гораздо эффективнее просто тестировать систему по мере ее создания. Моделирование может использоваться для оценки производительности лишь самых простых систем, а если ваша система настолько проста, что ее можно смоделировать, то она наверняка будет настолько быстра, что моделировать ее будет незачем.
Процедурное и объектно-ориентированное программирование
объектно-ориентированное программирование См. ООПОбъектно-ориентированное программирование (ООП) предоставляет вам множество способов замедлить работу ваших программ. Изначально оно было придумано для того, чтобы программисты могли создавать повторно используемые компоненты, но ООПООП редко используется по прямому назначению. Избыточные затраты на "планирование с расчетом на будущее", разработку объектных моделей и обсуждение интерфейсов компонентов обычно сводят к нулю преимущества ООП перед программированием на процедурном языке. ООП не делает код более пригодным для повторного использования, оно не ускоряет время разработки и вообще не дает ничего, что нельзя было бы сделать с той же легкостью на языках С или Perl. Причина, по которой использование языка Java может действительно сокращать время разработки, - наличие множества хороших переносимых библиотек, интерфейсы к которым уже широко известны. Другая причина, по которой кодирование на Java оказывается быстрее, состоит в том, что исключаются ошибки, свя
занные с использованием указателей. С другой стороны, за это приходится платить: на проверку границ массивов и сборку мусора расходуются ресурсы системы. Все это имеет весьма отдаленное отношение к объектной ориентированности языка Java.
Хорошо известно, что объектно-ориентированные программы работают медленнее, чем написанные с использованием процедурного подхода. Причин тому имеется несколько. Во-первых, нарушаются типичные схемы кэширования из-за отсутствия локальности ссылок. Во-вторых, для обращения к родительским классам и их полям обычно используется несколько уровней вложенности.
ООП поощряет взаимозависимость классов, а это затрудняет их повторное использованиеповторное использование. В действительности ООП неизбежно ведет к образованию пестрого множества самодельных интерфейсов и абсолютных зависимостей между объектами. В результате получается огромный клубок кода, пронизанный переплетением связей, и ни одна часть его не может быть использована без поиска и загрузки всех остальных частей. Программы, вызываемые из интерпретатора Unix, являются гораздо более удачными примерами повторно используемого кода, чем большая часть программ на C++ или Java. Попробуйте воспользоваться хотя бы одним классом из любой библиотеки Java так, как вы бы воспользовались какой-нибудь программой Unix типа cat, ls или wc. Не получится! А ведь все программы Unix можно вызывать из других программ, соединяя их каналами для конвейерной обработки, потому что у них у всех имеется одинаковый чудесный простой интерфейс - стандартные потоки ввода, вывода и сообщений об ошибках.
Как бы ни было плохо объектно-ориентированное программирование, распределенное ООПООП;распределенное еще хуже. Помимо ужасной производительности, программы, написанные с использованием концепции распределенного ООП, чрезвычайно сложны в тестировании, поскольку для связи между объектами не используется простой протокол типа HTTP. Вместо этого при удаленных вызовах методов обычно происходит сборка объектов для пересылки их по сети в качестве параметров. Это означает, что отправка даже одного-единственного символа данных требует огромных накладных расходов на упаковку этого символа в объект, сборку объекта, а затем восстановление его на другом конце. Распределенное ООП порождает хрупкие, неустойчивые программы, поскольку удаленные вызовы должны быть совершенно корректными, а к ошибкам такого рода программисты обычно заранее не готовятся. Сравните это с веб. Программы CGI вызываются множеством различных клиентов без какого-либо специального протокола. Веб гораздо более снисходительна к программисту.
Я не люблю ООП прежде всего потому, что моей целью является достижение максимальной производительности. Бывает, что ООП заметно облегчает кодирование программ. Если вас интересуют другие точки зрения, попробуйте обратиться по адресу: http://martinfowler.com/isa/layers.html.
Основы
В этом разделе мы рассмотрим основные составляющие элементы архитектурной схемы веб-сайтавеб-сайт;архитектура.
Браузер
Веб-браузербраузер представляет собой практически идеальный графический интерфейс пользователяGraphical User Interface См. GUI (Graphical User Interfaceграфический интерфейс пользователя См. GUI - GUIGUI), поскольку он прост, стандартизован и распространен повсеместно. С его помощью можно вывести на экран все, что может быть нужно пользователям: текст, графику, кнопки, поля для заполнения и так далее. Разработка GUIGUI;разработка на HTML на HTML проста настолько, насколько это вообще возможно. Для создания GUI на Visual Basic или Java требуется гораздо больше опыта, причем взаимодействие интерфейса с программой обычно осуществляется не в стиле протокола HTTP, что существенно усложняет тестирование и требует от пользователей загрузки интерфейса для каждого отдельного приложения. Практически на всех персональных компьютерах мира сейчас имеется хоть какой-нибудь браузер, способный читать HTML, и нужно быть сумасшедшим, чтобы этим не пользоваться.
Особенно плохая идея - оптимизировать сайты под Internet Explorer или Netscapeвеб-сайт;оптимизация под браузер. Ведь главное достоинство веб - повсеместная распространенность и переносимость. Если вы попытаетесь предъявить какие-то лишние требования к пользователям, вы не только заставите отвернуться от вас тех, кто не пользуется рекомендуемым вами браузером, но также подвергнетесь опасности сделать свой сайт платформенно-зависимым. Став зависимым от конкретного браузера, вы ограничите не только свободу своих пользователей в выборе браузеров, но и свою собственную свободу в представлении содержимого. Зачем лишаться свободы?
С появлением стандарта объектной модели документа Document Object Model См. DOM(Document Object Modelобъектная модель документа См. DOM - DOMDOM) браузеры могут делать практически все, что доступно всем прочим видам GUI: сортировать столбцы, загружать только данные либо части HTML-страниц, а также отображать множество элементов, которые без этого стандарта пришлось бы реализовать как Java-апплеты. Объектная модель документаDOM;поддержка поддерживается браузерами Internet Explorer (IE), Netscape и Opera, хотя и в разной степени. В IE и Netscape используются разные версии DOM; более того, версии Netscape 4 и 6 также отличаются в трактовке DOMDOM;различия трактовки.
У браузеров могут возникать проблемы при загрузке очень больших документов или поиске по ним, поскольку браузеры часто занимают чрезмерный объем памяти и работают заметно медленнее, чем могли бы. Тем не менее я не могу порекомендовать использовать для распределенных приложений какой-либо другой графический интерфейс пользователя из-за того, что преимущества браузеров затмевают все их недостатки.
Система балансировки нагрузки
Балансировка нагрузкибалансировка нагрузки необходима для масштабирования веб-сайта. Можно распределять нагрузку по разным веб-серверам или запросы от серверов по связующим программам и устройствам. В любом случае вы можете выбирать из множества бесплатных и коммерческих продуктов.
Уровень DNS
балансировка нагрузки;RRDNSНаиболее часто используемое решение называется круговой системой DNSкруговая система DNSDNS;круговая система (Round Robin DNSRound Robin DNS См. RRDNS - RRDNSRRDNS). Идея состоит в настройке DNS-сервера так, чтобы возвращать в ответ на запрос с именем вашего веб-сервера несколько IP-адресов. Клиент выбирает любой из этих адресов. Обратите внимание: клиенты с Windows выбирают один IP-адрес и в дальнейшем обращаются только к нему, тогда как клиенты с Unix могут переключаться между предложенными IP-адресами. Альтернативный подход: сервер DNS перебирает адреса самостоятельно, возвращая клиенту только один из них в ответ на каждый запрос. Круговая система DNS действительно осуществляет балансировку нагрузки, но результат может отличаться от ожидаемого или желаемого по следующим причинамRRDNS;недостатки.
Хотя запросы клиентов распределяются по серверам равномерно, RRDNS не делает попытки найти ближайший или по каким-либо другим параметрам наиболее подходящий сервер для каждого клиента. Время отклика может заметно меняться, если эти серверы располагаются в разных точках Земли или просто неэквивалентны друг другу.
Круговая система DNS не обеспечивает реальной балансировки нагрузки, но в простейшем случае она до какой-то степени выравнивает ее. Реальная балансировка нагрузки подразумевает измерение степени загруженности серверов и распределение новых клиентов в соответствии с этой загруженностью таким образом, чтобы клиенты всегда обращались к серверам, имеющим достаточно ресурсов, чтобы их обслужить. Это особенно важно для вычислительноемких процессов CGI. Нехорошо, если два сложных запроса обрабатываются одним сервером, в то время как другой сервер загружен на самую малость и занимается обработкой одного простого запроса.
Когда один из серверов, входящих в круговую систему DNS, работает значительно медленнее, чем остальные серверы, возникает особая ситуация, называемая "конвоированием"RRDNS;конвоирование. Пользователи при этом выстраиваются в очередь на медленных серверах, а быстрые серверы остаются без запросов. Если вам когда-нибудь приходилось ездить по узкой горной дороге, вы, возможно, сталкивались с чем-то подобным. Никто не может ехать быстрее, чем самая медленная машина. Все остальные догоняют ее и выстраиваются за ней в длинный хвост. При настоящей балансировке нагрузки такой проблемы не возникает, поскольку пользователи распределяются по серверам именно так, чтобы те были одинаково загружены. Если придерживаться нашей аналогии, "машины" получают возможность "обгонять друг друга".
RRDNS никак не обрабатывает возможные сбои серверовRRDNS;сбои серверов. Пользователи продолжают направляться на отказавший сервер. При реальной балансировке нагрузки надежность сайта повышается, поскольку при сбое одного сервера остальные автоматически берут его клиентов на себя.
Наконец, RRDNS усложняет сохранение данных о состоянии пользователей. Предположим, пользователь работает со своей корзиной, данные о состоянии которой хранятся в памяти сервера. При использовании RRDNS при каждой операции HTTP может быть выбран новый сервер, так что пользователь может даже получить сообщение о том, что он не вошел в систему, поскольку его сеанс открыт на другом сервере. Нельзя заставить клиентов придерживаться один раз выбранного IP-адреса из набора адресов, поскольку существует множество реализаций клиентов DNS.
Если вы решите удалить IP-адрес, вам придется помучиться из-за того, что изменения в системе DNS распространяются медленно и серверы DNS множества пользователей будут предоставлять им кэшированный IP-адрес вашего сервера в течение некоторого заметного промежутка времени. Это означает, что пользователи могут попытаться обратиться по неправильному IP-адресу. В результате они решат, что ваш сайт не работает. Операционная система Windows кэширует таблицу DNS, а клиенты Unix - нет. Это приведет к возникновению множества противоречивых сообщений, если, к примеру, один из двух серверов выйдет из строя. Половина пользователей Windows сообщит, что ваш сайт не работает, а другая половина будет считать, что все в порядке. Пользователи с Unix будут получать сообщения об ошибках при каждом втором обращении к сайту.
Уровень IP
балансировка нагрузки;Local DirectorБолее сложное решение предлагается фирмой Resonate в виде коммерческого программного продукта Local DirectorLocal Director, система балансировки нагрузки ("локальный направитель"). Local Director работает на уровне протокола IP, отображая один "виртуальный" IP-адрес на реальные IP-адреса нескольких компьютеров. Он действительно измеряет использование ресурсов всех компьютеров и выбирает из них наиболее подходящий в соответствии с набором изменяемых правил. Эта программа позволяет с легкостью удалить из группы один из серверов при возникновении на нем неполадок (в отличие от круговой системы DNS). Фирма ResonateResonate, фирма имеет достаточно хорошую репутацию с точки зрения надежности программного обеспечения.
У записей DNS существует ограничение: в базе может быть не более 32 полей на одну запись, поэтому нельзя указать более 32 IP-адресов для одного имени DNS. Программа Resonate под названием Global DirectorGlobal Director, система балансировки нагрузки ("глобальный направитель") использует для балансировки нагрузки систему DNS и не страдает из-за этого ограничения. Подробности см. на веб-странице фирмы Resonate (http://www.resonate.com/).
Еще один способ балансировки нагрузки на уровне IP состоит в создании двух серверов на разных концах страны и присвоении им одинаковых IP-адресов. Протокол маршрутизации BGPBGP, протокол изначально гарантирует, что пакеты TCP не будут блуждать зря: нагрузка на эти серверы будет сбалансирована автоматически.
балансировка нагрузки;многоадресная передачаЕсть и еще один хитрый метод использования IP для балансировки нагрузки. Он заключается в применении многоадресной передачи. Многоадресная передачамногоадресная передача - это механизм публикации и подписки, работающий на уровне IP. Некоторые IP-адреса считаются адресами многоадресной передачи. Данные, отправляемые на такой адрес, автоматически передаются всем выразившим свою заинтересованность в их получении, а прочие адресаты их не получают, что заметно экономит пропускную способность сети по сравнению с широковещательной передачей. Многоадресная передача может быть использована в распределении нагрузки веб следующим образом: несколько веб-серверов подписываются на один адрес многоадресной передачи, причем каждый из этих серверов отвечает только на запросы определенного типа (например, запросы с IP-адресов из своего диапазона или запросы на конкретные данные). Все прочие запросы сервером игнорируются.
Одна из проблем с многоадресной передачей состоит в том, что все маршрутизаторы между отправителем и получателями должны понимать протокол многоадресной передачи. В настоящее время на это способны не все маршрутизаторы. Подробнее об использовании многоадресной передачи для балансировки нагрузки на веб-серверы читайте по адресу: http://gizmo.lut.ac.uk/~martin/wwwcac/wwwcac.html.
Уровень Ethernet
балансировка нагрузки;уровень EthernetАппаратные устройства, обеспечивающие балансировку нагрузки, обычно работают на уровне Ethernet, отображая один IP-адрес на несколько интерфейсных карт Ethernet и таким образом разделяя между ними нагрузку. Работа на уровне Ethernet ограничивает возможности аппаратных систем балансировки одной подсетью, тогда как программные системы балансировки нагрузки типа Local и Global Director могут работать в нескольких подсетях. Нужно учитывать и еще один важный фактор: придется ли вам выкидывать аппаратную систему балансировки нагрузки, когда она устареет, или вы сможете приспособить ее куда-то в другое место.
Вне зависимости от того, осуществляется ли балансировка нагрузки на уровне DNS, IP или Ethernet, она оказывается более эффективной в том случае, если нагрузка распределяется между серверами приблизительно одинаковой мощности.
Веб-сервер
веб-серверВеб-серверы в настоящее время уже стали обычным товаром. Мой совет: используйте веб-сервер ApacheApache, веб-сервер, потому что он бесплатный, очень надежный и быстрый. Вообще говоря, большая часть веб-сайтов в Интернете использует сервер Apache.
Информационный сервер Интернета (Internet Information ServerInternet Information Server См. IIS - IISIIS, веб-сервер) лучше не использовать - главным образом потому, что он уязвим для опасных вирусовIIS, веб-сервер;уязвимость. На эту тему имеется специальный отчет группы Гартнера (Gartner Group). Есть и другая причина, по которой не стоит использовать IIS: Microsoft всегда пытается заставить вас хранить свое содержимое в его собственном недокументированном формате. IIS представляет собой серьезную угрозу переносимости вашего содержимого. Apache прекрасно работает под Windows и не таит в себе такой угрозы. Кроме того, на Apache почти не действуют вирусы.
СОВЕТ. Содержимое и журналы веб-сервера следует держать отдельно, на разных физических дисках, чтобы они не мешали друг другу.
Связующие программы
связующая программа Любое программное обеспечение, взаимодействующее с веб-сервером и базой данных, может считаться связующим (middlewaremiddleware). Первым связующим ПО был интерфейс CGICGI, интерфейс, но никто его так не называл. Вскоре после начала широкого распространения CGI Netscape и Microsoft предложили свои API для генерации динамического содержимого непосредственно из процесса веб-сервера. Эти интерфейсы работали гораздо быстрее, но абсолютно не являлись переносимыми и были склонны "завешивать" сервер, в отличие от CGI. После этого на рынок вышла компания Sun с API серверных приложений (сервлетов сервлет- servletsservlet) для Java, который по производительности лежит между CGI и серверным API, но является безопасным и переносимым. Большая часть современных связующих программ развилась из сервлетов. Пакет TuxedoTuxedo, программный пакет и системы передачи сообщений типа TibcoTibco, система передачи сообщений и MQMQ, система передачи сообщений также могут использоваться как связующие программы. Компан
ия Sun в настоящий момент продвигает на рынок пакет Enterprise JavaBeansEnterprise JavaBeans См. EJB - масштабируемое решение в области связующего ПО, но у этого пакета имеются серьезные проблемы с производительностью, вызванные использованием удаленных объектов. Удаленные вызовы методов удаленные вызовы методовработают гораздо медленнее локальных по множеству причин. Во-первых, между компьютерами физически имеется некоторое расстояние. Скорость света увеличить невозможно, поэтому с данной точки зрения ситуация никогда не улучшится. Во-вторых, при выполнении вызовов RMIRMI компьютерам приходится осуществлять сборку и разборку объектов-параметров.
Еще одна проблема с EJB связана с тестированием. Вам не удастся легко просмотреть сетевой трафик RMI - во всяком случае, так же легко, как данные HTTP. И написать тестовый клиент для RMI весьма непросто, в отличие от HTTP.
Интересно сравнить команду HTTP POSTPOST, команда HTTP с удаленными вызовами процедур (собственно говоря, POST - тоже удаленный вызов процедуры). Пользователь читает форму, вводит в нее данные, после чего отправляет эти данные программе, выполняющейся на другом конце соединения. Отличие состоит в том, что форма хранится в формате, удобном для чтения, и никто не ожидает, что браузер клиента будет вызывать удаленную программу с частотой, сравнимой с вызовами RMI. Вызовы HTTP POST широко используются для ввода пользовательских данных на веб-сайтах благодаря жесткой стандартизации и универсальному формату аргументов и входных данных. Любой пользователь с любым браузером может передать данные на любой веб-сервер. Простота и переносимость правят миром!
База данных
база данных Таблицы баз данных должны быть определены, дублированы, разделены и предоставлены для внешнего доступа таким образом, чтобы обеспечивался максимальный уровень параллельности операций и данные передавались по возможности равномерно. Оптимизация баз данных - серьезная тема, на которую уже написано множество книг. Хороший администратор баз данных стоит очень дорого.
Пример архитектуры веб-сайта
Теперь, когда вы знаете основные элементы архитектуры веб-сайтавеб-сайт;примеры архитектуры и изучили противоречивые требования к ним, вам придется решить, как совместить все это в одном целом. Существует великое множество возможных комбинаций программ и оборудования, но их можно разделить на небольшое количество основных категорий, перечислить которые несложно. Сервер статического содержимого легко масштабировать с помощью системы балансировки нагрузки, поэтому рассматривать его не слишком интересно. Вместо этого я решил сосредоточиться на веб-сайтах с поддержкой транзакций, а также на сайтах, состоящих в большой степени из динамического содержимого. Можно получить множество примеров описаний архитектуры, почитав подробности любого тестирования, проведенного каким-либо из поставщиков оборудования или программного обеспечения. Примеры имеются на сайте Web Bench (http://www.spec.org/). Далее мы рассмотрим наиболее типичные ситуации.
Один компьютер
Большая часть небольших веб-сайтов работает на одном компьютере и обычно использует LinuxLinux, операционная система, ApacheApache, веб-сервер, MySQLMySQL, база данных и PerlPerl, язык (получаем аббревиатуру LAMPLAMP, набор программ для веб-сайта). Использование единственного компьютера означает, что между компонентами на стороне сервера не будет никакого сетевого трафика и, более того, для связи, скорее всего, будет использоваться не относительно медленный интерфейс сетевой карты с терминатором, а чрезвычайно быстрая память с общим доступом. Серверу придется переключаться между различными процессами, а на переключение контекста тратятся ресурсы, но производительность такой машины может быть все равно выше, чем у нескольких специально выделенных компьютеров, соединенных между собой с помощью Ethernet. Трудно сказать, является ли один компьютер более надежным, чем несколько, или же наоборот.
Большие веб-сайты тоже могут работать на одной машине. В частности, OracleOracle, база данных отлично функционирует в том случае, если веб-сервер Oracle Web ServerOracle, база данных;Oracle Web Server и база данных работают вместе. Недостатком данного подхода является масштабируемость: вы ограничены возможностями одного компьютера - если, конечно, вам не удастся благополучно выполнить кластеризацию (сделать это непросто).
Аналогичный подход состоит в использовании ровно двух компьютеров, один из которых отводится только под статическое содержимое (например, изображения), а второй - под динамическое, формируемое сервлетами или CGI. Преимущество этого подхода в том, что повышение производительности двух компьютеров можно проводить независимо. У компьютера, обслуживающего статическое содержимое, должно быть достаточно памяти, чтобы все оно туда помещалось. На второй машине должно быть несколько быстрых центральных процессоров.
Стековая архитектура
стековая архитектура Стековая архитектура ограничивает возможности хранения информации о состоянии базой данных. Остальная часть системы представляет собой просто "трубытруба" (funnelsfunnel) к базе данных, поэтому вы можете легко выполнять масштабированиестековая архитектура;масштабируемостьмасштабируемость;стековая архитектура, увеличивая количество этих труб и не беспокоясь о распределении нагрузки, обновлении информации о состоянии и других проблемах. Ни в одной из частей стека не происходит кэширования информации о состоянии, поэтому производительность зависит только от того, насколько быстро вы можете обращаться к базе данных и насколько быстро она вам отвечает. Ахиллесова пята в данном случае - это, разумеется, база данных.
Примером стека с использованием современного коммерческого программного обеспечения может служить система, осуществляющая балансировку нагрузки между множеством небольших веб-серверов Sun, которые подключаются к своим связующим серверам, представляющим собой сервлеты без информации о состоянии (которые, в свою очередь, используют для обеспечения цельности транзакций программный пакет TuxedoTuxedo, программный пакет и подключаются к базе данных OracleOracle, база данных). Получается, что каждый веб-сервер, зажатый с двух сторон брандмауэрами, подключается к одному связующему серверу, который подключается к базе данных. Связь между элементами осуществляется через сеть, поэтому для ограничения трафика в сегментах сеть должна разбиваться на подсети. Если из-за сбоя отключается один из веб-серверов, соответствующий ему связующий сервер становится бесполезным (и наоборот).
Уровни
многоуровневая архитектура Многоуровневая архитектура эффективна с точки зрения использования ресурсов. Каждый веб-сервер находит наименее загруженный связующий сервер, что увеличивает общую производительность по сравнению со стековым подходом. Такая схема иногда называется "nґn". Другое преимущество состоит в том, что выход из строя одного компьютера не влияет на использование других компьютеров.
Уровень веб-серверов в "демилитаризованной зонедемилитаризованная зона" (участок между Интернетом и локальной сетью), соединенный с уровнем связующих серверов, требует добавления еще одной системы балансирования нагрузки. Для увеличения производительности можно сделать веб-серверы многосетевыми (multihomed) узламимногосетевой узел, установив на них по две сетевые карты (одну для Интернета и одну для внутренней сети, где находятся связующий сервер и база данных).
Множество небольших компьютеров, специализированных под конкретную задачу, работают гораздо быстрее, чем несколько мощных, и при этом оказываются надежнее, поскольку выход из строя одного из них не влияет на все остальные. При этом цена в расчете на один компьютер оказывается ниже, но места все это занимает больше и требует больших затрат на администрирование, что может в итоге свести положительный эффект к нулю. Место для компьютеров иногда стоит дороже самих компьютеров, поскольку стоимость его включает затраты на питание и охлаждение.
Linux на мейнфрейме
Linux, операционная система;на мейнфреймеНаиболее интересное новое архитектурное решение, о котором я слышал, состоит в том, чтобы запустить тысячу Linux на одном мейнфреймемейнфрейм OS390. Правда, я не слышал, чтобы кто-нибудь реально это использовал. Отличная документация на эту тему находится по адресу: http://www.4th.com/tech/linux/vmlinux.shtml. Как и в других вариантах с использованием одного компьютера, в данном случае не возникает никаких проблем с внутренней сетью. Масштабируются мейнфреймы неплохо, а проблемы с производительностью и размерами уже хорошо изучены. Недостатками являются высокая стоимость мейнфреймов и ограниченность в выборе производителя.
Реальный масштаб времени
В принципе возможно написать веб-сервер с заранее известными задержками и потреблением ресурсов, хотя я не слышал, чтобы это было действительно кем-то сделано. Точно зная потребность в ресурсах, мы можем точно сказать, сколько пользователей смогут одновременно пользоваться нашим сервером. Это означает, что планирование мощности становится наукой, а тестирование нагрузки - просто подтверждением того, что и так известно.
Для того чтобы написать такой сервер, нужно воспользоваться операционной системой реального времениоперационная система;реального времени. На настоящий момент операционные системы реального времени используются в основном для встроенных систем, в тех случаях, где необходимо получить гарантированное время отклика - в машинах, самолетах и военной технике. Однако операционные системы реального времени могут использоваться и для веб-серверов, связующих серверов и баз данных. Сам Интернет имеет переменное время ожидания, но это не умаляет преимуществ, которые дают нам заранее известные мощность и время задержки сервера.
Компания TimeSysTimeSys, компания (http://www.timesys.com/) продает ядро LinuxLinux, операционная система;ядро реального времени реального времени, а также виртуальную машину Java того же свойства. Их время задержки известно заранее, но обычно оно оказывается несколько большим, чем в системах без гарантированного времени отклика. Кроме того, программист должен уметь профилировать код и пользоваться предоставленными ему возможностями.
Тенденции
тенденции Хотя пропускная способность постоянно растет, задержки в Сети не уменьшаются. Пакеты уже сейчас передаются практически со скоростью света, так что этот параметр вырасти уже не может. Это означает, что передача тысячи небольших пакетов осуществляется за время, пропорциональное расстоянию между точками, так что географическое положение сервера все еще имеет некоторое значение, да и всегда будет иметь.
Для компенсации внутренних задержек Интернета существует тенденция отправлять ответы пользователям еще до того, как они их попросят. Статическое содержимое уже сейчас распределяется компанией AkamaiAkamai, служба распространения данных по серверам, расположенным по всему миру. Следующим логическим шагом будет распределение приложений, порождающих страницы. Дальше я предвижу, что динамическая генерация страниц будет возложена на сам браузер. До некоторой степени это уже произошло, поскольку современные браузеры могут кэшировать XSL и изображения, после чего обновлять и переформатировать фрагменты данных XMLXML, язык в пределах одной страницы с использованием стандарта DOMDOM;перспективы для структур данных браузера и языка JavaScript для изменения этих структур. В течение некоторого времени можно было запрашивать фрагменты веб-документов с помощью запроса HTTP Byterangebyterange, запрос HTTP, поддерживаемого большей частью веб-серверов. Проблема в том, чтобы браузер смог объединить этот новый фрагмент документ
а с той его частью, которая уже была кэширована браузером. Такие вещи уже выполняются с помощью апплетов, но требуют большой самостоятельной работы. С помощью стандарта DOM это делается гораздо проще. Таким образом, большая часть связующих программ может быть исключена из использования. Возможно также, что браузеры смогут сами взаимодействовать с реляционными базами данных, осуществляя запросы SQL для получения и обновления страниц.
Здесь вы можете спросить: нельзя ли запихать в браузер и базу данных, если уж мы взвалили на него все остальное? Вообще говоря, она там уже есть и всегда была - в кэше браузера. Кэш не является реляционным, но в нем можно сохранять и искать данные. Основная проблема тут заключается в том, что пользователь не может явно управлять кэшем. Пользователи не могут выполнять поиск по кэшу, помещать туда данные, а также обновлять или удалять их. Если вы знаете, как работает кэш вашего браузера, вы можете изменить его, но это не то же самое, что обратиться к нему с веб-страницы. После того как мы получим такую возможность, обновление страниц и приложений будет выполняться гораздо быстрее и с передачей меньших объемов данных.
Другая область, где возможны значительные улучшения производительности, - это уменьшение количества передаваемых пакетов путем использования протокола TCPTCP, протокол;транзакции для транзакций (T/TCPT/TCP, протокол), который позволяет установить соединение по TCP, передать данные и закрыть соединение - и все это одним пакетом. К сожалению, столь значительное улучшение осуществить невозможно, если не обновить стек протоколов TCP на клиентских компьютерах.
Программы, используемые на широко известных сайтах
На странице http://www.keynote.com/measures/business/business40.html имеется список провайдеров доступа к Интернету и программного обеспечения, используемого 40 большими компаниями. Вы можете получить те же сведения самостоятельно с помощью программ traceroutetraceroute, программа и telnettelnet, программа, обращаясь к порту 80. Самые популярные провайдеры, по данным KeynoteKeynote, фирма, - UUNET, BBN и MCI, а наиболее популярные веб-серверы - Netscape EnterpriseNetscape Enterprise, веб-сервер и Apache. Есть и еще сайт с множеством данных по веб - http://www.securityspace.com/.
Примеры конфигураций
Давайте рассмотрим несколько примеров конфигураций веб-сайтов, рассчитанных на низкую, среднюю и высокую нагрузкувеб-сайт;примеры конфигураций.
Низкая нагрузка
веб-сайт; с низкой нагрузкойСайт с низкой нагрузкой обрабатывает от одного до десяти тысяч обращений в день. Такой сайт легко можно установить у себя дома. Типичная конфигурация: хороший компьютер (2000 долларов), LinuxLinux, операционная система 2.2 (бесплатно), ApacheApache, веб-сервер 1.3 (бесплатно) и связь по кабельному модему (100 кбит/с, 100 долларов в месяц).
База данных может быть реализована в обычных файлах, или через хэш-таблицу языка Perl, или как массив в программе CGI, и у вас не возникнет никаких проблем при небольшом числе пользователей и размере базы данных в несколько тысяч записей. После того как частота обращений превысит 1 запрос в секунду или база данных превысит объем в несколько тысяч элементов, вам лучше будет перейти на бесплатную реляционную базу данных MySQLMySQL, база данных.
Слабыми местами в такой конфигурации являются база данных и соединение с Интернетом. Напротив, Apache и Linux способны выдержать заметно большую нагрузку.
Средняя нагрузка
веб-сайт; со средней нагрузкойСайт со средней нагрузкой обрабатывает от 10 000 до 1 000 000 обращений в день. Типичная конфигурация - Sun Ultra или Intel Pentium Pro со 128 Мбайт памяти для операционной системы и буфера файловой системы плюс от 2 до 4 Мбайт на каждый процесс сервера. Конечно, чем больше памяти, тем лучше, лишь бы вы могли себе это позволить: такие рабочие станции стоят от 2000 до 20 000 долларов.
Под содержимое и журналы лучше отвести отдельные диски (и еще один - под виртуальную память), а размер диска под содержимое должен быть таким, чтобы оно свободно на нем умещалось. Массивы дисков всегда работают лучше при случайном обращении к данным, так как несколько операций поиска может осуществляться параллельно.
Количество сетевых интерфейсов можно увеличить, добавив нужное количество сетевых карт 10BaseT или 100BaseT, где верхний предел лежит на уровне 45 карт для некоторых систем Solaris. Веб-сервер ApacheApache, веб-сервер прекрасно обслуживает веб-сайты со средней нагрузкой, но вы можете перейти на NetscapeNetscape Enterprise, веб-сервер или другой коммерческий сервер при повышении нагрузки либо для обеспечения поддержки, либо для обеспечения должного уровня защищенности.
Один миллион обращений в день кажется довольно большим числом, но это всего лишь около 12 обращений в секунду (при равномерном распределении по времени дня). Даже 20 обращений в секунду вполне могут быть обработаны большей частью рабочих станций, если сайт содержит только статические страницы и изображения, а не динамическое содержимое. С другой стороны, 20 обращений в секунду - это довольно большая нагрузка с точки зрения Сети. Если на среднестатистический запрос отправляется 10 Кбайт, то мы получаем 10 Кбайт/запросґ8 бит/Кбайтґ12 запросов/с= 983 040 бит/с. Вам может показаться, что одна линия T1 со скоростью передачи 1 540 000 бит/с может обслужить эти запросы, но подумайте о том, что трафик веб является, скорее, импульсным, нежели непрерывным, поскольку одно обращение к странице подразумевает передачу всех изображений, апплетов и так далее, поэтому можно ожидать, что пиковая нагрузка будет в 3-5 раз выше средней. Это значит, что вы, скорее всего, не сможете обслужить миллион запросов в день через одну лини
ю T1, но сможете обслужить 100 000 таких запросов.
Если ваш сайт работает с базой данных, есть смысл использовать мощные коммерческие СУБД типа OracleOracle, база данных, InformixInformix, база данных, SybaseSybase;база данных, цены на которые лежат в диапазоне от 10 до 50 тысяч долларов. Максимальную производительность можно получить, используя диспетчер подключений от производителя базы данных, но можно написать и свой диспетчер. Лучше всего пользоваться не CGICGI, интерфейс, а сервлетами FastCGIFastCGI, стандарт либо API серверов - такими, как Apache APIApache, веб-сервер;API, NSAPINSAPI, интерфейс или ISAPIISAPI, интерфейс.
Большая нагрузка
веб-сайт; с большой нагрузкойСайт с большой нагрузкой получает более миллиона обращений в день. Множество примеров конфигураций таких сайтов можно найти по адресу: http://www.spec.org/osg/web99 в разделе Tuning Descriptions. Другие примеры конфигураций можно поискать по адресу: http://www.sun.com/software/solutions/blueprints/.
Какие сайты являются наиболее загруженными?
веб-сайт; рейтингиСписок ста наиболее загруженных сайтов мира можно найти по адресу: http://www.hot100.com/. Данные такого рода получаются в основном из анализа журналов прокси-серверов. Рейтинги сайтов со временем меняются. На момент написания этой книги первая десятка выглядела так:
http://www.yahoo.com
http://www.microsoft.com/
http://www.lycos.com/
http://www.aol.com/
http://www.go.com/
http://www.google.com/
http://www.altavista.com/
http://www.excite.com/
http://www.chek.com/
http://www.fortunecity.com/
Основные рекомендации
Помните о том, что иногда приходится идти на компромиссы.
Планируя архитектуру, спросите себя: "Если я решу, что это меня не устраивает, смогу ли я легко сменить эту архитектуру на другую уже после реализации?".
Планируйте сайт с расчетом на будущее, а не так, чтобы он отвечал только вашим сиюминутным потребностям.
Тюнинг веб-сервера. 2-е издание. / П. Киллелиа - СПб: Питер, 2003. - 528 с.
|