Тюнинг веб-сервера. 2-е изд.
П. Киллелиа
Архитектура веб-сайта
Разработчикам веб-сайтов часто приходится идти на компромиссы. Им нужно подбирать оптимальную конфигурацию и выбирать нужные компоненты из множества существующих. Все зависит от тог
, к чему вы стремитесь, – нет решения, которое подошло бы всем. В этой главе мы рассматриваем фундаментальные проблемы, с которыми может столкнуться любой.
Компромиссы
В процессе разработки архитектуры сайта часто возникает необходимость жертвовать одним ради другого, выбирать между сохранением информации о пользователях и масштабируемостью, между дублированием и простотой, между синхронностью и асинхронностью, между соединениями и их отсутствием, между скоростью разработки и тщательным планированием и, наконец, между процедурным и объектно-ориентированным программированием.
Сохранение информации и масштабируемость масштабируемость веб-сервер;информация о состояниивеб-сервер;масштабируемостьСам по себе веб-сайт неспособен сохранять информацию об индивидуальных пользователях в промежутках между веб-транзакциями. Пользователи таких сайтов не могут хранить на них никакой информации о себе. Сайт ничего не “помнит” о ваших предыдущих посещениях. Он отправляет вам запрошенную страницу независимо от того, запрашивали ли вы ее раньше, и независимо от того, с какой страницы вы на нее попали.
У таких веб-сайтов не бывает проблем с масштабируемостью. Сайты без сохранения состояния могут легко дублироватьсявеб-сайт;дублирование, что вместе с распределением нагрузки обеспечивает масштабирование даже в случае работы с динамическим содержимым (если, конечно, это содержимое допускает дублирование). Примером может являться сайт, на котором размещается информация о котировках акций или прогноз погоды. Поскольку функциональность всех веб-серверов одинакова, пользователь может без всяких проблем получить заглавную страницу сайта с одного сервера, затем щелкнуть ссылку на этой странице и получить другую страницу с другого сервера.
Совсем иначе обстоят дела на сервере транзакциймасштабируемость;транзакционных серверов, где необходимо сохранение информации о состоянии пользователей, например о входе и выходе из системы, о содержимом покупательской корзины или пользовательского счета. Необходимость сохранения информации о состоянии пользователей является источником большей части проблем с производительностью на сайтах с поддержкой транзакций, ограничивает масштабируемость скоростью получения и обновления информации о пользователях, заставляет серверы постоянно обмениваться этой информацией. Система записей представляет собой базу данных, в которую записываются транзакции, и неизбежно является узким местом. Существует несколько способов уклониться от конфликта между необходимостью сохранения информации о пользователях и необходимостью масштабирования сайтамасштабируемость;рекомендации.
- Храните сведения о состоянии в явном и компактном виде, например в одном файле cookie, чтобы состояние транзакции помещалось в один пакет.
- Не разделяйте сведений о состоянии между браузером, промежуточным сервером и базой данных, чтобы небольшие ошибки не приводили к огромному беспорядку.
- Обеспечьте атомарность операции записи состояния в систему записей и проверку успешности выполнения этой операции.
Уменьшение объема сведений о состоянии также весьма благоприятно влияет на производительность, поскольку меньший объем данных приходится записывать в базу данных или считывать из нее. Если вы планируете масштабирование сайта с поддержкой транзакций путем дублирования данных о состоянии между серверами, малый объем этих данных облегчит их дублирование.
синхронизацияРаспределение обработки данных о состоянии между несколькими процессорами потребует интенсивного обмена данными для синхронизации – как в случае с несколькими машинами в кластере, так и в случае с одной многопроцессорной машиной. В первом случае это затронет сетевое соединение между парами компьютеров, а во втором будет производиться синхронизация кэшей процессоров. В обоих случаях количество пар процессоров, нуждающихся в синхронизации, будет экспоненциально расти с ростом числа процессоров.
То же относится и к сотрудничеству людей. Чрезмерное увеличение числа работников в группе может привести к падению эффективности из-за роста затрат на общение (например, проведение деловых совещаний). Мне вспоминается один исполнительный директор, который утверждал, что лучший способ ускорить затормозившийся проект – это начать увольнять участвующих в нем сотрудников, поскольку чаще всего проекты тормозятся из-за слишком большого количества задействованного персонала. По-моему, он прав.
Дублирование и простота
Да, веб-сайты можно масштабировать, копируя данные с одного сервера на другой каждую ночьвеб-сайт;дублирование. Однако масштабирование через репликацию усложняет администрирование сайта, а чрезмерное усложнение для сайтов смертельно опасно. Гораздо проще реализовать схему с одним авторитетным источником данных.
С другой стороны, без репликации масштабируемость будет ограничена скоростью центрального источника данных, которым может являться, например, сервер NFS или реляционная база данных. Особенно сильно это ограничение действует при попытке записи в центральную базу данных, поскольку транзакции с базами данных должны удовлетворять так называемому ACIDACID, критерий-критерию (Atomicity, Consistency, Isolation, Durability – Атомарность, Непротиворечивость, Изоляция и Долговечность). Для обеспечения непротиворечивости (согласованности) и долговечности транзакции до ее начала необходимо заблокировать данные, с которыми вы собираетесь работать (это и будет изоляция). Это делается для того, чтобы никакой другой процесс не мог изменить и, возможно, разрушить данные в процессе транзакции, которая либо выполняется целиком до успешного завершения, либо полностью отклоняется (атомарность). Поскольку вы работаете с единственным набором данных и обращаетесь к ним строго последовательно, скорость выполнения транзакций будет ограничена тем, как быстро вы можете заблокировать, изменить и разблокировать данные в базе. Блокирование других процессов уменьшает производительность. Согласованность данных требует также синхронизации кэшей с системой записей. Долговечность означает, что данные сохраняются после перезагрузки компьютера. согласованность данныхЧасто забывают о том, что постоянная полная внутренняя согласованность базы данных не является обязательным требованием. Вполне допустима некоторая несогласованность, то есть противоречивость данных в течение некоторого промежутка времени. Это не приводит к слишком большому риску. Представим себе банк, у которого есть центральная база данных о состоянии счетов и кассовые терминалы с локальным кэшем. За один час с одного счета с одного терминала ATM можно снять не более 200 долларов, и при этом немедленного обращения к базе данных не произойдет: изменения будут кэшированы АТМ до конца часа. Это значительно ускоряет транзакцию с точки зрения пользователя. База данных синхронизируется в течение часа с момента транзакции, причем для этого могут использоваться более медленные (но и более дешевые) линии связи. Банк подвергается некоторому риску, потому что за один час пользователь может обойти много терминалов и снять с каждого по 200 долларов, но этот риск считается пренебрежимо малым по сравнению с выигрышем для пользователя и для банка, особенно если банк предъявляет какие-либо требования к минимальному остатку на счете. Служащие банка всегда знают, сколько денег было на каждом счете час назад, но про текущий момент они не могут сказать ничего. Это компромисс между временем ожидания для пользователя, риском для банка, стоимостью передачи информации и сложностью программирования. масштабируемость;кластеризацияВсе более популярной становится кластеризациякластеризация – объединение нескольких компьютеров в один более мощный. Масштабирование веб-сайтоввеб-сайт;кластеризация методом кластеризации также ограничено возможностями передачи сведений о состоянии между отдельными компьютерами кластера. По этой причине некоторые программные средства для кластеризации, такие как WebLogic, разделяют сведения о состоянии в любой конкретный момент лишь между двумя компьютерами кластера. При этом входящее подключение пользователя должно направляться на одну из двух машин, хранящих данные о нем, что усложняет схему. Такое решение иллюстрирует фразу Джеймса Гослинга о том, что решение проблемы обычно заключается в перемещении ее в другую часть системы.
Репликация медленно меняющихся данных обычно выполняется гораздо легче, чем репликация состояния одной конкретной транзакции. Существует множество готовых решений такой задачи – команды Unix rdistrdist, программа и rsyncrsync, программа, кэширующие прокси-серверы, программное обеспечение от компаний типа MarimbaMarimba, компания, а также коммерческие службы кэширования, такие как AkamaiAkamai, служба распространения данных и InktomiInktomi, служба распространения данных.
Синхронность и асинхронность
вызов;синхронныйСинхронные вызовы блокируются до возвращения результата. Большая часть веб-страниц заставляет вас бездельничать до тех пор, пока на экране не появится ответ на ваш запрос. Асинхронные вызовывызов;асинхронный возвращают управление немедленно. Некоторые асинхронные веб-страницы помещают ваш запрос в очередь, после чего немедленно отправляют вам сообщение о том, что ответ будет выдан позже (возможно, отправлен вам по электронной почте). Все зависит от того, готовы ли вы ждать в бездействии до получения ответа или же хотите заняться другими делами.
Другой пример синхронного вызова – запрос к базе данных JDBC, блокирующий вызвавший его программный поток до получения результата. При этом масштабируемость ограничивается скоростью базы данных. Если у вас в какой-то момент появится больше запросов, чем потоков, все потоки окажутся заблокированы, и сайт перестанет обслуживать пользователей. С другой стороны, асинхронные системы работы с сообщениями, такие как TibcoTibco, система передачи сообщений и MQMQ, система передачи сообщений, дают вам возможность отправлять сообщение с запросом и заниматься чем-то другим.
Зачем же вообще нужны в таком случае синхронные вызовы? Они обладают тем преимуществом, что вы узнаете результат вызова до продолжения работы. При асинхронном вызове сообщение об ошибке может быть доставлено существенно позже либо не доставлено вовсе. Синхронные вызовы использовать проще, поскольку они не требуют отдельной обработки результатов.
Связь без логического соединения
соединение;логическоеПротоколы без логического соединения не требуют поддержания соединения в промежутках между запросами. Протокол HTTP использует логические соединения TCP, но для очередного запроса не обязательно использовать то же соединение, которое использовалось для предыдущего, поэтому его можно назвать протоколом без соединения.
Хотя HTTP неэффективен в том смысле, что для передачи небольших объемов данных этот протокол требует установки и завершения соединения по 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/
Основные рекомендации
- Помните о том, что иногда приходится идти на компромиссы.
- Планируя архитектуру, спросите себя: “Если я решу, что это меня не устраивает, смогу ли я легко сменить эту архитектуру на другую уже после реализации?”.
- Планируйте сайт с расчетом на будущее, а не так, чтобы он отвечал только вашим сиюминутным потребностям.