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

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

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

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

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


Rambler's Top100

  

Исследуем производительность JDBC-интерфейсов

Барри Нэнс

При использовании мини-приложений Java доступ к базам данных (БД) вашей сети в ряде случаев может замедлиться. В статье проанализированы причины этого явления и даны советы по их устранению.

Когда вы работаете с Java-приложениями, возникает проблема снижения производительности, на решение которой зачастую тратится много сверхурочных часов. Эта проблема нередко проявляется в той части Java-программ, которая взаимодействует с базами данных. Элегантный и полезный в работе язык Java лаконичен, его код "прозрачен" для программистов. Кроме того, он обладает свойством повторного использования объектов и интегрируется с технологиями Интернет и интрасетей. Однако снижение производительности вызывает озабоченность разработчиков приложений.

Благодаря компиляции во время исполнения (JIT), оптимизации, а также наличию средств аппаратной поддержки производительность приложений языка Java со временем должна улучшиться. Для пользовательского интерфейса при вводе данных, когда компьютер с запущенной на нем виртуальной Java-машиной (Java Virtual Machine - JVM) работает значительно быстрее самого пользователя, производительность Java-приложения вполне отвечает предъявляемым ей требованиям. Но что в этом случае можно сказать о скорости доступа к БД? Как "переключить" Java на более "высокую передачу", при которой программам необходимо выбирать или сохранять строки таблицы в системе управления реляционной БД?

Тестирование Java-программ

Мы исследовали производительность Java-интерфейсов при работе с базами данных на примере небольшой сети Ethernet. Она состояла из ПК с ОС MS Windows NT Server и ПО Internet Information Server 3.0, пятнадцати клиентских ПК с Windows 95 и портативного ПК с анализатором протоколов Sniffer фирмы Network General, который осуществлял мониторинг сетевого трафика и загрузки оборудования, а в это время наше ПО выдавало SQL-запросы операторы через интерфейс JDBC. Мы испытывали базы данных Oracle, IBM DB2 и Microsoft SQL Server. Для разработки своего ПО нами использовался пакет Java Developer's Kit 1.1 фирмы Sun Microsystems. Нам необходимо было выяснить, насколько большой трафик генерируется приложениями JDBC (оказалось, что не очень большой), почему Java-приложение "замедляется" (мы были не первыми, кто обнаружил это) и как ведут себя "под нагрузкой" драйверы JDBC различных производителей. В результате проделанной работы нам удалось обнаружить наилучший, на наш взгляд, способ решения проблемы производительности JDBC.

JDBC - интерфейс программирования приложений (API) на уровне вызовов, разработанный фирмой Sun для использования операторов SQL в Java-программах. Первоначально он был реализован в виде отдельного набора классов для загрузки в программу, написанную на языке Java. В феврале с. г. фирма Sun выпустила упомянутый выше JDK версии 1.1 - инструментальный набор для разработки программ на этом языке, где JDBC уже включен в его базовые функций.

Уровни JDBC

JDBC добавляет к исполняющей среде Java ряд модулей: файл класса (class file), менеджер драйвера и сам драйвер JDBC. Существует четыре типа драйверов JDBC. Тип 1 - это шлюз между JDBC и интерфейсом Open Database Connectivity (ODBC). Тип 2, являющийся совокупностью машинного и Java-кодов, использует интерфейс конкретной реляционной базы данных. Тип 3 написан исключительно на языке Java. Для пересылки SQL-запроса по сети в нем задействован "нейтральный" по отношению к производителю СУБД протокол, а доставка SQL-запроса серверу БД осуществляется уже средствами программного интерфейса конкретной СУБД. И наконец, тип 4 - это также чистый, на все 100%, Java-код, но для доставки SQL-запроса серверу БД здесь применяется зависящий от конкретной СУБД протокол.

Драйверы типа 1 - самые медленные, в то время как драйверы типа 2 - самые быстрые. Драйверы типа 3 в силу своих небольших размеров загружаются быстро, но запросы исполняют медленнее, чем драйверы типа 2. Эффективность драйверов типа 4 ниже эффективности драйверов типа 2.

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

Во время выполнения мини-приложения Java JDBC загружает центральный процессор (ЦП) по мере того, как осуществляются преобразование и передача данных от одного интерфейса к другому. Однако для драйвера типа 4 дополнительных преобразований данных не требуется, поскольку он использует "родной" протокол СУБД. При применении драйверов JDBC типов 3 и 4, полностью написанных на языке Java, возникают самые большие потери производительности. Тем не менее для уменьшения загрузки ЦП драйверы типа 4 могут использовать собственный протокол СУБД.

В процессе доступа к БД посредством JDBC (мы проводили серию сеансов), когда все 15 клиентов нашей испытательной сети запускались одновременно, мы собирали статистику с помощью ПО Sniffer. Обнаружилось, что в данном случае тип драйвера не влияет на производительность. Средняя загруженность сети была низкой, поэтому мы сделали вывод, что самым узким местом для JDBC (как и для Java) является не производительность сети, а скорость работы ЦП. В ходе сеансов доступа к БД размеры сообщений с данными в сетевом канале обычно были незначительными. Как показал эксперимент, это происходило благодаря оптимальной структуре нашей тестовой БД: таблица содержала большое число строк и всего несколько столбцов.

Предложенный компанией Intersolv шлюз между JDBC и ODBC, который фирма Sun намеревалась использовать как промежуточное решение до тех пор, пока производители СУБД не разработают свои собственные драйверы, значительно увеличил время доступа к БД(в два раза по сравнению с драйверами типа 4). Это происходило в основном из-за преобразований, которые должны были выполняться шлюзом. Например, одна из функций шлюза между JDBC и ODBC - конвертирование типов данных Java в формат ODBC. Все типы данных имеют одно и тоже представление и одни и те же идентификаторы, за исключением форматов даты и времени. В Java идентификатор типа "время" имеет значение 93, а в ODBC - 11. Вы можете сами убедиться в этом, используя для представления значений типов данных каждого ODBC-вызова DriverManager.setLogStream. (Но сначала убедитесь, что режим logging выключен. В противном случае шлюз будет записывать на диск большой объем информации о прохождении запроса и тем самым замедлит процесс.)

Мы пришли к выводу, что шлюз между JDBC и ODBC обеспечивает соединение с большинством промышленных баз данных, так как практически каждая из них снабжена интерфейсом ODBC, но в то же время значительно замедляет доступ через JDBC. Если производитель вашей БД предоставляет вам драйвер JDBC, которым этот шлюз не используется, то мы советуем вам работать именно с ним.

Драйверы JDBC

Список производителей, продающих (или распространяющих бесплатно) драйверы JDBC, растет. И, чтобы справиться с ограничениями мини-приложений Java по безопасности (мини-приложение не осуществляет запись в локальную файловую систему, а только открывает сетевое соединение с хост-машиной, с которой оно было загружено, и не исполняет аппаратно-зависимый код), они (производители) при разработке драйверов JDBC достигли известной степени изобретательности. Как уже говорилось, почти все производители снабжают свои БД ODBC-интерфейсом (если вы не возражаете против использования шлюза между JDBC и ODBC), но существуют и другие подходы (более высокого уровня) для реализации соединения с сервером БД, в которых предусматривается использование сервера-посредника, запущенного на той же машине, что и Web-сервер. В спецификацию JDK 1.1 поддержка интерфейса JDBC включена как функция ядра, поэтому браузеры, совместимые с JDK 1.1, могут запускать мини-приложения и соединяться с БД без использования серверов-посредников.

Небольшие по размеру и достаточно быстрые драйверы JDBC фирмы OpenLink Software (размер файла класса - около 45 Кбайт) соединяются с модулем агента БД OpenLink с помощью так называемого "брокера запроса". Во время инициализации мини-приложения менеджер драйвера, используя унифицированный локатор ресурса, который оно ему предоставляет, загружает соответствующий драйвер JDBC. Затем ПО фирмы OpenLink запрашивает службу агента JDBC через сообщение к брокеру запроса OpenLink, обычно запускаемого на Web-сервере.

Брокер запроса, применяющий правила из списка правил Session Rules Book фирмы OpenLink, запускает или повторно использует агент JDBC. Он также связывает модуль агента БД с запросившим соединение агентом JDBC. Для увеличения производительности OpenLink разработала технологию Logical Message Assembly (LMA) с оптимизированным протоколом транспортного уровня. LMA быстро разбивает большие запросы на небольшие сообщения ЛВС и так же быстро "собирает" их в узле получения.

Фирма DataRamp предлагает решение, основанное на использовании сервера-посредника ODBC, который базируется на программном интерфейсе socket и поставляет услуги ODBC удаленным клиентам. Характерно, что при этом клиент запускает драйвер ODBC фирмы DataRamp вместе со своим драйвером JDBC. В основном данный процесс аналогичен процессу использования шлюза между JDBC и ODBC, с той лишь разницей, что здесь вместо протокола, поставляемого производителем, используется протокол обработки данных фирмы DataRamp.

Продукт jdbcKona/T3 фирмы WebLogic является драйвером JDBC и включает в себя ПО T3Server и T3Client фирмы WebLogic. ПО T3Server - это Java-приложение, которое вы запускаете на вашем Web-сервере и с которым могут связаться мини-приложения Java. T3Server работает как сервер-посредник JDBC и "от имени" мини-приложений устанавливает JDBC-соединения с промышленными БД. ПО T3Client, будучи "чистым" Java-продуктом, запускает мини-приложение и создает объект свойств с пользовательским номером ID, паролем, именем сервера и другими данными. Для поиска и сохранения строк таблицы БД мини-приложение также может использовать прикладной программный интерфейс JDBC.

Драйвер jdbcCONNECT (тип 4) фирмы Sybase поставляется с приложением сервера-посредника, написанным на языке Java, и запускается на к Web-сервере. Подобно продукту WebLogic, этот драйвер работает как шлюз между серверами Web и БД. Шлюз Java устанавливает соединение с хост-машиной БД, используя для этого протокол промежуточного ПО фирмы Sybase, а само мини-приложение в соответствии с ограничениями по безопасности поддерживает соединение только с хостом загрузки.

Продукт JetConnect фирмы XDB Systems является сервером-посредником на базе ODBC-стандарта. В следующую его версию фирма XDB планирует включить поддержку JDBC. Пока же JetConnect предлагает полную функциональную поддержку ODBC для Java-программ, используя при этом собственную библиотеку классов, представляющую собой расширенный интерфейс ODBC, куда включены скроллинг и связывание таблиц БД по строкам и столбцам.

Продукт dbANYWHERE фирмы Symantec обеспечивает доступ к БД посредством двух различных API-интерфейсов - стандартного интерфейса JDBC и нового API dbANYWHERE, который, по словам представителей фирмы Symantec, является более мощным, чем JDBC. Для работы вы выбираете наиболее подходящий для вашего приложения API. dbANYWHERE обеспечивает неограниченное число соединений клиента с БД Microsoft Access и Sybase SQL Anywhere и поставляется с собственным ODBC-драйвером, а также с драйверами для БД Microsoft SQL Server, Sybase и Oracle.

Повышение быстродействия JDBC

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

В реляционных БД и драйверах JDBC должна быть предусмотрена возможность управлять деблокированием множества строк, полученных в одном ответном сообщении. Предположим, что в результирующем наборе содержится таблица, состоящая из 20 строк; процесс построчной пересылки такой таблицы будет происходить медленно. Было бы неплохо, если бы в БД имелась возможность для пересылки множества строк в одном ответе, а у драйвера JDBC - способность построчной передачи таблицы приложению посредством деблокирования строк ответа. В настоящее время за одну передачу драйверы JDBC получают от СУРБД по сети только одну строку.

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

Лучшее решение мы припасли напоследок. Поскольку Java-приложения (и интерфейсы JDBC) связаны средой интерпретатора виртуальной Java-машины, то, по нашему мнению, лучший способ ускорить их работу (включая мини-приложения) - использовать хранимые (stored) процедуры, которые запускаются прямо на компьютере сервера БД. Хранимые процедуры создаются на расширенном диалекте SQL выбранного вами производителя БД, например языком хранимых процедур для Oracle является PL/SQL.

"Разгрузка" Java-программ в части доступа к БД может способствовать достижению их более высокой производительности, но она имеет также и другие преимущества. Так, с точки зрения безопасности метод хранимых процедур позволяет вам отменять право прямой модификации данных - вы должны только дать разрешение на использование соответствующих процедур. "Оборотной стороной" этого подхода является "привязывание" вашего приложения к конкретной СУРБД. Если для каждого нового проекта вам необходимо иметь возможность выбора БД, то метод с использованием хранимых процедур может оказаться неподходящим для вас.

Интерфейс JDBC очень хорошо использовать для поддержки хранимых процедур. С помощью простых операторов JDBC, например таких, как call <procedure_name> [parameter1, parameter2, ...], можно обрабатывать и обновлять строки и данные таблиц БД и передавать их Java-программе. Сегодня большинство промышленных БД позволяют компилировать хранимые процедуры в пакеты, откуда вы их можете вызвать. Такие откомпилированные пакеты процедур часто работают быстрее своих Java-эквивалентов.

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





  
11 '1997
СОДЕРЖАНИЕ

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

• Нарушитель конвенции

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

• Коннектор - "узкое" место кабельной системы

• Коммутируемый Ethernet или разделяемый Fast Ethernet

• Когда не помогает хороший пинок

• Волоконно-оптический кабель - что это и зачем он нужен

• Удаленная загрузка - ваша "палочка-выручалочка"

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

• IP-коммутация: сражение за сетевые высоты

• Надоедливый "писк"

• Связующее ПО: на сцене статисты

• Качество обслуживания, или Как добиться неравенства в мире равноправия

• Системы управления уровня рабочей группы

• Грядет РИФ'98...

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

• Услуги цифровой связи E1

• Рефлектометры для медных кабелей

• Телефонные гарнитуры: в серьезном бизнесе нет мелочей

• Технологии доступа. Делайте ваши ставки

• Руководство покупателя модемов формата Pc Card

интернет и интрасети

• Интернет для среднего офиса

• Мультимедиа в Интернет

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

• Реальные системы для виртуальных коммутируемых частных сетей

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

• Три новинки Lucent Technologies, Парад новинок от HP, Что нам стоит сеть построить..., Быстрый и многофункциональный коммутатор от 3Com

только на сервере

• Интернет от... IBM

• Фирменное ПО управления сетевыми устройствами

• Исследуем производительность JDBC - интерфейсов

• В поисках унифицированной почтовой архитектуры



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