TAO/performance-tests/RTCorba/Oneways/Reliable/README

   1
   2
   3 Server:
   4
   5 Type 'server' with no args. Server outputs its IOR
   6 to the screen for a sanity check.
   7
   8
   9 Client:
  10
  11 Type 'client' with one or more of the following args:
  12
  13 -k ior          -- input specific IOR.
  14 -s payload size -- size of payload if payload test is used.
  15 -p payload test -- use payload test.
  16 -t test type    -- runs only one type of oneway test.
  17 -i iterations   -- number of calls in each test.
  18 -l level        -- selects level at which SyncScope policy is set.
  19 -m buffer size  -- queue size for buffered oneways.
  20 -w servant work -- number of loops of 1000 done by servant
  21 -x              -- shuts down server after testing.
  22
  23 levels:
  24
  25 orb             -- sets SyncScope policy at the ORB level.
  26 thread          -- sets SyncScope policy at the thread level.
  27 object          -- sets SyncScope policy at the object level (default);
  28
  29 test types:
  30
  31 none            -- sets SyncScope policy value to SYNC_NONE.
  32 transport       -- sets SyncScope policy value to SYNC_WITH_TRANSPORT.
  33 server          -- sets SyncScope policy value to SYNC_WITH_SERVER.
  34 target          -- sets SyncScope policy value to SYNC_WITH_TARGET.
  35 twoway          -- makes regular twoway requests.
  36
  37 If the test type is 'none', request buffering is enabled, and
  38 a buffering constraint policy is created, based on the number of
  39 requests the queue should hold, as passed in the -m argument. If the
  40 test type is anything else, the -m argument is not used. To get
  41 reasonable results with buffered oneway requests, it's a good idea
  42 to make the number of iterations -i a multiple of the queue size -m.
  43 This will insure that there are no requests left in the queue to be
  44 sent when the tests are done with their timings. For buffered
  45 oneways, control is returned to the application as soon as the
  46 request is placed on the queue, or, if the queue is being flushed,
  47 as soon as all the requests are sent.
  48
  49 If the test type is 'transport', the oneway requests are handled the
  50 same way they have always been handled in TAO, that is, control is
  51 returned to the application when the request is handed off to the
  52 transport (usually TCP) layer.
  53
  54 If the test type is 'server', control is returned to the application
  55 after any servant locator is called, but before the servant
  56 executes the request. This will enable any location forwarding
  57 information to be returned to the client.
  58
  59 If the test type is 'target', the oneway request is handled as if
  60 it were a twoway request, i.e., control is returned to the
  61 application only after the servant has executed the request. Any
  62 system exceptions that may be raised will be sent back to the
  63 client.
  64
  65 If the test type is 'twoway', the tests will be run with standard
  66 twoways requests, in order to compare the data with the results
  67 from the various SyncScope policy values of oneway requests.
  68
  69 The -w option sets the number of empty loops of 1000 performed by
  70 the servant. To test the advantage of SYNC_WITH_SERVER over
  71 SYNC_WITH_TARGET and twoway requests, the servant must perform
  72 some 'significant' work that a oneway request with a SyncScope
  73 policy value of SYNC_WITH_SERVER does not wait on, while the
  74 other two types of requests mentioned above do.
  75
  76
  77 All the above command line options except -k, -s, -p and -x may be
  78 used with the perl script run_test.pl. If no test type is specified,
  79 the script will run each test type in turn before the server is shut
  80 down.
  81
  82 There is also a perl script called client_test.pl, which facilitates
  83 testing with the client and server on different machines. To use
  84 this script, first run the server manually, then run client_test.pl.
  85 With this script, the server will not shut down automatically.
  86
  87 There is code in the test to set the priorities of the client and
  88 server threads to values consistent with a real time priority
  89 class on Solaris and other Unix systems. If the user is not logged
  90 in as a superuser, a message will be output that the threads are
  91 running in a timesharing priority class.