Оптимизация сервера Web

Изощренное информационное наполнение делает узел Web привлекательным, но из-за него производительность узла может упасть до нуля. Наши советы помогут программистам держать узел в "хорошей форме".

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

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

Кроме того, данную задачу можно решить и своими силами с помощью таких продуктов, как SiteSweeper компании Site Technologies. Это программное обеспечение определяет объем файлов на вашем узле и время, которое требуется пользователю для их загрузки. Данная информация позволяет понять, насколько производительность сервера адекватна нагрузке. Приобретение продукта наподобие SiteSweeper менее обременительно для бюджета, чем профессиональные услуги по тестированию; с другой стороны, те, кто их предлагает, как правило, располагают сетью в пределах большого региона или даже страны, благодаря чему они могут протестировать производительность узла из нескольких пунктов.

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

ПРОИЗВОДИТЕЛЬНОСТЬ СЕТИ

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

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

Это далеко не единственный путь, например вы можете применять продукты для анализа интенсивности использования (таких как Accrue Insight компании Accrue Software или net.Analysis Pro 3.0, предлагаемый net.Genesis), которые позволят выявить ресурсы узла, к которым чаще всего обращаются; эти данные могут послужить, в свою очередь, основой для определения среднего размера файла. (Инструменты для анализа интенсивности использования будут подробнее рассмотрены ниже.) SiteSweeper, определяющий размер и продолжительность загрузки страницы, - тоже хорошее средство получения такой информации.

Установив средний размер файла, передаваемый при типичном запросе к серверу Web, следует сравнить его с цифрами, приведенными в Таблице 1. Эти данные позволяют определить максимальное число запросов HTTP в секунду, которые соединение с Internet способно поддерживать при таком размере файла. Так, например, тот, кто располагает соединением Т-1 (1,544 Мбит/с) и пересылает файлы размером около 10 Кбайт, может рассчитывать на обработку до 18,7 запросов HTTP в секунду. При среднем размере файла 100 Кбайт соединение Т-1 сможет поддерживать до 1,8 запроса в секунду. Следует иметь в виду, что в Таблице приведено максимальное число обслуживаемых запросов, и фактическая производительность всегда оказывается несколько ниже.

ТАБЛИЦА 1 - МАКСИМАЛЬНОЕ ЧИСЛО HTTP-ОПЕРАЦИЙ В СЕКУНДУ

Сотрудник компании StarNine Technologies Луис Слотульбер предложил свой подход к данной проблеме. Его модель производительности сервера Web учитывает все стандартные переменные, описывающие производительность, - пропускную способность сети, размер файла, время отклика и т. д. Кроме того, он использует несколько сценариев для определения факторов, влияющих на производительность сервера Web. Ввиду того, что большинство серверов Web находится в сетях Ethernet со скоростью 10 Мбит/с и имеют выход в Internet по соединениям Т-1 (1,544 Мбит/с), неудивительно, что именно соединения с Internet становятся тем злополучным бутылочным горлышком, в которое никто не может пролезть. Так, модель Слотульбера демонстрирует, что общая производительность узла Web уменьшается экспотенциально с ростом размера файла. Например, увеличение среднего размера файла с 5 Кбайт до 80 Кбайт приводит к падению производительности на 94% - от 35 обращений в секунду до двух. Короче говоря, если вы хотите, чтобы узел Web имел адекватную производительность, следует обращать внимание не только на емкость соединения с Internet и производительность сервера, но и на передаваемое по сети информационное наполнение.

Естественным побуждением любого, кто обнаруживает, что сетевое соединение тормозит работу Web, - модернизировать это соединение до следующего уровня. Однако не стоит спешить с этим дорогостоящим мероприятием. Поинтересуйтесь сначала у своего провайдера Internet, сколько промежуточных узлов отделяет ваш сервер от главной магистрали. Может статься, что соединение Т-1 предоставлено службой Local ISP некоего Криса, который, в свою очередь, арендует свои линии у Regional ISP некоего Боба, а тот - у Eastern ISP неведомой Сюзи. И это еще не последний этап - Сюзи пользуется услугами BBN Planet. Иными словами, запрос, адресованный вашему серверу, проходит еще через четыре промежуточных узла, любые проблемы с производительностью которых влияют на производительность вашего узла.

Если доступ в Internet предоставляется небольшим провайдером, неспособным удовлетворить ваших требований к пропускной способности, рассмотрите возможность обратиться к услугам более крупной организации, которая гораздо "ближе" к главной магистрали. Возможно, услуги этого провайдера обойдутся дороже, однако лучшая производительность и меньшая вероятность сбоев стоят денег. Модернизация соединения с Internet оправдана только в том случае, если оно (соединение) тормозит работу даже при пользовании услугами первичного провайдера.

ПРОИЗВОДИТЕЛЬНОСТЬ КОМПЬЮТЕРА

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

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

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

Те, кто использует в качестве сервера Web платформу Windows NT, могут извлечь массу информации об его производительности, а также производительности сети с помощью NT Performance Monitor. В меню Start, в левом нижнем углу экрана, надо выбрать опцию Run. Наберите perfmon в диалоговом окне и нажмите Enter. Открывшаяся консоль Performance Monitor позволяет просматривать многочисленные переменные в различных категориях, таких как Browser, Cache, Memory, Server, Processes, Threads, Processor и Disk Access. В целом Performance Monitor представляет исчерпывающую картину работы системы.

Компания BGS Systems предлагает Best/1 Visualizer для NT. Этот инструмент не только осуществляет мониторинг производительности систем Web на базе Windows NT, но и предупреждает о потенциальных и указывает на причины возникших проблем. С помощью этого инструмента можно определить время отклика и загрузку машины, работающей в качестве сервера Web, а также оценить эффект от установки более быстрой машины или добавления дополнительной памяти. Компания BGS предлагает и Best/1 Visualizer для UNIX-систем, которые легко интегрируются с такими популярными системами управления сетью для UNIX, как SunNet Manager, OpenView от HP и TME 10 компании Tivoli.

Если в качестве платформы сервера Web выбрана ОС UNIX, увеличить его производительность можно несколькими способами. Группа участников проекта Apache Web HTTP Server Project (www.apache.org), целью которого стало создание и свободное распространение серверов HTTP, уже предложила целый ряд ориентированных на конкретные платформы приемов, позволяющих настроить ядро UNIX в целях обеспечения лучшего обслуживания TCP. Общие решения состоят в увеличении числа процессоров, а также максимального количества открытых соединений с системой. Если машина сильно загружена (т. е. обрабатывает более чем несколько обращений в секунду), любое из этих действий способно привести к существенному скачку производительности. Кроме того, вы можете попытаться воспользоваться известными "заплатками" для данной конкретной операционной системы UNIX. Некоторые из этих "заплаток" могут повысить производительность системы, к примеру, за счет увеличения числа соединений в очереди или путем изменения способа обработки сетевых запросов.

ПРОИЗВОДИТЕЛЬНОСТЬ СЕРВЕРА

Выбор правильной серверной платформы имеет решающее значение для создания высокопроизводительного узла Web. При определенных условиях некоторые платформы серверов Web работают лучше. Компания WebCompare провела сравнение производительности различных платформ; его можно найти в Internet по адресу: www.webcompare.internet.com. Этот узел содержит сведения о работе всех доступных серверов Web и предоставляет информацию об их производительности, в том числе сравнительную таблицу по серверам.

Как правило, мониторинг производительности сервера осуществляется посредством выборочной проверки. Администратор запускает браузер и проверяет, насколько быстро загружаются страницы сервера. Как нетрудно представить, этот подход не дает точного значения производительности. Часто оказывается, что либо запрошенные страницы находятся в кэше браузера, либо между браузером и сервером располагается proxy-сервер. И то и другое создает впечатление высокой производительности. Кроме того, скорость обработки запроса одного пользователя не имеет ничего общего с производительностью при обработке 100 одновременных запросов. Так, например, один пользователь находится в том же сегменте сети, что и узел Web, и страницы обрабатываются со скоростью, обеспечиваемой Ethernet (10 Мбит/с), другой же - подсоединен по более медленному соединению типа линии T-1. Показатель производительности узла Web напрямую зависит от того, оценивает ее тот пользователь, который работает в локальной сети со скоростью 10 Мбит/с, или тот, который располагает лишь предоставленным основным провайдером Internet соединением по телефонной линии со скоростью 28,8 Кбит/с.

Для определения производительности имеющейся платформы требуется тестовый инструмент, такой как SQA LoadTest компании Rational Software. При помощи этого инструмента можно проверить все аспекты запроса ресурсов браузером для Windows NT с серверов на платформе Windows или UNIX. В числе этих ресурсов - апплеты Java, JavaScript, модули расширения браузера, выполняющиеся как на клиенте, так и на Web-сервере. Благодаря LoadTest вы можете произвести тестирование нескольких машин. Определив тестовую последовательность один раз, тестирование без труда можно повторять всякий раз при изменении тех или иных аспектов работы сервера Web. Это позволит немедленно оценить эффективность действий по повышению производительности.

Компания Radview Software предлагает аналогичный продукт тестирования нагрузки под названием WebLoad. Он позволяет измерять производительность сервера Web с большого числа клиентских станций на платформах Windows и UNIX. Этот продукт может определить производительность узла при работе с 500 посетителями одновременно, а также оценить, сколько пользователей могут в одно и то же время использовать апплеты Java. С помощью одной машины WebLoad генерирует до 8,2 млн обращений к узлу в день. Если помножить это значение на два или три (по числу машин, участвующих в тестировании производительности), можно получить достаточно обращений, чтобы создать "стрессовую ситуацию" даже для крупных комплексов серверов Web.

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

Распределить нагрузку позволяет, например, простая циклическая система DNS. При этом сценарии домены вашего сервера Web соотносятся со списком возможных IP-адресов. Приходящие запросы направляются по очереди на каждый адрес, так что задействованными оказываются все зеркальные серверы. Однако этого может оказаться недостаточно для выхода из кризиса производительности. Есть другой подход - динамическое перенаправление URL; при этом основной сервер Web обслуживает все входящие запросы, но перенаправляет браузер на другой URL (или даже на другой сервер Web). Основной недостаток обоих подходов в том, что они не учитывают статуса серверов-зеркал. Если какой-либо из них неисправен или работает недостаточно быстро, то DNS или основной сервер Web не знают об этом и продолжают посылать запросы на неработающий сервер.

Существуют несколько коммерческих продуктов, устраняющих этот недостаток. Один из лучших - аппаратное решение Equalizer компании Coyote Point Systems - представляет собой маршрутизатор распределения нагрузки, перенаправляющий входящие запросы на любое количество серверов. Оно рассчитано не только на HTTP-запросы, но и на шифрованные соединения SSL, а также ftp, SMTP и протоколы обмена сообщениями IMAP и POP. Основанный на Web интерфейс администрирования позволяет создавать виртуальные кластеры серверов с общим IP-адресом. Из каждого кластера серверыможно на лету добавлять или удалять в случае возникновения неожиданных ситуаций. Кроме того, Equalizer определяет сбои серверов и немедленно компенсирует их, перенаправляя трафик на действующие системы. Лучшая в семействе модель E350 поддерживает до 2 млн активных соединений; она пригодна для самых крупных узлов Web.

Подобно Equalizer, ПО LocalDirector компании Cisco Systems представляет собой маршрутизатор распределения нагрузки. Он поддерживает меньший трафик (только 700 000 активных соединений одновременно), но обеспечивает постоянную доступность в случае возникновения критической ситуации, когда происходит сбой одного из модулей LocalDirector. Кабельная линия между двумя модулями гарантирует, что при сбое одного из них другой возьмет на себя выполнение его функций автоматически. LocalDirector поддерживает HTTP, gopher и POP, а также трафик электронной почты.

Обрабатывает ли узел Web большой объем международного трафика? (Установить это можно при помощи средств анализа использования.) Если да, то стоит рассмотреть вопрос об установке зеркал как можно дальше от основного сервера - так, чтобы они обслуживали местный трафик в своих регионах. Вы можете либо договориться с компанией, предоставляющей хосты Web, либо разместить машину с сервером у местного провайдера. Таким образом ускоряется доступ к узлу для пользователей отдаленных регионов, поскольку им не придется "добираться" до сервера через несколько транзитных узлов. Некоторые крупные узлы Web предлагают карту серверов на своей домашней странице, дабы пользователи могли выбрать ближайший к себе сервер.

ОПТИМИЗАЦИЯ ИНФОРМАЦИОННОГО НАПОЛНЕНИЯ

Итак, если соединение с Internet работает нормально, производительность компьютера и сервера достаточна, самое время подумать об информационном наполнении. Как видно из модели Слотульбера работы сервера Web, объем информационного наполнения может существенно повлиять на производительность узла.

Определить, как информационное наполнение влияет на производительность сервера, позволяют средства анализа использования программного обеспечения типа Accrue Insight компании Accrue Software или net.Analysis Pro 3.0, предлагаемый net.Genesis. Эти средства помогают понять, не только как работает узел Web, но и как его используют посетители. Изучая последовательность нажатия посетителями клавиш мыши при навигации по узлу, вы можете определить, как оптимизировать информационное наполнение и с точки зрения внешнего вида, и в интересах производительности.

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

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

Но даже если заголовки с рекламой служат необходимым дополнением к узлу, то не ссылайтесь хотя бы на страницы с рекламой на других узлах Web. Все проблемы в сети между местным сервером и сервером с рекламой вам неподконтрольны. Рекламу нужно хранить локально либо применять имеющиеся в продаже продукты, наподобие WebBanner компании CGICity, позволяющие чередовать рекламу на месте.

Постарайтесь также пользоваться как можно меньшими изображениями, "экономные" форматы графических файлов, например JPEG вместо GIF, будут как нельзя кстати. Согласно модели Слотульбера, более высокая производительность достигается за счет уменьшения размеров файлов. Разбивая большие карты изображений на более мелкие фрагменты, легко добиться быстрой загрузки страниц даже при напряженном трафике. Дополнительное преимущество небольших файлов состоит в том, что при возникновении проблем с каким-либо изображением все остальные можно тем не менее получить.

ОСТАВАЙТЕСЬ НА КОНЕ

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