Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

SQL Server 6.0: взаимодействие клиента с сервером

Брюс Робертсон

В настоящей статье приводятся результаты тестирования, проведенного с помощью сетевого анализатора Sniffer фирмы Network General, работы продукта DB-Library сервера SQL Server 6.0 (версия 4.21 исследовалась нами ранее), установленного на компьютере-клиенте под управлением операционных систем Windows for Workgroups 3.11, Windows NT 3.51 и Windows 95.

Особенно хотелось бы отметить более производительную и эффективную работу новой версии, а также появление в продукте библиотеки Multi-Protocol Net-Library, использующей механизм вызова удаленных процедур (Remote Procedure Call - RPC) фирмы Microsoft. Этот механизм соответствует описываемому в спецификации среды распределенных вычислений (Distributed Computing Enviroment - DCE).

Шифрование

При использовании продукта DB-Library 6.0 (как и его предшественника) мы смогли прочитать передаваемые по сети имя и пароль пользователя в случае применения в качестве средств межпроцессного взаимодействия гнезд (socket) протоколов TCP\IP и IPX\SPX. Сервер SQL Server 6.0 поддерживает режим интегрированной безопасности (integrated security) доменных каталогов Windows NT, и поэтому клиенты, задействующие либо механизм именованных каналов Named Pipes (дополнительно требуется программа redirector фирмы Microsoft), либо библиотеку Multi-Protocol Net-Library, могут выполнять процедуру аутентификации через домен Windows NT. А это означает - пароль клиента не передается по сети. Заметим, что хотя библиотека Multi-Protocol Net-Library и является соответствующей спецификации DCE реализацией механизма вызова удаленных процедур, она не использует служб каталогов и аутентификации DCE.

Средства Multi-Protocol Net-Library позволяют также шифровать передаваемые данные по алгоритму RC4, применимому при вызове удаленных процедур системы Windows NT. На сервере администратор может заставить использовать шифрование данных для всех соединений с клиентами; на клиенте каждый пользователь сам решает, когда ему необходимо шифрование. В 32-разрядной системе Windows это происходит путем внесения изменений в соответствующий реестр (registry), а в 16-разрядной - в файл WIN.INI.

Использование шифрования в нашем случае сильно не повлияло на производительность системы (она уменьшалась лишь на 10%). Однако, скорее всего, оно вызовет существенное снижение производительности при менее быстродействующем аппаратном оборудовании клиента и более загруженном сервере.

Производительность

Чтобы проверить, с какой скоростью передаются данные между клиентом и сервером SQL Server 6.0, мы использовали сетевой анализатор Sniffer. Поскольку он не "умеет" декодировать применяемый в DB-Library протокол, мы могли получать картину происходящего только наблюдая за передаваемыми в пакетах данными в ASCII- и шестнадцатиричном представлениях.

Задействование тех или иных библиотек Net-Library и протоколов в принципе, может сильно повлиять на результаты, но в наших тестах, проводимых на незагруженной сети Ethernet, оно не вызвали значительного разброса производительности. При использовании различных библиотек Net-Library и под управлением системы Windows NT 3.51 клиент сервера SQL Server 6.0 оказался на 20% быстрее, чем клиент SQL Server 4.21а. Под управлением Windows for Workgroup и тот, и другой показали практически одинаковую скорость вне зависимости от того, применялись ли вызовы удаленных процедур или обычный режим работы. Для Windows 95 не существует клиента сервера SQL Server 4.21а. Протоколы TCP/IP были самыми эффективными и обеспечили максимальную производительность.

Также как и библиотека Named Pipes Net-Library, новая библиотека Multi-Protocol Net-Library может функционировать с различными механизмами межпроцессного взаимодействия: именованными каналами, гнездами SPX и гнездами TCP\IP. Мы протестировали все три варианта, а кроме того, режим, при котором именованные каналы использовались над протоколами TCP\IP. Применение на 32-разрядном клиенте механизма вызовов удаленных процедур привело к 30%-ному снижению производительности, по сравнению с непосредственным задействием механизма межпроцессного взаимодействия. На клиенте под управлением Windows for Workgroup изменение производительности оказалось незначительным. Видимо, это связано с более медленной, 16-разрядной, операционной системой.

Таким образом при развертывании большинства сетевых СУБД SQL Server задействование именованных каналов в качестве механизма межпроцессного взаимодействия, похоже, больше не является необходимым. Почему? Потому, что библиотека RPC Net-Library тоже обеспечивает режим интегрированной безопасности, но, в отличие от именованных каналов, добавляет к нему возможность шифрования данных. Кроме того, работа с именованными каналами требует программы redirector на каждом клиенте. Следовательно, если вы не собираетесь шифровать данные и не нуждаетесь в интегрированной безопасности, вам есть смысл использовать обычный режим, в противном случае - вызовы удаленных процедур.

Оказалось, что 32-разрядные операционные системы значительно более быстрые, чем 16-разрядные: наш тестовый запрос выполнялся в 2,5-5 раз быстрее в зависимости от различных сетевых соединений. Таким образом, операционная система клиента играет в подобных системах значительную роль.

Эффективность эксплуатации сети

Некоторые изменения, внесенные в версию 4.21, нацелены на то, чтобы DB-Library 6.0 обеспечивала значительное повышение производительности системы при работе в медленных и сильно загруженных сетях. В основном, это должно происходить за счет более эффективного задействования сети. DB-Library 6.0 способна использовать меньшее (по сравнению с версией 4.21а) число пакетов для выполнения аналогичной работы (она заполняет кадры Ethernet по максимуму). Также DB-Library 6.0 и поддерживает оконный (window 1) режим, не требующий подтверждения приема каждого посланного низлежащим протоколом транспортного уровня пакета информации, что позволяет избежать эффекта "пинг-понга", обычного для соединений по протоколу SPX. При использовании протоколов TCP\IP оконный режим мог быть реализован уже в версии 4.21а.

В версии 4.21а только библиотека Net-Library гнезд TCP\IP позволяла заполнить кадр Ethernet пользовательской информацией по максимуму (1514 байт). Теперь и гнезда TCP\IP, и гнезда SPX, и именованные каналы (при работе над TCP\IP), и вызовы удаленных процедур (при работе над всеми другими протоколами) способны максимально заполнять пользовательской информацией кадры Ethernet. Однако при использовании упомянутых механизмов полный кадр формируется, только если приложение запрашивает достаточный для этого размер пакета протокола Tabular Data Stream (TDS).

В SQL Server 6.0 параметры сетевого пакета, применяемые по умолчанию, могут быть установлены для всех серверов и клиентов, но клиентские приложения иногда игнорирует эту установку. Размер пакета по умолчанию равен 4096 байт, что значительно больше, чем в версии 4.21а (512 байт). Таким образом, DB-Library передает блоки данных размером 4096 байт библиотеке Net-Library, которая старается полностью заполнить кадр Ethernet перед его отправкой. Благодаря этому эффективному способу значительно снижается общее число кадров, необходимых для передачи информации от сервера клиенту, при различных механизмах межпроцессного взаимодействия, поддерживаемых Net-Library. Наши тесты показали уменьшение числа кадров примерно с 600 (для SPX и RPC) и 1200 (для именованных каналов) до 200 кадров в большинстве случаев.

Используя утилиту ISQL/w фирмы Microsoft на клиенте под управлением 16- и 32-разрядных систем Windows, мы так и не смогли добиться, чтобы размер пакета составил 4096 байт. ISQL/w не запрашивает у сервера установленный по умолчанию размер пакета и применяет свой собственный - 512 байт. Работающая в символьном режиме утилита ISQL (существует для Windows NT и Windows 95) по крайней мере, позволяет назначать размер пакета вручную. Задав его 4096 байт, мы дали возможность клиентам Windows NT и Windows 95 заполнить кадры Ethernet полезной нагрузкой полностью (1460 байт). Подобной утилиты для 16-разрядной Windows не поставляется, поэтому в этом случае мы были бессильны.

Версии SPX

В нарисованной нами радужной картине полного заполнения кадров Ethernet есть один изъян. При использовании механизма гнезд SPX или вызовов удаленных процедур над SPX, библиотеки Net-Library ограничивали размер кадра Ethernet в наших тестах до 594 байт. Оказалось, что сервер был сконфигурирован для работы файловой и принтерной службы NetWare (File and Print Service for NetWare) фирмы Microsoft, а это требовало от него наличия сетевого адреса NetWare, необходимо при межсетевых взаимодействиях. Поэтому клиент думал, что SQL Server расположен в другой сети NetWare, хотя на самом деле он находился в том же физическом сегменте Ethernet.

Библиотеки SPX Net-Library фирмы Microsoft применяют более раннюю реализацию интерфейса транспортного уровня, SPX I, которая автоматически уменьшает размер пакета для его успешного прохождения через несколько сетей. Этим и объясняется столь маленький размер кадра - менее 600 байт в нашем случае. Соединения SPX I позволяют формировать кадр размером 1514 байт, только если SQL Server находится в одном сегменте с клиентом (как вы помните, в наших тестах именно так и было, но клиент не смог этого распознать), а всякий раз, когда трафик должен пройти через маршрутизатор трафика протокола IPX, формируется кадр меньшего размера. Поэтому для повышения производительности при работе в больших сетях рекомендуется интерфейс SPX II.

Только библиотека Multi-Protocol Net-Library фактически поддерживает интерфейс SPX II, реализующий и оконный режим, и режим формирования больших пакетов при межсетевом взаимодействии (Large Internet Packet). Когда в системе Windows NT были использованы вызовы удаленных процедур поверх протокола SPX мы добились передачи серверу кадров размером 1514 байт. К сожалению, наши надежды на то, что Multi-Protocol Net-Library задействует интерфейс SPX II на всех платформах, не оправдались. Мы так и не смогли пересылать большие кадры при работе клиента под управлением систем Windows for Workgroups (более того, в этом случае мы вообще не сумели протестировать передачу пакетов размером 4096 байт) и Windows 95. В описании Windows 95 указано, что для поддержки интерфейса SPX II необходима библиотека TLI.DLL, но найти ее на диске CD-ROM с данной операционной системой нам не посчастливилось. Возможно, мы должны были получить ее от фирмы Novell, но Microsoft об этом нас не предупредила.

Вот так "сюрприз": Windows 95 нужна библиотека DLL фирмы Novell для поддержки интерфейса транспортного уровня SPX II. Подобных проблем нет в Windows NT, там поддержка SPX II встроена в драйвер NWLINK.

Протоколы TCP\IP оказались наиболее эффективными на всех платформах и, по-видимому, проявят себя еще лучше в сетях с большим временем передачи данных между узлами. Отрыв TCP\IP от других средств обеспечения транспортного сервиса не столь значителен в том случае, если последние позволяют формировать кадры Ethernet размером 1514 байт. Мы выяснили, что производительность не так сильно зависит от применяемых протоколов, как это было в предыдущих тестах. Следовательно, механизм вызовов удаленных процедур совместно с популярными транспортными средствами позволяет задействоватьпредоставляет новые полезные функциональные возможности, такие как шифрование и режим интегрированной безопасности без установки программы redirector на каждом клиенте. Вызовы удаленных процедур, используемые с протоколами TCP\IP, похоже, являются наилучшим средством связи между клиентом и сервером в SQL Server 6.0.


распечатать статью

Подключение городских телефонных номеров Тольятти toliatti.sipout.net.




  
1 '1996
СОДЕРЖАНИЕ

колонка редактора

• Говорит и показывает Интервидение

открытые системы

• Мир TCP/IP. Internet Protocol

• Пятая волна компьютеризации: открытые сети общего пользования

• DCE. Скорее жива, чем мертва?

• Ява - остров восходящего солнца

• Проблемы маршрутизации трафика в Internet

• Удаленный доступ по PPP

• Будущее мультимедиа в Internet

• Интеграция Unix и Windows NT средствами NFS

• Internet: каково же будущее?

корпоративные сети

• Переход к коммутируемым сетям

• Загадка маршрутизатора

• Мост над бурным потоком

• Технология управления распределенными сетями

локальные сети

• Дисковые массивы RAID типа SCSI-to-SCSI

• Ленточные системы с автоматической сменой кассет

• Сетевые адаптеры Ethernet для шины PCI

услуги сетей связи

• Системы низкоорбитальных спутников

• Кодирование речи в цифровой телефонии

• Архитектура и функциональные модули сетей SDH

приложения клиент-сервер

• Однопользовательские СУРБД

• SQL Server 6.0: взаимодействие клиента с сервером

• Комплексная автоматизация производства на основе систем SCADA

защита данных

• А в вашей сети живут драконы?

• Испытание антивирусных программ для NetWare

новые продукты

• RAID без компромиссов, Эмулятор SunPC для DOS и Windows, Коммутатор LinkSwitch 1000 фирмы 3Com, Маршрутизаторы 7500 фирмы Cisco, MultiNet for Windows фирмы TGV



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх