Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: analyzing slow connections

Re: analyzing slow connections

From: Ed Stevens <nospam_at_noway.nohow>
Date: Tue, 05 Aug 2003 15:10:19 -0500
Message-ID: <pm30jv46ucd6k9ogq1vqaitsfmbc16l37r@4ax.com>


Brian,

At this point I still don't know what they are doing, but I'll add this to my list. Thx.

On Tue, 5 Aug 2003 14:12:20 GMT, Brian Peasland <dba_at_remove_spam.peasland.com> wrote:

>Since this is a web app, have you looked at connection pooling? Most
>application servers support this sort of thing nowadays. You can have
>the app server make the connections once the app server starts. The
>connections are persistent and stay around for use by your end users.
>This can essentially eliminate your connection time. Connection pooling
>and other similar methods all vary depending on your platform so you'll
>have to read your docs to get more information.
>
>HTH,
>Brian
>
>Ed Stevens wrote:
>>
>> comments embedded
>>
>> On 5 Aug 2003 01:14:50 -0700, vslabs_at_onwe.co.za (Billy Verreynne)
>> wrote:
>>
>> >Ed Stevens <nospam_at_noway.nohow> wrote
>> >>
>> >> I've been given a head's-up that a project is being put together to
>> >> figure out why an app is experiencing delays in connecting/starting
>> >> up. Mostly will be looking at application code and tracing network
>> >> issues (this being done by the network and server admins) but there
>> >> will be some attention to Oracle itself. Notice that once the app is
>> >> up and started they seem to be happy -- it's just statup/connect
>> >> delays that are of concern. With that in mind, what should I be
>> >> looking at, and what should I be prepared for?
>> >
>> >What app? Custom, off-the-shelve, vendor? What platform does it run
>> >on? What constitutes "slow connection times"? What language is it
>> >written in? (contrary to popular believe, nor men or programming
>> >languages are created as equals)
>> >
>> Custom web app, using a variety of components and probably languages.
>> I was given the database a couple of years ago after it was in
>> production, and have to do nothing with it since except stop/start it
>> for planned data center outages.
>>
>> (As for all men created as equals, it has been observed by ice
>> fishermen relieving themselves behind their ice shacks that, in cold
>> weather, all men *are* created equal!)
>>
>> >
>> >Simple example. Windows app. Uses 10 different input forms and 20
>> >report forms.
>> >
>> >The no-brainer programmer will construct all 30 forms upon startup.
>> >This will have a SERIOUS impact on startup time (not too mention
>> >resources).
>> >
>> >The clever programmer will construct (and destroy) the forms where and
>> >when needed.
>> >
>> I'll pass that along. I suspect I'll only get involved when it comes
>> to tracking the CONNECT statement . . .
>>
>> >Unfortunately I have seen all too much of the former.. and just as
>> >unfortunate is that you cannot kill a dumbass calling himself a
>> >programmer.. yet anyway (wait 'til the Scorched Earth Party comes into
>> >power.. we will have special laws to deal with so-called programmers..
>> >using lead pipes of course).
>> >
>> >Other "overheads" in app startup:
>> >- loading and initialising DLLs
>> >- establishing network connections
>> >- construction of objects
>> >
>> >There's nothing you can do about loading of DLL's.. except maybe to
>> >preload them at Windows startup (but that requires a custom little
>> >Windows service to be written which will make dumbass programmer not
>> >only trash your network, but causing the coffee machine to overload
>> >too).
>> >
>> >Network connections.. including connecting to Oracle. What can slow
>> >that down is slow/incorrectly configures WINS/DNS servers.. or using
>> >reverse lookups on the server side. Including going thru firewalls and
>> >proxies.
>>
>> I'll definately make a point of that. The app *does* go thru
>> firewalls.
>> >
>> >As for the last one.. doing that across the network.. What is there to
>> >say but that 3 tier sucks.
>> >
>> >Have fun. And don't forget your lead pipe (you get you own brand new
>> >one when signing on as a card carrying member of the Scorched Earth
>> >Party).
>>
>> Where do I sign up?
>>
>> Thanks for the pointers, Billy. I'll keep them in by back pocket to
>> bring out as the opportunity arises. As I understand it, this will
>> be a multi-team approach, with developers, network admins, server
>> admins, and DBA. History teaches me two things: First, being "just" a
>> DBA (and worse, living in Tennesse, which means I must be barefoot and
>> ignorant) I won't be asked for any input on non-DB issues. Second,
>> since the delopers are such clever people (living in California,
>> center of all technical knowledge), the problem *must* be a DB issue!
Received on Tue Aug 05 2003 - 15:10:19 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US