Re: analyzing slow connections

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!

-- 
===================================================================

Brian Peasland
dba_at_remove_spam.peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
 the three"