Re: Small TNS packages
Date: Tue, 24 Nov 2009 09:06:40 -0800 (PST)
On Nov 24, 7:09 am, Troels Arvin <tro..._at_arvin.dk> wrote:
> joel garry wrote:
> > Look up SDU and and SEND_BUF_SIZE (and related parameters) in the docs.
> Those are server-side parameters?
See the net services and administration guides, as well as metalink. The recv_buf_size is the client side of the send_buf_size. http://download.oracle.com/docs/cd/B19306_01/network.102/b14212/plan.htm#sthref616 says "You can deploy SDU at the client, the application Web server, and the database server."
> As a follow-up:
> The application uses JDBC. By using
> we experienced a dramatic speedup: Execution time was cut to 1/20
> (although TNS packet sizes had only increased by a factor 5, from around
> 400 to around 2000).
> Thanks to you and and Mladen, by the way.
You're welcome. Note the lesson here: You can usually get much greater performance improvement from fixing the app than tweaking parameters. Tune the app then tune the system if there is still a problem (assuming the system is not way out in left field, which is why a good methodology will rule out gross misconfiguration first - this has less importance than in the past, since defaults are mostly reasonable these days, if you follow directions and aren't doing anything strange). Fixing a wayward app often helps the rest of the system. And where do apps come from? That's why there are books like "Effective Oracle by Design."
The best performance comes from not doing unnecessary work. Here, the unnecessary work was in generating too many fetches. Is there more?
-- _at_home.com is bogus. http://www.signonsandiego.com/news/2009/nov/23/hp-profit-jumps-on-cost-cuts-new-market-expansion/Received on Tue Nov 24 2009 - 11:06:40 CST