Some are not pleased with the performance of
> of the VM server and the question has been raised as to whether it would
> be better to run the server under MVS, or on a dedicated RS/6000. Can
> some of you reading this list share first-hand experience in comparing
> the performance of ADSM servers on different platforms,
> [...]
> - Are there any advantages to running the server under MVS instead of VM?
> The VM server doesn't take advantage of CMS multitasking as far as I know.
The VM server *requires* CMS multitasking. That's what the
requirement for DMSSVM is. I haven't noticed a real difference in
server performance between VM and MVS servers _on similar
hardware_. In most cases, heavy MVS shops tend to have more
sophisticated hardware (multipath cached DASD controllers, 3390s
vs 3380s, etc) for MVS due to MVS's heavier demands for
resources. In that case, the MVS code is somewhat faster because
the underlying hardware is better.
The VM TCP/IP implementation is quite a bit faster, though
(compared with MVS TCP 2.1, anyway). Percieved speed is heaviily
dependent on the design and engineering of your network, though.
Have you looked at the number of ring purges and token delay
times with a promiscuous mode monitor? You may also want to look
very hard at the number of ICMP redirects and any routing
functions being performed by your TCP server and interface; VM
TCP is a good host implementation, but it (like most shared
systems) makes a lousy router.
> - How does the performance of the server on an RS/6000 compare with the VM
> server? Some ADSM functions are fairly disk I/O intensive. Can the
> RS/6000 server with SCSI disks handle the load as well as the VM server
> with 3390s?
Database processing on the RS/6K is the major bottleneck; expires
can take a very, very long time (in one case, I hit over 12 hours
on a smaller RS/6K with a long retention period and large number
of backup copies). You also want to plan for a larger disk
staging area (potentially on a separate SCSI bus) for good
performance. The multipath support in the 3990 wins big.
> What about 8mm cartridge drives vs. 3490 drives? If we
> put ADSM on an RS/6000, would we need to get 3490E drives for it, or would
> 8mm drives be fast enough?
3490s win hands down. Even in streaming mode, the fastest 8mm
drives seldom exceed 750K/sec. A 3490 in streaming mode can
accept data at very close to full channel speed, roughly 4+ times
the maximum transfer rate of the 8mm drives. Consider the media
quality issue as well -- what happens when you develop a bad spot
in the middle of a 5G tape? 8mm tape isn't nearly as reliable as
3490 technology in that arena.
> - What kind of data rates do you see on backups between clients and various
> servers on a 16Mb token ring with TCP/IP?
170-200K/sec average using PC/TCP and IBM token-ring adapters.
> I realize that is heavily
> dependent on other factors such as network traffic, but does an RS/6000
> have an advantage here?
Only a small one; you don't have to go up and down the channel
for various things. The microcode for the RS/6K channel card
isn't as optimized as the 3172 ucode. You trade minor network
performance increase for slower 8mm tape access and database access.
You need a lot more staging disk on the RS/6K to compensate for
the slower tape access.
> TCP/IP transactions (e.g. pings) seem to take
> much longer to the VM system than to an RS/6000. Our VM system is
> connected to the LAN via a channel attached RS/6000, using the CLAW
> protocol. Our VM system also has very heavy SMTP activity and up to
> 165+ logon sessions via TELNET.
You may want to try setting up a separate TCP/IP virtual machine
for ADSM. Buy a used 8232 or a older 3172 and use it for ADSM
support; if you've got all your IP traffic going through one TCP
machine, that's probably what's killing your performance. Also
make sure you're running TCPIP in XA mode and give it at least
32M (or more -- up the small and large databuffer pools a lot;
ADSM eats them up quickly). Used 8232s or 3172-1s are going for
around $2-3K; I'd try that first -- it should buy you some
performance for your telnet users too.
|
