HP3000-L Archives

February 2008, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Thu, 7 Feb 2008 10:21:31 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
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 *

ATOM RSS1 RSS2