cancel
Showing results for 
Search instead for 
Did you mean: 

CPU performance problem???

VaSC_LYN
Occasional Contributor

CPU performance problem???

Pls see the attached file for detail,thx your
reply in advance.
2 REPLIES
Hein van den Heuvel
Honored Contributor

Re: CPU performance problem???

Hi,

Just fyi, I like your idea of putting your very well formulated question in an attachment to preserve formatting of ascii graphis and tables. HOWEVER... my knee jerk reaction to this topic was "Ya right, and I'll scratch your back too". Others my feel similar, so might I suggest placing the basic query in the topic, and repeat it in its intended form in the text attachment?!

For the benefit of the other readers:

"I did a performance test for my applications.the topology is showing below. I have 2 servers,one is rp8420 with 16 CPU(1.0Ghz) and 32G Mem,the other is rx8640 with 16 CPU(1.6Ghz) and 32G Mem.The rp8420 and DB server are at same site,the rx8640 is at 20 miles away form them.I used Loadruner to do performance test,and got those results under same pressure at both sites.

Identical load:
Deals(times/5mins) CPU_UTIL(avg) SYS_MODE_UTIL(avg) USER_MODE_UTIL(avg)
rp8420 12380 90% 25% 65%
rx8640 9620 66% 28% 37%

With higher load:
SYS_MODE_UTIL(avg) USER_MODE_UTIL(avg)
rx8640 9620 91% 33% 58%

1:why rx8640 can't handle as many deals as rp8420 with same pressure(50vus)?
2:form test result1 we see rx8640 spent more cpu time on SYS_MODE_UTIL compared
rp8420,why?
Notes:I thought "USER_MODE_UTIL/SYS_MODE_UTIL=2~3" is best utilization.
3:for test result2 when I add more pressure(100vus) on rx8640,it didn't
beheave like my thought.the utilization of cpu was raised,but performance
for handling deals didn't grow?


A1) Because it is further away and does not have the network bandwith/response time it needs to do an optimal job?

What is the network speed for the RP vs the RX? What is the (ping) latency for each? 20 miles rounds trip is about 0.2 millisecond. Ergo, there is a maximum of 5,000 exchanges per second.. for 1 stream. But this is IF you have a direct wire. But is you just connect to 'the cloud' then the packets may well travel hundreds of miles.
Google for: network latency distance
You'll find much background reading. For example:
http://www.numion.com/Calculators/Distance.html


A2) I like to see even less system time (proportionally of course). This may well be a result of different timing/scheduling for the network traffic. Things like delayed acks, packet trains, affect the work on the network stack and influence process scheduling.

A3) If I am right in that the performance of the rx8640 was defined by the network, and not by the processing power of the box, then attempting to put more load on the box will only serve to make it more busy, more processes to deal with. More wasted scheduling time. Poorer caching characteristics.

Suggestions:

S1) How about running a test with a trimmed down load, perhaps 40vus (virtual users?), and see if it perform better (proportionately of course). It MAY actually even do more 'deals' and. My expectation is that it will show less cpu used and better sys/usr ratio .

S2) Somehow NETWORK ROUTE the RP traffice via the RX site for a test. yeah... no fair. It will have to go both ways, for (at least) 80 miles round trip.

If you can not set that up, then at least THROTTLE the RP connection to the RX connection speed. Maybe introduce a 10mb/sec bridge in the path for a test?

And uh... Proper testing is NOT trivial. The lack of details information about the network in the post suggests that your team is not entirely ready for the job. Involve a pro!

Regards,
Hein van den Heuvel ( at gmail dot com )
HvdH Performance Consulting

VaSC_LYN
Occasional Contributor

Re: CPU performance problem???

Hello,

thank u for your reply first.

1:the 2 sites have 30 miles away,connected by direct fc cables through 6 switches.

2:Does the network latency cause the worse sys/usr ratio(1-0.5)?

3:how to improve the sys/usr ratio?

4:I don't have the data of 40vus,we will do the test later.and give u the result.