 |
|
|
|
| |
 к выбору публикации
|
|
|
Выбор аппаратной платформы для приложения Парус Корпорация 8.3
В публикации приводятся результаты тестирования различных аппаратных платформ, предназначенных для работы с приложением Парус Корпорация 8.3. Тестирование проводилось администратором сети пользователя, а взаимодействие с компанией ProLAN осуществлялось по схеме ТестАтелье. Полученные результаты, по нашему мнению, представляют интерес для широкого круга пользователей приложения Парус Корпорация 8.3, которых интересуют вопросы производительность работы данного приложения в сети.
|
 |
Цели, технология и логика тестирования
Крупная нефтегазовая компания, где активно используется приложения Парус Корпорация 8.3, обратилась к нам с просьбой помочь определить причину неудовлетворительного времени реакции данного приложения. Было принято решения начать диагностику в соответствии с организационной схемой ТестАтелье. Суть этой схемы заключается в следующем. Пользователь с использованием свободного пакета SelFTrend 4.x производит тестирование своей сетевой инфраструктуры и по электронной почте присылает полученные результаты в компанию ProLAN. Мы эти результаты декодируем, анализируем и говорим пользователю, что, с нашей точки зрения, нужно сделать для ускорения работы приложения.
В данном случае было принято решения в качестве критерия "здоровья" сетевой инфраструктуры использовать время выполнения SQL-запроса, который создаст сам пользователь. В промышленную сеть пользователя был установлен Зонд (компьютер, на котором выполняется программа SelFTrend), который измерял время выполнения созданного пользователем SQL-запроса. Текст этого запроса приводится в разделе "Информация об инфраструктуре". Одновременно с сервера снимались характеристики его работы (утилизация процессора, дисков и т.п. - всего более 20 параметров). Это тоже делал сам пользователь (администратор сети). Вся собранная информация присылалась в ProLAN, где импортировалась в базу данных и анализировалась программой Trend Analyst.
Обработав первую порцию присланных данных, мы увидели, что время выполнения SQL-запроса существенно колеблется в течение суток. Если ночью оно составляет 5 секунд, то в рабочие часы - около 20 секунд. Из этого мы сделали вывод, что в сети есть "узкое место", которое и является причиной ухудшения времени реакции системы. Выполнив корреляционный анализ характеристик работы сервера и времени выполнения SQL-запросов, мы увидели, что оно существенно зависит от утилизации жестких дисков сервера. На основании этого мы предположили, что именно производительность дискового контроллера является "узким местом" системы (или, по крайне мере, одним из них). Эта гипотеза совпала с внутренними ощущениями администратора сети, и он решил исследовать, как время выполнения интересующего его SQL-запроса зависит от аппаратной платформы сервера.
С этой целью, с помощью Зонда администратор сети измерял время выполнения одного и того же SQL-запроса при установке базы данных на различные серверные платформы. Все сервера устанавливались в одну и ту же точку локальной сети, при этом в качестве Зонда использовалась одна и та же рабочая станция. В двух случаях Зонд работал с "боевым" сервером, с которым одновременно работали пользователи приложения Парус Корпорация 8.3. В трех других случаях в локальную сеть устанавливался тестовый сервер с копией "боевой" базы данных и Зонд работал с тестовым сервером. Вы можете легко определить, какие сервера являются "боевыми" по длительности проведенных измерений. С боевыми серверами тестирование проводилось в течение длительного времени. С тестовыми серверами - несколько часов.
|
|
|
Полученные результаты
Полученные результаты приведены ниже и говорят сами за себя. Мы хотели бы сделать только одно пояснение. Анализируя таблицу 1, нужно обращать внимание, в первую очередь, на значение минимального времени выполнения SQL-запроса. Это связано с тем, что тестирование всех серверов проводилось в "боевой" сети и на время выполнения SQL-запросов влияла, также, и загрузка сети.
Таблица 1. Сравнительная таблица времени выполнения SQL-запросов при различных серверных платформах
|
Железо |
ОС |
СУБД |
|
Время выполнения SQL запроса (с) |
|
|
|
|
|
avg |
min |
max |
|
Compaq Proliant ML530 2xPIII-933, RAM 4Gb SDRAM 133, Smart Array 3200 controller, HDD 10x18Gb UIIISCSI, NIC E100B |
OS Solaris8x86 |
Oracle 8.1.7 |
7,55 |
4,76 |
32,84 |
|
HP NetServer 6000, CPU 4xPIII-750, RAM 2Gb, HDD 6x18Gb U2-SCSI, Raid Controller MegaRAID, NIC E100B |
OS Windows NT 4.0 Server + SP6a |
Oracle 8.0.6 for NT |
11,18 |
10,71 |
13,16 |
|
SunFire 280R CPU 2xUltraSparcIII-750MHz RAM 2Gb HDD 2x36Gb FC-AL (internal), 9x36Gb FC-AL RAID (RAID5) (external) не оптимизирован |
OS Solaris8 |
Oracle 8.1.7 |
6,83 |
6,79 |
6,89 |
|
SunFire 280R CPU 2xUltraSparcIII-750MHz RAM 2Gb HDD 2x36Gb FC-AL (internal), 9x36Gb FC-AL RAID (RAID5) (external) оптимизирован |
OS Solaris8 |
Oracle 8.1.7 |
4,69 |
4,63 |
6,38 |
|
Compaq Proliant ML530 2xPIII-933, RAM 4Gb SDRAM 133, Smart Array 5300 controller, HDD 10x18Gb UIIISCSI, NIC E100B |
OS Solaris8x86 |
Oracle 8.1.7 |
6,60 |
3,16 |
36,00 |
|
В заключение хотим отметить, что после замены оборудования на сервере работа приложения Парус Корпорация 8.3 заметно ускорилась. По словам администратора сети - "Теперь все летает".
А теперь загадка - догадайтесь, какое оборудование сервера поменял администратор сети?
|
 |
наверх
|
|
