Just a thought...if it only seems to be your .NET apps that have any
noticeable performance issues are you separating the ODBC jobs, etc into
their own subsystem? Then you can adjust memory pools, etc just for those
jobs and focus on the direct issue vs using a light anti-tank weapon to
kill a mosquito?
Thanks,
Tommy Holden
From: Sam_L <lennon_s_j@xxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 06/04/2013 06:37 PM
Subject: Re: Cost of Activating Second Processor
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Kurt,
Do you have any metrics from before activating the second processor that
you will compare against?
If we get to test a second processor I'd want to have something better
than "it feels faster" or "doesn't seem to have made any difference". I
suppose maybe the elapsed time for our month-end process might be a good
benchmark, but if you have an approach that you can share...
It's not that we have a sluggish machine--compiles are still
satisfyingly fast, but some of our .NET apps that connect to the iSeries
seem to be taking longer to get going, and the boss sees that. Of
course, the network guys have virtualized all the Windows servers and
that might be something to do with it. But it is seems very difficult
to do any measurement on a mixed environment.
Sam
On 6/4/2013 4:44 PM, Anderson, Kurt wrote:
Hi Sam,
I don't have any answers for you, but we recently activated a second
processor and so far we haven't noticed any impact. I wasn't a part of
the decision to get the additional processor, but there must be a way to
get some metrics on your system to see if a second processor would provide
an ROI. Make sure you're up-to-date on PTFs. We're working on the PTF
thing (just about there) and the next step is that there are some reports
that can be ran that cost a couple hundred bucks (so I hear).
-Kurt
midrange.com
