Hi Brian :)
Ok... follow up question on what is driving the need to upgrade... is
there network hops involved? If so, has the network infrastructure been
reviewed?
I remember cases where the response time was fine at the 3k but the
network latency to the enduser out in "Egypt" was less than desirable due to
the circuits and limits in between...
Btw... anyone from Providence Health Services reading this?
Art "puttering away on the job hunt" Bahrs
P.S. I hope this makes it thru... last few attempts to post haven't seemed
to make it to the listserv?
=========================================
Art Bahrs, CISSP
[log in to unmask]
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of [log in to unmask]
Sent: Thursday, February 07, 2008 07:22
To: [log in to unmask]
Subject: Re: [HP3000-L] performance measurement
On Wed, 6 Feb 2008 19:04:16 GMT, [log in to unmask]
<[log in to unmask]> wrote:
>Thanks to those of you who sent a response. I already have the hardware in
my computer room, so I don't have any flexibility to look at anything other
than 979/200 or 400 (currently has 4 processors configured but I don't know
that we need that much more power than what the 200 can offer). The biggie
of course is how much Cognos will charge for the upgrade.
>The info that Craig provided was the direction I was looking for and the
cpu
bottleneck issue is something I will need to analyze. I've been a system
admin
for nearly 15 years and never had a good understanding how to interprete the
performance chart when upgrading (shame on me).
>Still looking for more input. Thanks again!
> Wes
You've mentioned that this is a Cognos based application. Is it mostly
online
(Quick screens), and/or are there many batch reports(Quiz) or updates(QTP)?
What's driving the need to upgrade?
Terminal response time?
Batch through-put?
Backup processing time?
If you're currently having large batch backlogs, or the batch processes you
have 'take too long' - having more 'width' (more CPU's) can help out quite a
bit, especially if you could run more than 1 job at a time w/o locking
and/or IO
contention issues. More CPU's also gives you more 'headroom' for growth.
Terminal based CPU use easily 'spreads' accross multiple CPU's, so as long
as
response-time issues aren't disk IO or memory shortage based, more CPU's
help.
I've had cases on systems I've worked on where having a multiple CPU system
actually helped my client's application continue to run w/o apparent
performance degradation to their users - even though one processor had
failed. This allowed scheduling a maintenance event, rather than taking the
entire box down immediately.
If this is a 'home grown' application, your programmers/analysts/consultants
that are responsible for it can help identify what the bottlenecks currently
are,
and how much you'd benefit from the additional 'horsepower' that more CPUs
can give. If it's a vendor application, their support dept, or other
'application'
experts (consultants) could help in this determination.
Of course, nothing beats the hard data that a good monitoring tool (Glance,
etc) can give you - both before, and after an upgrade. While it's true that
performance tuning may still be an 'art', with good data - at least you know
how big your canvas is, and how much of what colors are available on your
palette.
And because I don't recall anyone explicitly stated it yet: YMMV. ;-)
Brian Edminster
Applied Technologies
P.O. Box 234
Germantown, MD, 20875-0234 USA
"Open Source Software by Applied Technologies
- Solutions for Today, Solutions for Tomorrow"
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
