Re: Occasional delay in processing incoming packets
From: James (needadohelp_at_hotmail.com)
Date: 08/18/04
- Next message: Geoff N. Hiten: "Re: Licensing Questions"
- Previous message: David Browne: "Re: Clustered index scan wrongly resorted to in execution plan"
- In reply to: David G.: "Re: Occasional delay in processing incoming packets"
- Next in thread: David G.: "Re: Occasional delay in processing incoming packets"
- Reply: David G.: "Re: Occasional delay in processing incoming packets"
- Messages sorted by: [ date ] [ thread ]
Date: 18 Aug 2004 12:43:33 -0700
I created a Named Pipes alias and used that instead of TCP/IP. I've
never done that before, so I checked to make sure the connections were
using Named Pipes before continuing.
During this test I still have the same problem.
"David G." <david_nospam@nospam.com> wrote in message news:<eOaWzPOhEHA.1276@TK2MSFTNGP09.phx.gbl>...
> James wrote:
> > I have a problem where occasionally (less that 1%) a packet is not
> > processed for as long as 25 seconds.
> >
> > 1) I get the exact same behavior with ADO 2.8 and ADO.NET.
> >
> > 2) A detailed view of the chain of events looks like this:
> >
> > . T+0 seconds - connection from the pool is allocated
> > . T+0 seconds - vb call to Command.Execute (or c# call to
> > DataAdapter.Fill)
> > . T+0 seconds - single packet (118 bytes) is sent to database machine
> > (from a web server)
> > . T+0.1 seconds - ack received from database machine indicating packet
> > was successfully received in full
> > . T+25 seconds - SQL Profiler trace "Start Time" for database call
> > . T+25 seconds - SQL Profiler trace "End Time" for database call
> > . T+25 seconds - data returns to application
> > . T+25 seconds - connection is returned to the pool
> >
> >
> > So the "lost time" occurs on the database machine between the time the
> > packet is received, and the time Profiler claims SQL Server started
> > working on the query.
> >
> > I've tried to run perfmon on the obvious counters on the database but
> > I've failed to find anything out of the ordinary. There are so many
> > counters! Any ideas on what specifically I should be looking at now?
> >
> > ~ James
> >
> > Occasional delay in processing incoming packets
>
> If you can, try setting up an alias to teh SQL Server machine using a
> different network protocol (e.g. named pipes instead of TCP/IP). That
> way you can see if the problem is related to the network library. If the
> start time in Profiler is T+25, it sounds like SQL Server is not getting
> the packet until T+25.
>
> You can set up aliases from the SQL Server Client Tools - Client Network
> Utility.
- Next message: Geoff N. Hiten: "Re: Licensing Questions"
- Previous message: David Browne: "Re: Clustered index scan wrongly resorted to in execution plan"
- In reply to: David G.: "Re: Occasional delay in processing incoming packets"
- Next in thread: David G.: "Re: Occasional delay in processing incoming packets"
- Reply: David G.: "Re: Occasional delay in processing incoming packets"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|