Использование эмуляторов дистанционных терминалов

Оценить
(0 голоса)

RTE (Remote terminal emulators - эмуляторы дистанционных терминалов) - это прикладное программное обеспечение, подражающее реальным действиям пользователей обычно на персональных компьютерах, браузерах или ASCII-терминалах. Вместо поиска свободного аппаратного обеспечения и реальных пользователей для проведения испытания приложения проще использовать RTE. На рынке доступно некоторое количество изощренных продуктов (например, preVue от Rational). Эмулятор дистанционного терминала, не занимающего рук (HandsOff Remote Terminal Emulator), - текстового RTE - доступен на Web-странице книги для платформ SPARC и х86 Solaris. Становятся доступными также Web-эмуляторы, называемые Remote Browser Emulators (эмуляторы дистанционных браузеров).

Хотя RTE обычно используются для проведения сопоставительных испытаний, они также полезны для профилирования приложений при их разработке. Всегда лучше выявить "узкие места" до того, как приложение выйдет в свет. Профилирование приложения, или его характеристика, также используется для регрессивного тестирования (гарантирующего, что функциональные характеристики и производительность не ухудшились с выходом нового программного или аппаратного обеспечения). Самые большие приложения ERP (Enterprise Resource Planning - планирования ресурсов предприятия), например, от SAP и Peoplesoft, снабжены связанными с ними тестовыми наборами программ. Эти наборы чрезвычайно полезны при выявлении и фиксировании "узких мест" до того, как пользователи обнаружат их сами. К сожалению, многие важные приложения выходят в жизнь без проведения многопользовательского тестирования.

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

Далее подведены итоги по некоторым из приближенных подсчетов, представленных в этой главе.

•             Конфигурируйте на 30% больше дискового пространства, чем вам требуется. Этот дополнительный объем будет способствовать росту и гибкости при размещении данных.

•             Активность диска объемом 9 Гбайт при полном диапазоне подвода головок со скоростью вращения 7200 об/мин допускает около 75 IOPS с временами поиска около 30 миллисекунд и пропускной способностью около 8.5 Мбайт/сек. Диски нынешнего поколения объемом 32 Гбайт и с частотой вращения 10000 об/мин поддерживают свыше 100 IOPS и имеют пропускную способность от 12 до 20 Мбайт/сек, даже если используется весь объем диска. Эти оценки предполагают операции ввода/вывода небольшого размера (от 2 до 8 Кбайт).

•             Устройства хранения SPARCstorage Arrays могут поддерживать пропускную способность около 17 Мбайт/сек. StorEdge А5100 - около 90 Мбайт/сек в одном цикле. Массивы ТЗ - до 100 Мбайт/сек.

•             Единственная шина SBus способна поддерживать пропускную способность, составляющую приблизительно 110 Мбайт/сек.

•             Центральные процессоры UltraSPARC 400 МГц способны обрабатывать через БД около 30 Гбайт/сек, используя операции ввода/вывода размером 128 Кбайт и более.

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

•             Конфигурирование требуемого объема с использованием дисков емкостью 18 или 36 Гбайт обеспечит, вероятно, адекватную производительность и стоимость для большинства сред.

•             Планирование высокой готовности повышает требования к объему диска на 100% в случае конфигурации RAID 1 (зеркалирование) и на 25% в случае конфигурации 4+1 RAID 5.

•             Использование технологии клиент/сервер для отправки приложений в отдельные системы позволяет сократить требования к ЦП сервера БД на одну треть и даже наполовину. В случае SAP и других приложений ERP сокращение будет еще больше.

•             Допускается от 32 до 64 Мбайт для выполнения начальных требований к серверу БД.

•             Допускается от 32 до 64 Мбайт для начальных системных издержек операционной системы.

•             Для каждого пользователя на клиентской машине допускается от 2 до 4 Мбайт (и намного больше - от 10 до 16 Мбайт-для приложений ERP) и для каждого пользователя на сервере БД от 1 до 2 Мбайт для рабочих нагрузок OLTP, если недоступна другая информация. Добавьте эти требования, если используется конфигурация в режиме разделения времени.

•             Конфигурируйте память буферного кэша эквивалентной 5%-15% от размера вашей БД.

•             Избегайте использовать результаты тестирования ТРС при оценке размера системы.

Инструмент общего назначения для задания размеров OLTP
Подоплека
Введение метрик
Поиск упрощающих допущений
Накопление исходных данных

Добавить комментарий


Защитный код
Обновить