Re: Connection performance issue
From: David Gugick (davidg-nospam_at_imceda.com)
Date: 12/23/04
- Next message: Sergey Bogdanov: "How to get tree by OPENXML?"
- Previous message: Ross Presser: "Re: [OT] How do you pronounce "varchar"?"
- In reply to: Zach Wells: "Re: Connection performance issue"
- Next in thread: Andrew J. Kelly: "Re: Connection performance issue"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 23 Dec 2004 13:54:31 -0500
Zach Wells wrote:
> David Gugick wrote:
>> Zach Wells wrote:
>>
>>> David Gugick wrote:
>>>
>>>>
>>>> If you have CALs, I'm not sure if they are for concurrent or by
>>>> user. But certainly there are considerations, hence, my time out
>>>> suggestion. I've never been on a project that didn't keep them
>>>> open, usually with a timer to drop the connection when idle. It
>>>> would have to be carefully architected, I think into the UI
>>>> itself, rather than the data access library. I think about a
>>>> screen that requires 3 or 4 stored procedure executions to get all
>>>> the data and having to connect and disconnect for each execution
>>>> and the overhead seems high. Disconnecting from the UI would give
>>>> a little more control over when the connection terminates, but
>>>> does leave open the possibility that the connection is never
>>>> closed. And we're back to a timer again...
>>>
>>>
>>> But connection pooling solves that overhead problem doesn't it?
>>>
>>> Zach
>>
>>
>> Yes, connection pooling on the client can mitigate this somewhat. I
>> know you can do this from the ODBC applet in control panel. How else
>> is it implemented?
>>
>
> I'm not terribly familiar with connection pooling. I just know that it
> is on by default.
>
> So, given that, and the way licensing works, it seems to me that
> opening and closing connetions as fast as possible is the way to go.
> Plus, MS recommends that practice. I was really trying to find out
> why you think it makes more sense to keep connections open.
>
> Back in the day (few years ago), it was the practice to open a
> connection when you first started your app, use that connection
> throughout your application's life, then close it when the app exited.
> However, with the newer n-tier architecture it has become the standard
> to open and close your connections as quickly as possible. I'm just
> curious what you use to justify your approach.
>
> FYI, I'm not challenging you or questioning your logic, I'm just
> curious what your logic and arguments are for it.
>
> Zach
I was just talking about a client-server architecture, which is what the
OP was asking, where the front-end is controlling the connections. Once
you move to a middle tier, you can use connection pooling on that
middle-tier computer. I don't think pooling is on by default at the
client (at least not that I've seen on my clients).
For a client-server architecture (like a .Net Windows Forms
application), I would leave the connection open, since you are
guaranteed the best performance. And since I don't know how CALs are
licensed (per user or per connection), I can't speak as to what's the
best for a limited CAL environment, but I would hate to think that a
limited CAL environment ran the risk of running out of connections. Most
companies I know have processor licensing anyway so leaving the
connections open poses no issues and gives best performance. In that
type of environment, I don't see any benefit of opening and closing.
-- David G.
- Next message: Sergey Bogdanov: "How to get tree by OPENXML?"
- Previous message: Ross Presser: "Re: [OT] How do you pronounce "varchar"?"
- In reply to: Zach Wells: "Re: Connection performance issue"
- Next in thread: Andrew J. Kelly: "Re: Connection performance issue"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
