1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
This application tests the redundancy feature of TAO's Naming Service.
To run all tests automatically -
execute Perl script run_test.pl
To run tests manually -
start the Naming Service (see
TAO/orbsvcs/Naming_Service/README for valid options),
then run ./client the optional options are shown below.
NOTE: if running tests manually, the NameService directory must exist
before starting the Naming Service and this directory must be cleaned out
manually after stopping the Naming Service.
The following options exist:
---------------------------
-b Breath of Context tree, default is 4, minimum is 2
-d Depth of Context tree, default is 4, minimum is 2
-o Breath of Object tree, default is 4, minimum is 2
-p ior for Naming Server 1
-q ior for Naming Server 2
The client creates two context trees, one of breath b and one of depth d,
and another node with o objects. It then removes the contexts b-1, d and
the object o-1. All these are done using the first name server. The
client then accesses contexts b, b-1, d, d-1, and objects o, o-1 looking
for the appropriate found/not-found returns using the second name server.
Example (on a Unix system):
$ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -o nsior1\
-r NameService -ORBEndPoint iiop://localhost:10001 &
$ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -o nsior2\
-r NameService -ORBEndPoint iiop://localhost:10002 &
$ ./client -p file://nsior1 -q file://nsior2
where the steps correspond to 1&2)starting the Naming Service
in redundant mode, 3) running the client.
Don't forget to kill the name servers after you are done.
EXPECTED OUTPUT FOR THIS TEST
*****************************
Redundancy test OK.
The default test runs in a few seconds. (4 on my 500MHz Linux)
*****************************
Restrictions, performance notes, and future
While the redundant naming service is only fully function on Tru64
clusters, it can be used on any two systems that share a file system
with locking. However, this test puts the two naming servers on the
local system doesn't test the locking (probablistic to do, at best)
and runs the client on the same system. This will specifically test
only the functionality of the redundancy. The extra parameters can
be used manually to probe performance, as illustrated below.
Using the b,d, and o options, I determined:
As the number of objects in a single context increases, performance
decreases. This is because of I/O limits, each addition of a new
object reference adds about 1/2 KB and rewrites the whole file. I
observed 9746 objects added to a single context in 100 minutes and
noted that the disk light was on solid.
As the number of contexts increase, the CPU became the limiting factor.
2000 contexts under the root context took 20 minutes.
As the depth of the contexts increases, the limit becomes the file
system. As the number of contexts, equivalent to files, passed 12000,
the system slowed to a crawl. The first 12000 took about 5 minutes, the
next 15 minutes only got another 2000. Process CPU was very low, less
than 5 %. Disk activity was high, but not contiguous, lot of head motion
not seen in the single context above.
Future enhancement of this service should address these performance
limits. One obvious enhancement is to use IPC between the redundant
Naming Servers to reduce the dependence on the disk, then a lazy update
of the disk can be done. Would take a lot of code, but doable.
|
