Hi, Tim: The network traffic of the db server is 15-20Mbit/Second, not MB/Second. Sorry for the confusion. We are running 100Based LAN between application server and database server. Actully as I said in earlier posts, we upgraded two db servers. The other one which has cpu upgrade from 12*400MHZ to 8*900MHZ does have less application response time after upgrade. Average response time for typical service dropped 30-50 percent. But applications running on this server does not. The typical application response increased for about 5%. This seems strange. We really cannot explain to boss. Thanks Zhu Chao. ----- Original Message ----- From: "Tim Gorman" <tim@xxxxxxxxxxxxx> To: <oracle-l@xxxxxxxxxxxxx> Sent: Friday, April 30, 2004 6:12 PM Subject: Re: CPU upgrade caused application slow down > Zhu Chao, > > Sustained rates of 15-20 Mbytes/sec is absolute network saturation if you'r= > e > running 100BaseT - don=B9t forget that 100 Mbits/sec is 12.5 Mbytes/sec. Eve= > n > if the network segment closest to the server is GigE, you might have a > network segment somewhere in the mix running at 100BaseT, perhaps? > > Cary's remarks aren't theory, of course. Making one component of the stack > of technology much faster will almost certainly cause a bottleneck in > another component. Think of a 10-mile (16 km) roadway where the first 6 > miles (10 km) are expanded to 4 lanes while the remainder is left at 2 > lanes. That was the situation in my hometown (Evergreen, Colorado) some > years ago -- guess whether the roadway expansion helped improve traffic flo= > w > or caused massive backups where the lanes reduced from 4 to 2...? > > Just some thoughts... > > -Tim > > > > 1.. According to Cary Millsap=A1=AFs theory, upgrade CPU *CAN* make performan= > ce > > worse. In his case, SQL*Net was the bottleneck. Our server network traffi= > c is > > only at 15-20Mb/Second. This seems not like the bottleneck, Though from 1= > 0046 > > trace report, sqlnet wait is the NO.1 wait event, but this is normal for = > most > > applications. I also tried to change the tnsnames.ora and listener.ora w= > ith > > larger SDU/TDU of 8KB, restarted tuxedo service and oracle listener. And > > compare the performance data leter. This does not make much difference fo= > r > > application response time. > >=20 > > 2.. We did some pure simple SQL test. Result in appendix 1. SAME SQL in > > 1200MHZ CPU does run faster. > >=20 > > 2.. We write a simple tuxedo service run the same SQL for 1000 times. > > Everytime the SQL is transferred through SQL*Net and result is fetched in= > to > > host variable. The result still shows that it runs faster on 1200MHZ CPU.= > The > > average response time in 1200MHZ server is 12.12ms ,and the average respo= > nse > > time in 900mhz server is 14.20ms. > > ---------------------------------------------------------------- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > ---------------------------------------------------------------- > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > put 'unsubscribe' in the subject line. > -- > Archives are at //www.freelists.org/archives/oracle-l/ > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > ----------------------------------------------------------------- > > ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------