Efektywność wybranych implementacji środowiska corba


Platforma sprzętowa i programowa



Pobieranie 164.45 Kb.
Strona3/4
Data09.03.2018
Rozmiar164.45 Kb.
1   2   3   4

3.2 Platforma sprzętowa i programowa


Prowadzone testy są kontynuacją badań wykonanych dla firmy IONA, których celem było porównanie platformy Orbix 3.01 z Orbix 2000. Orbix 2000 jest całkowicie nową implementacją specyfikacji CORBA stworzoną jako środowisko w pełni modularne zbudowane w oparciu o architekturę IONA ART (Adaptive Runtime Technology) [4]. Tę samą architekturę wykorzystuje implementacja Orbix 2000 dla języka Java, co uzasadnia przeprowadzenie testów porównawczych dla obu tych środowisk. Wszystkie powyższe implementacje IONA są produktami komercyjnymi, celowe więc wydawało się porównanie tych produktów z implementacją dostępną darmowo. Podsumowując, podczas testów wykorzystywano następujące implementacje specyfikacji CORBA:

  • Orbix 3.01 z odwzorowaniem IDL do C++,

  • Orbix 2000 wersja 1.21 z odwzorowaniem IDL do C++,

  • Orbix 2000 wersja 2.0 beta z odwzorowaniem IDL do języka Java,

  • CORBA zawarta w środowisku JDK 1.4.

Porównaniu podlegać więc będą dwie implementacje CORBA z odwzorowaniem IDL do C++ i dwie z odwzorowaniem do języka Java.

Do testów wybrane zostały trzy komputery oznaczane w dalszej części artykułu jako ,  i  należące do tej samej lokalnej sieci komputerowej, lecz różniące się architekturą sprzętową i programową. Pozwoliło to zbadać wpływ uwarunkowań systemowych na efektywność poszczególnych implementacji. Opis parametrów tych komputerów znajduje się w tabeli 1.



Tabela 1. Opis parametrów komputerów wykorzystywanych podczas testów

Symbol komputera

Typ komputera

Procesor(y)

Wielkość pamięci RAM

Sterownik sieciowy

System operacyjny

MTU interfejsu loopback [B]



Sun Enterprise 3000

3 x UltraSPARC 400 MHz

1,5 GB

Eth 100 Mb/s

Solaris 2.8

8232



Sun Ultra 1

1 x UltraSPARC 140 MHz

64 MB

Eth 10 Mb/s

Solaris 2.8

8232



Sun Ultra 1

1 x UltraSPARC 140 MHz

64 MB

Eth 10 Mb/s

Solaris 2.7

8232

Konfiguracja komputera  wyposażonego w starszą wersję systemu operacyjnego (Solaris 2.7) nie pozwoliła na uruchomienie środowiska Orbix 2000 ani w wersji C++, ani Java; na maszynie tej testowane więc były tylko Orbix 3.01 oraz implementacja pochodząca z JDK 1.4. Otrzymano w ten sposób 26 różnych konfiguracji sprzętowo-programowych pracujących w homogenicznym środowisku CORBA. Przykładowo dla implementacji Orbix 3.01 testowane były następujące konfiguracje sprzętowe: , , , , , , , , , gdzie pierwszy symbol oznacza komputer klienta, a drugi komputer serwera. Z badań wyłączono testy w środowiskach heterogenicznych – pomiędzy różnymi implementacjami specyfikacji CORBA – co znacząco ułatwiło analizę wyników.


3.3 Interfejs testowy


Testowy moduł IDL Benchmark opracowano w taki sposób, aby umożliwić zbadanie wydajności przesyłania możliwie szerokiej grupy typów. Znajdują się w nim definicje kilku podlegających przesyłaniu typów użytkownika – struktury, unii, interfejsu oraz sekwencji; fragmenty pliku benchmark.idl z ich definicjami przedstawione są w tabelach 2, 3, 4 i 5. Moduł definiuje ponadto trzy interfejsy z operacjami do transferu danych. Każdy z nich zawiera po cztery operacje służące do testowania danego typu; zmienna tego typu zawsze jest jedynym parametrem operacji, przykładowo:

  • void short_in_t(in short s);

przesłanie wartości typu short od klienta do serwera

  • void short_inout_t(inout short s);

przesłanie wartości typu short od klienta do serwera z możliwością jej zmiany w serwerze

  • void short_out_t(out short s);

przesłanie wartości typu short od serwera do klienta

  • short short_ret_t();

przesłanie wartości typu short od serwera do klienta jako wartości zwracanej operacji

T
enum discrim1 { e1, e2, e3 };
union u1

switch (discrim1)

{

case e1: short s;



case e2: long l;

case e3: char c;

};

interface I

{

void foo();



short bar (in short s);

double d ();

};
abela 2. Definicja unii u1 Tabela 3. Definicja interfejsu I


T
struct s2

{

short s;



long l;

long long ll;

unsigned short us;

unsigned long ul;

float f;

double d;

char c;

string st;



boolean b;

octet o;


any a;

};


typedef sequence ShortSeq_UB;

typedef sequence FloatSeq_64K;

typedef sequence StringSeq_UB;

typedef sequence OctetSeq_1M;

typedef sequence AnySeq_UB;
typedef sequence S2Seq_UB;
abela 4. Definicja struktury s2 Tabela 5. Definicja sekwencji

Poszczególne interfejsy zawierały operacje służące przesyłaniu zmiennych następujących typów:



  1. Interfejs BasicTester

    • Wbudowane typy proste CORBA takie jak: char, short, double, octet.

    • Typ łańcuchowy (string).

    • Typ Any.

  2. Interfejs UserTypeTester – struktura s2, unia u1 oraz interfejs I (tab. 2, 3, 4).

  3. Interfejs SequenceTester – sekwencje (tab. 5), zarówno o ograniczonej maksymalnej długości (ang. bounded) jak i nielimitowane składające się z elementów będących:

    • typami prostymi,

    • strukturami s2,

    • zmiennymi Any.

3.4 Metoda prowadzenia pomiarów


Wszystkie operacje z interfejsu IDL miały domyślny atrybut twoway, dzięki czemu możliwe było dokonywanie pomiaru po stronie klienta – bezpośrednio przed i bezpośrednio po wykonaniu operacji. Do pomiaru czasu wykorzystano standardową funkcję gettimeofday, która odmierza czas z dokładnością do 1 mikrosekundy. (W środowisku Java do wywołania jej niezbędne było skorzystanie z mechanizmu JNI). Sam czas dokonywania pomiaru nie zaburza wyniku, gdyż trwa około 1 s (a więc jest co najmniej trzy rzędy wielkości krótszy niż mierzone wartości) i w związku z tym został zaniedbany. Od wyniku pomiaru odejmowano – tam, gdzie to było możliwe – czas przetwarzania danych po stronie serwera. W celu zwiększenia jakości otrzymanych wyników każdy z testów powtarzany był 200 razy. Na etapie opracowywania wyników odrzucane były wartości znacznie przewyższające pozostałe rezultaty, których występowanie spowodowane było najczęściej chwilowymi zmianami obciążenia sieci lub serwerów.

4. Analiza wyników badań


Otrzymane wyniki pozwolą określić różnice w wydajności testowanych implementacji standardu CORBA. Istotne przy tym jest, że pomiary wykonywane były przy współpracy serwera z pojedynczym klientem w warunkach laboratoryjnych (tj. przy wyeliminowaniu możliwie szerokiej gamy czynników zakłócających pracę sieci oraz komputerów testowych). Pozwoliło to w dokładny sposób zbadać czasy wykonania operacji, z drugiej jednak strony, warunki pracy programów testujących odbiegały znacząco od warunków normalnej eksploatacji oprogramowania CORBA, przez co zostało pominięte wiele innych czynników mających wpływ na wydajność implementacji.

4.1 Wyniki uzyskane dla typów prostych


Rysunek 3 przedstawia wykres zależności czasu wykonania operacji (z atrybutem in) przesłania wartości typu short od zastosowanego środowiska i komputerów, na których pracował klient i serwer. Typ short wybrany został w opracowaniu jako reprezentant całej grupy typów prostych; wyniki dla pozostałych typów prostych były bardzo zbliżone. Zachowanie takie spowodowane jest przez podobną serializację typów prostych oraz zbliżony rozmiar danych nie przekraczający rozmiaru MTU ani dla interfejsu loopback, ani dla Ethernet.

Rys. 3. Czas wykonania operacji przesłania wartości (z atrybutem in) typu short w zależności od konfiguracji sprzętowej i programowej

Z przedstawionego rysunku można jednoznacznie stwierdzić, że wydajność implementacji środowiska CORBA dla języka C++ jest większa niż tych dla języka Java. Stosunek wydajności jest szczególnie duży przy wykonaniu połączenia wewnątrzmaszynowego (,  oraz ). Jest to spowodowane dużym obciążeniem maszyny generowanym przez dwa środowiska Javy pracujące jednocześnie. Efekt ten jest szczególnie zauważalny na komputerach  oraz , które są wyposażone w stosunkowo niewielkie zasoby. Wyjaśnienia wymaga również nieco gorsza wydajność komputera  w stosunku do . Jak wspomniano wcześniej, maszyna  wyposażona została w starszą wersję systemu operacyjnego, przez co niemożliwe było uruchomienie na niej środowisk Orbix 2000. Podczas testów na komputerze  uruchomiono mniejszą ilość serwerów, na skutek czego dostępnych było więcej zasobów pamięci i procesora. Rysunek 3 pokazuje więc także wpływ obciążenia generowanego przez środowiska CORBA na pracę systemu. W przypadku implementacji dla Javy mniejsza ilość zasobów spowodowała dość znaczne zmniejszenie wydajności (patrz  oraz  dla Java 1.4).




Pobieranie 164.45 Kb.

Share with your friends:
1   2   3   4




©operacji.org 2020
wyślij wiadomość

    Strona główna