Re: analyzing slow connections

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 - 08:18:55 CDT