I don't have any comprehensive ways to test components involved in between
client/network/ADSM. But will try test to find out the maximum each
component can perform and then eliminate bottleneck when they come
together.

The followings are just bits and pieces that might give you ideas but may
not draw a concrete conslusion. I have done tests on SQL-BT around 2 years
ago, hope what I can recall is accurate.

There is dry-run mode in SQL-BT, I think this read the disks and output to
/dev/null on client (not sure if it involves ADSM API). If you are
interested in SQL-BT compression, check the effect by turning on/off SQL-BT
compression. Dry-run with compression off probably tells you the disk read
performance and compression on tells you CPU performance of the client.

The next is network, you can test it by ftp large files from ADSM server to
client or vice versa. This involves disk read and write in additional to
network performance, but at least give you idea on network performance. Or
there should be programs to test network performance, eg to xmit data from
machineA's memory to machineB's memory. But you need to source it. Or you
can arrange a sniffer to monitor the network.

I think there is dry-run for restore in SQL-BT, probably you can test
reading from ADSM tapes, sending over network then to /dev/null of client.
This eliminate bottleneck from client's disk.

To test writing to tape drive, try backup large files on ADSM server via
sharememory.
Or do a unix dd form disk to /dev/null (to measure the disk read
performance) then dd from disk to tape drive to measure the difference.

Finally ADSM db/log and parm in dsmserv.opt & dsm.sys do also affect
performance... etc. and you need to spend time to test.

Thanks.

Regards,
Eric Tang