No Title

Опыт сопровождения сервера.

Опыт сопровождения сервера выявил ряд проблем. Остановимся на следующих:
A. Производительность с точки зрения пользователя.
B. Множественность кодировок русского языка.
C. Представление, отображение математических выражений и поиск по формулам.
D. Поиск по документам, представленным на сервере.

A. Производительность WWW-технологии зависит от трех основных факторов.

1.

Производительность сервера. Ее определяют:

Аппаратура
- Центральный процессор
- Оперативная память
- Подсистема ввода/вывода
Используемая операционная система, инструментальное и прикладное программное обеспечение
Структура данных
Одновременно исполняемые приложения

2.

Пропускная способность сети зависит от:

Коммуникационных протоколов
Сетевых драйверов
Технических средств передачи: мостов, маршрутизаторов, кабелей и т.д.
Производительности Proxy и DNS - серверов

3.

Производительность клиента, складывающаяся из:

Производительности аппаратных средств
Качества программного обеспечения
Другой загрузки клиента

1. Временем загрузки HTML-страницы будем называть время, прошедшее с момента нажатия кнопки мыши на ссылке до завершения отображения HTML-страницы программой просмотра. В идеале, загрузка большинства WWW-страниц должна выполняться не более чем за 3 - 7 секунд.
Сервер с меньшим числом более производительных процессоров обеспечивает лучшее (меньшее) время реакции на единичный запрос пользователя по сравнению с многопроцессорным сервером, кластером или несколькими независимыми серверами при равном количестве запросов, обрабатываемых в единицу времени всей системой (время реакции распределенной системы, по различным оценкам, может быть в среднем в 3-4 раза больше). В случае многопроцессорной системы на основе общей оперативной памяти (SMP) это явление объясняется тем, что запрос пользователя обрабатывается обычным последовательным процессом. Параллельно может выполняться несколько таких процессов, обслуживающих различных пользователей. При выполнении планирования операционная система предоставляет первому в очереди активному процессу первый свободный процессор. Таким образом, когда общее число процессов меньше или равно количеству процессоров в системе, каждый процесс выполняется со скоростью обеспечиваемой одним процессором. Когда количество активных процессов превышает количество процессоров, производительность будет только меньше, за счет конкурирующих процессов. В случае системы с распределенной памятью результат может оказаться хуже из-за неравномерного распределения рабочей нагрузки между узлами обработки. Качественная диаграмма, представленная на рис.1, иллюстрирует этот эффект. Следует также учесть неодновременное и неравномерное поступление запросов. В случае большого числа слабо загруженных серверов (с небольшой частотой обращений) выгоднее объединить их на одном сервере (рис. 2).

$\begin{figure}\centering\includegraphics[width=5in]{dima1.ps}\end{figure}$

Рис. 1.

$\begin{figure}\centering\includegraphics[width=5in]{dima2.ps}\end{figure}$

Рис. 2.

При этом:

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

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

Существенным является объем оперативной памяти. Оперативная память большой емкости позволяет разместить данные непосредственно в ней (Data in memory), сократив время отклика за счет устранения ожидания данных от дисковой подсистемы.

Уменьшение различной обработки данных на сервере (например, такой как, перекодировка "на лету", получение алфавитного списка из базы данных и т.п.) так же сокращает время реакции. Так при обращении к страницам, генерируемым с помощью CGI-скриптов, требуется примерно в 2 раза больше оперативной памяти, а нагрузка на процессор увеличивается более чем в 5 раз, по сравнению с запросами простых HTML-страниц. С другой стороны хранение готовых HTML-страниц приводит к увеличению объемов хранимых данных. Принцип "хранить все, что возможно в готовом виде" при росте объемов хранимых данных приводит к неуправляемости системы. "Ручное" управление сервером становится крайне сложным. Требуются специальные программные средства для проверки корректности ссылок содержащихся в документах. Должны проверятся ссылки на другие документы как хранящиеся на том же сервере, так и хранимые на других серверах. Необходимо иметь средства поиска файлов, не связанных ни с какими документами (особенно файлов с изображениями). Для того, чтобы избежать подобной ситуации, следует, по-видимому, хранить данные в формате какой-нибудь СУБД, а часть стабильных HTML-страниц (алфавитные списки сотрудников института, списки по отделам, списки по титулам и т.п.) генерировать автоматически только в случае изменения данных, а не порождать их заново при каждом обращении пользователя к WWW-серверу.

2. Уменьшить время передачи по сети можно сократив объем передаваемой информации. Для этого следует свести к минимуму или вообще отказаться от применения сложных, многоцветных, больших графических элементов (если это невозможно - разбить их на несколько мелких) и таких средств как апплеты JAVA, Java-Script, VB- Script. Тем более, что время и труд, затраченные на их разработку, часто не соответствуют полученному результату.

3. Казалось бы, производительность на стороне клиента не является критичным параметром для просмотра HTML-страниц. Однако использование в качестве клиента более мощного компьютера при прочих равных условиях (например, замена i386 33 МГц. на i486 55 МГц., оба с 4 МБ памяти) показывает в 2-3 раза меньшее время ожидания полной загрузки страницы.

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

B. Различные кодировки кириллицы, применяемые на разных программно-аппаратных платформах, создают неудобства как для разработчиков серверов, так и для пользователей. Проблема множественности кодировок решается либо за счет предоставления информации серверами в различных кодировках, либо возможностью настройки программ просмотра на кодировку сервера, либо перекодирующими прокси - серверами. Каждое из этих решений имеет свои недостатки. Например, при автоматическом распознавании кодировки сервер не всегда верно определяет ее на стороне клиента. Переход по ссылке со страницы в одной кодировке может быть выполнен на страницу в другой кодировке, и промежуточная перекодировка сделает текст нечитаемым. В то же время хранение одних и тех же данных в различных кодировках требует значительно большего дискового пространства и усложняет процедуры сопровождения сервера. Простейшим решением в этом случае является поддержка содержимого сервера в одной кодировке с последующим автоматическим дублированием всех файлов в остальных кодировках (перекодировка). Введение единого стандарта на кодировку позволило бы радикально решить эту проблему. Наиболее перспективной, по-видимому, является двухбайтная кодировка UNICODE, охватывающая основные алфавиты, наборы условных знаков и имеющая резерв для символов, определяемых пользователем. Важное препятствие для ее внедрения - удвоение объема данных - сейчас можно считать несущественным из-за развития аппаратных средств.

C. Представление математических выражений и химических формул, нотной записи, других специальных и условных знаков в HTML-документах представляет собой гораздо более важную проблему, чем множественность кодировок кириллицы. К сожалению, в настоящее время имеется единственный универсальный способ их представления - преобразование в графический вид. Недостатки этого решения известны: рассогласование со шрифтами, используемыми различными программами просмотра, и при печати, а также больший объем передаваемой информации по сравнению с текстовым форматом. Использование кодировки UNICODE, имеющей в своем составе коды для математических символов и других условных знаков, существенно упрощает решение этой проблемы.

Проблему представления математических формул может решить широкое распространение технологии, основанной на языке Mathematical Markup Language (MathML), разработанной Math Working Group, куда входят представители компаний Adobe, Hewlett-Packard, IBM, Xerox PARC и SoftQuad.

D. В настоящее время WWW-сервер ИММ представляет собой набор HTML-страниц, связанных ссылками. С ростом объема информационного наполнения WWW- сервера становится необходимой организация встроенного механизма поиска, благодаря которому пользователи должны получить возможность проводить поиск по ключевым словам. Размещение средств поиска на самом сервере упрощает процесс доступа к информации, а также уменьшает число избыточных ссылок, получаемых в ответ на запрос, адресованный специальному поисковому серверу, благодаря тому, что различаются слова в зависимости от контекста. Например, на WWW-серверах IBM на каждой HTML-странице присутствует ссылка для обращения к механизму поиска.

Доступные нам бесплатные механизмы поиска не имеют целого ряда важных функций [1]:

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

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

Литература: [1] Роберт Ричардсон, Найди то, не знаю что, Lan Magazine/Журнал сетевых решений, (Март 1998, том 4, номер 3).

ИММ УрО РАН http://www.imm.intec.ru