Network is full of peanut butter...

....or *something*...

Please forgive me if I sound a bit naive; I'm a developer, not a network
guy.

We are having HORRENDOUS performance issues here between (what should be) a
lean mean web app and the big momma SQL server.

The SQL Server is a 4-cpu box with a RAID-10 stack, 3GB RAM <sorry, don't
know the clock speed> Windows 2000 (updates and patches unknown), SQL Server
2000 + SP3, and the whole building is all 100Mb Ethernet.

A TRACERT shows one hop from my dev box to the SQL box.

A PING replies all four packets in < 1ms.

But then the other day, while debugging some code, I had VS.NET up in the
debugger, and SQL Profiler eavesdropping so I could see the parameters being
passed to a stored procedure in the database. When the debugger invoked the
stored procedure, it was 4 minutes until the SQL Profiler finally
acknowledged the call.

The MIS guys here resemble the Marx Brothers, and there are no MCSE's or
MCDBA's, and I'm the only MCSD. (You'd think a huge multinational
corporation would get one or more of the above)

My speculation is that a 4-minute delay from sending a packet to the server
receiving it could only be explained by bandwidth issues, and the only way I
can guess we're having a bandwidth issue like this is if there exists
excessive "daisy-chaining" of hubs -- for example, when the suits move a
bunch of people around and then add another hub or switch with like 30 boxes
on it, all piped through an "uplink" port to another hub that services
another couple dozen boxes through it's own "uplink" port, etc.

My problem is that I don't know enough network stuff to be able to prove or
disprove my theory. It would be neat if I had a utility that works like
TRACERT that I can use to see how many hubs / switches are between point A
and point B, not just how many subnets.

Anyone have some tips?

--
Peace & happy computing,

Mike Labosh, MCSD
"Working here is like living inside a Salvador Dali painting." -- Me. Yeah,
ME! [Oh fer cryin out loud]

Mike,

why don't you take a laptop, grab Groucho by the hand and walk to the big
momma SQL server, ie to the switch where it is connected. plug your laptop
to the switch and test response time. Then walk away further and further and
do some more response time measurements.

Peace & happy computing to you too,
Dusko Savatovic


"Mike Labosh" <(E-Mail Removed)> wrote in message
news:%23ex$(E-Mail Removed)...
> ...or *something*...
>
> Please forgive me if I sound a bit naive; I'm a developer, not a network
> guy.
>
> We are having HORRENDOUS performance issues here between (what should be)
> a lean mean web app and the big momma SQL server.
>
> The SQL Server is a 4-cpu box with a RAID-10 stack, 3GB RAM <sorry, don't
> know the clock speed> Windows 2000 (updates and patches unknown), SQL
> Server 2000 + SP3, and the whole building is all 100Mb Ethernet.
>
> A TRACERT shows one hop from my dev box to the SQL box.
>
> A PING replies all four packets in < 1ms.
>
> But then the other day, while debugging some code, I had VS.NET up in the
> debugger, and SQL Profiler eavesdropping so I could see the parameters
> being passed to a stored procedure in the database. When the debugger
> invoked the stored procedure, it was 4 minutes until the SQL Profiler
> finally acknowledged the call.
>
> The MIS guys here resemble the Marx Brothers, and there are no MCSE's or
> MCDBA's, and I'm the only MCSD. (You'd think a huge multinational
> corporation would get one or more of the above)
>
> My speculation is that a 4-minute delay from sending a packet to the
> server receiving it could only be explained by bandwidth issues, and the
> only way I can guess we're having a bandwidth issue like this is if there
> exists excessive "daisy-chaining" of hubs -- for example, when the suits
> move a bunch of people around and then add another hub or switch with like
> 30 boxes on it, all piped through an "uplink" port to another hub that
> services another couple dozen boxes through it's own "uplink" port, etc.
>
> My problem is that I don't know enough network stuff to be able to prove
> or disprove my theory. It would be neat if I had a utility that works
> like TRACERT that I can use to see how many hubs / switches are between
> point A and point B, not just how many subnets.
>
> Anyone have some tips?
>
> --
> Peace & happy computing,
>
> Mike Labosh, MCSD
> "Working here is like living inside a Salvador Dali painting." -- Me.
> Yeah, ME! [Oh fer cryin out loud]
>

There are no tools that I know of (other than older CatOS Cisco switches)
that will show you the layer 1/2 hops. You could get some documentation on
spanning-tree and show that to them. See if you can find out the size of
your switching diameter that will help.

"Mike Labosh" <(E-Mail Removed)> wrote in message
news:%23ex$(E-Mail Removed)...
> ...or *something*...
>
> Please forgive me if I sound a bit naive; I'm a developer, not a network
> guy.
>
> We are having HORRENDOUS performance issues here between (what should be)
a
> lean mean web app and the big momma SQL server.
>
> The SQL Server is a 4-cpu box with a RAID-10 stack, 3GB RAM <sorry, don't
> know the clock speed> Windows 2000 (updates and patches unknown), SQL
Server
> 2000 + SP3, and the whole building is all 100Mb Ethernet.
>
> A TRACERT shows one hop from my dev box to the SQL box.
>
> A PING replies all four packets in < 1ms.
>
> But then the other day, while debugging some code, I had VS.NET up in the
> debugger, and SQL Profiler eavesdropping so I could see the parameters
being
> passed to a stored procedure in the database. When the debugger invoked
the
> stored procedure, it was 4 minutes until the SQL Profiler finally
> acknowledged the call.
>
> The MIS guys here resemble the Marx Brothers, and there are no MCSE's or
> MCDBA's, and I'm the only MCSD. (You'd think a huge multinational
> corporation would get one or more of the above)
>
> My speculation is that a 4-minute delay from sending a packet to the
server
> receiving it could only be explained by bandwidth issues, and the only way
I
> can guess we're having a bandwidth issue like this is if there exists
> excessive "daisy-chaining" of hubs -- for example, when the suits move a
> bunch of people around and then add another hub or switch with like 30
boxes
> on it, all piped through an "uplink" port to another hub that services
> another couple dozen boxes through it's own "uplink" port, etc.
>
> My problem is that I don't know enough network stuff to be able to prove
or
> disprove my theory. It would be neat if I had a utility that works like
> TRACERT that I can use to see how many hubs / switches are between point
A
> and point B, not just how many subnets.
>
> Anyone have some tips?
>
> --
> Peace & happy computing,
>
> Mike Labosh, MCSD
> "Working here is like living inside a Salvador Dali painting." -- Me.
Yeah,
> ME! [Oh fer cryin out loud]
>
>

> why don't you take a laptop, grab Groucho by the hand and walk to the big
> momma SQL server, ie to the switch where it is connected. plug your laptop
> to the switch and test response time. Then walk away further and further
> and do some more response time measurements.

Excellent idea. We'll see what happens.
--
Peace & happy computing,

Mike Labosh, MCSD
"Working here is like living inside a Salvador Dali painting." -- Me. Yeah,
ME! [Oh fer cryin out loud]

I was just thinking,...with Ethernet,...isn't there a limit on how many
Repeaters (hub) or how many bridges (switches) can be chained together
before it fails? I know each link with cooper has a 300 foot (100 meters)
limit, but I thought there was also a limit to how many repeaters and/or
bridges could be in the path as well when working in the context of a LAN.


--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/t...dance/2004.asp
http://www.microsoft.com/isaserver/t...dance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------



"Neteng" <(E-Mail Removed)> wrote in message
news:ux$(E-Mail Removed)...
> There are no tools that I know of (other than older CatOS Cisco switches)
> that will show you the layer 1/2 hops. You could get some documentation on
> spanning-tree and show that to them. See if you can find out the size of
> your switching diameter that will help.
>
> "Mike Labosh" <(E-Mail Removed)> wrote in message
> news:%23ex$(E-Mail Removed)...
> > ...or *something*...
> >
> > Please forgive me if I sound a bit naive; I'm a developer, not a
network
> > guy.
> >
> > We are having HORRENDOUS performance issues here between (what should
be)
> a
> > lean mean web app and the big momma SQL server.
> >
> > The SQL Server is a 4-cpu box with a RAID-10 stack, 3GB RAM <sorry,
don't
> > know the clock speed> Windows 2000 (updates and patches unknown), SQL
> Server
> > 2000 + SP3, and the whole building is all 100Mb Ethernet.
> >
> > A TRACERT shows one hop from my dev box to the SQL box.
> >
> > A PING replies all four packets in < 1ms.
> >
> > But then the other day, while debugging some code, I had VS.NET up in
the
> > debugger, and SQL Profiler eavesdropping so I could see the parameters
> being
> > passed to a stored procedure in the database. When the debugger invoked
> the
> > stored procedure, it was 4 minutes until the SQL Profiler finally
> > acknowledged the call.
> >
> > The MIS guys here resemble the Marx Brothers, and there are no MCSE's or
> > MCDBA's, and I'm the only MCSD. (You'd think a huge multinational
> > corporation would get one or more of the above)
> >
> > My speculation is that a 4-minute delay from sending a packet to the
> server
> > receiving it could only be explained by bandwidth issues, and the only
way
> I
> > can guess we're having a bandwidth issue like this is if there exists
> > excessive "daisy-chaining" of hubs -- for example, when the suits move a
> > bunch of people around and then add another hub or switch with like 30
> boxes
> > on it, all piped through an "uplink" port to another hub that services
> > another couple dozen boxes through it's own "uplink" port, etc.
> >
> > My problem is that I don't know enough network stuff to be able to prove
> or
> > disprove my theory. It would be neat if I had a utility that works like
> > TRACERT that I can use to see how many hubs / switches are between
point
> A
> > and point B, not just how many subnets.
> >
> > Anyone have some tips?
> >
> > --
> > Peace & happy computing,
> >
> > Mike Labosh, MCSD
> > "Working here is like living inside a Salvador Dali painting." -- Me.
> Yeah,
> > ME! [Oh fer cryin out loud]
> >
> >
>
>

It's the old 5-4-3 rule. If I remember right... 5 segments, 4 hubs, 3 of
them populated with users.

"Phillip Windell" <@.> wrote in message
news:(E-Mail Removed)...
> I was just thinking,...with Ethernet,...isn't there a limit on how many
> Repeaters (hub) or how many bridges (switches) can be chained together
> before it fails? I know each link with cooper has a 300 foot (100 meters)
> limit, but I thought there was also a limit to how many repeaters and/or
> bridges could be in the path as well when working in the context of a LAN.
>
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
> -----------------------------------------------------
> Understanding the ISA 2004 Access Rule Processing
> http://www.isaserver.org/articles/IS...cessRules.html
>
> Microsoft Internet Security & Acceleration Server: Guidance
> http://www.microsoft.com/isaserver/t...dance/2004.asp
> http://www.microsoft.com/isaserver/t...dance/2000.asp
>
> Microsoft Internet Security & Acceleration Server: Partners
> http://www.microsoft.com/isaserver/partners/default.asp
> -----------------------------------------------------
>
>
>
> "Neteng" <(E-Mail Removed)> wrote in message
> news:ux$(E-Mail Removed)...
> > There are no tools that I know of (other than older CatOS Cisco
switches)
> > that will show you the layer 1/2 hops. You could get some documentation
on
> > spanning-tree and show that to them. See if you can find out the size of
> > your switching diameter that will help.
> >
> > "Mike Labosh" <(E-Mail Removed)> wrote in message
> > news:%23ex$(E-Mail Removed)...
> > > ...or *something*...
> > >
> > > Please forgive me if I sound a bit naive; I'm a developer, not a
> network
> > > guy.
> > >
> > > We are having HORRENDOUS performance issues here between (what should
> be)
> > a
> > > lean mean web app and the big momma SQL server.
> > >
> > > The SQL Server is a 4-cpu box with a RAID-10 stack, 3GB RAM <sorry,
> don't
> > > know the clock speed> Windows 2000 (updates and patches unknown), SQL
> > Server
> > > 2000 + SP3, and the whole building is all 100Mb Ethernet.
> > >
> > > A TRACERT shows one hop from my dev box to the SQL box.
> > >
> > > A PING replies all four packets in < 1ms.
> > >
> > > But then the other day, while debugging some code, I had VS.NET up in
> the
> > > debugger, and SQL Profiler eavesdropping so I could see the parameters
> > being
> > > passed to a stored procedure in the database. When the debugger
invoked
> > the
> > > stored procedure, it was 4 minutes until the SQL Profiler finally
> > > acknowledged the call.
> > >
> > > The MIS guys here resemble the Marx Brothers, and there are no MCSE's
or
> > > MCDBA's, and I'm the only MCSD. (You'd think a huge multinational
> > > corporation would get one or more of the above)
> > >
> > > My speculation is that a 4-minute delay from sending a packet to the
> > server
> > > receiving it could only be explained by bandwidth issues, and the only
> way
> > I
> > > can guess we're having a bandwidth issue like this is if there exists
> > > excessive "daisy-chaining" of hubs -- for example, when the suits move
a
> > > bunch of people around and then add another hub or switch with like 30
> > boxes
> > > on it, all piped through an "uplink" port to another hub that services
> > > another couple dozen boxes through it's own "uplink" port, etc.
> > >
> > > My problem is that I don't know enough network stuff to be able to
prove
> > or
> > > disprove my theory. It would be neat if I had a utility that works
like
> > > TRACERT that I can use to see how many hubs / switches are between
> point
> > A
> > > and point B, not just how many subnets.
> > >
> > > Anyone have some tips?
> > >
> > > --
> > > Peace & happy computing,
> > >
> > > Mike Labosh, MCSD
> > > "Working here is like living inside a Salvador Dali painting." -- Me.
> > Yeah,
> > > ME! [Oh fer cryin out loud]
> > >
> > >
> >
> >
>
>

That's the one,...and it could be his problem,...or maybe an aggravation to
another pre-existing problem in combination.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/t...dance/2004.asp
http://www.microsoft.com/isaserver/t...dance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------


"Neteng" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> It's the old 5-4-3 rule. If I remember right... 5 segments, 4 hubs, 3 of
> them populated with users.
>
> "Phillip Windell" <@.> wrote in message
> news:(E-Mail Removed)...
> > I was just thinking,...with Ethernet,...isn't there a limit on how many
> > Repeaters (hub) or how many bridges (switches) can be chained together
> > before it fails? I know each link with cooper has a 300 foot (100
meters)
> > limit, but I thought there was also a limit to how many repeaters and/or
> > bridges could be in the path as well when working in the context of a
LAN.
> >
> >
> > --
> > Phillip Windell [MCP, MVP, CCNA]
> > www.wandtv.com
> > -----------------------------------------------------
> > Understanding the ISA 2004 Access Rule Processing
> > http://www.isaserver.org/articles/IS...cessRules.html
> >
> > Microsoft Internet Security & Acceleration Server: Guidance
> > http://www.microsoft.com/isaserver/t...dance/2004.asp
> > http://www.microsoft.com/isaserver/t...dance/2000.asp
> >
> > Microsoft Internet Security & Acceleration Server: Partners
> > http://www.microsoft.com/isaserver/partners/default.asp
> > -----------------------------------------------------
> >
> >
> >
> > "Neteng" <(E-Mail Removed)> wrote in message
> > news:ux$(E-Mail Removed)...
> > > There are no tools that I know of (other than older CatOS Cisco
> switches)
> > > that will show you the layer 1/2 hops. You could get some
documentation
> on
> > > spanning-tree and show that to them. See if you can find out the size
of
> > > your switching diameter that will help.
> > >
> > > "Mike Labosh" <(E-Mail Removed)> wrote in message
> > > news:%23ex$(E-Mail Removed)...
> > > > ...or *something*...
> > > >
> > > > Please forgive me if I sound a bit naive; I'm a developer, not a
> > network
> > > > guy.
> > > >
> > > > We are having HORRENDOUS performance issues here between (what
should
> > be)
> > > a
> > > > lean mean web app and the big momma SQL server.
> > > >
> > > > The SQL Server is a 4-cpu box with a RAID-10 stack, 3GB RAM <sorry,
> > don't
> > > > know the clock speed> Windows 2000 (updates and patches unknown),
SQL
> > > Server
> > > > 2000 + SP3, and the whole building is all 100Mb Ethernet.
> > > >
> > > > A TRACERT shows one hop from my dev box to the SQL box.
> > > >
> > > > A PING replies all four packets in < 1ms.
> > > >
> > > > But then the other day, while debugging some code, I had VS.NET up
in
> > the
> > > > debugger, and SQL Profiler eavesdropping so I could see the
parameters
> > > being
> > > > passed to a stored procedure in the database. When the debugger
> invoked
> > > the
> > > > stored procedure, it was 4 minutes until the SQL Profiler finally
> > > > acknowledged the call.
> > > >
> > > > The MIS guys here resemble the Marx Brothers, and there are no
MCSE's
> or
> > > > MCDBA's, and I'm the only MCSD. (You'd think a huge multinational
> > > > corporation would get one or more of the above)
> > > >
> > > > My speculation is that a 4-minute delay from sending a packet to the
> > > server
> > > > receiving it could only be explained by bandwidth issues, and the
only
> > way
> > > I
> > > > can guess we're having a bandwidth issue like this is if there
exists
> > > > excessive "daisy-chaining" of hubs -- for example, when the suits
move
> a
> > > > bunch of people around and then add another hub or switch with like
30
> > > boxes
> > > > on it, all piped through an "uplink" port to another hub that
services
> > > > another couple dozen boxes through it's own "uplink" port, etc.
> > > >
> > > > My problem is that I don't know enough network stuff to be able to
> prove
> > > or
> > > > disprove my theory. It would be neat if I had a utility that works
> like
> > > > TRACERT that I can use to see how many hubs / switches are between
> > point
> > > A
> > > > and point B, not just how many subnets.
> > > >
> > > > Anyone have some tips?
> > > >
> > > > --
> > > > Peace & happy computing,
> > > >
> > > > Mike Labosh, MCSD
> > > > "Working here is like living inside a Salvador Dali painting." --
Me.
> > > Yeah,
> > > > ME! [Oh fer cryin out loud]
> > > >
> > > >
> > >
> > >
> >
> >
>
>

You may want to check your DNS or WINS. I guess most likely your DNS setting
have some problem with name resolution if you are running AD. Delay in h/w
switches usually less than a second, not 4 minutes.

pan

"Mike Labosh" <(E-Mail Removed)> wrote in message
news:%23ex$(E-Mail Removed)...
> ...or *something*...
>
> Please forgive me if I sound a bit naive; I'm a developer, not a network
> guy.
>
> We are having HORRENDOUS performance issues here between (what should be)
> a lean mean web app and the big momma SQL server.
>
> The SQL Server is a 4-cpu box with a RAID-10 stack, 3GB RAM <sorry, don't
> know the clock speed> Windows 2000 (updates and patches unknown), SQL
> Server 2000 + SP3, and the whole building is all 100Mb Ethernet.
>
> A TRACERT shows one hop from my dev box to the SQL box.
>
> A PING replies all four packets in < 1ms.
>
> But then the other day, while debugging some code, I had VS.NET up in the
> debugger, and SQL Profiler eavesdropping so I could see the parameters
> being passed to a stored procedure in the database. When the debugger
> invoked the stored procedure, it was 4 minutes until the SQL Profiler
> finally acknowledged the call.
>
> The MIS guys here resemble the Marx Brothers, and there are no MCSE's or
> MCDBA's, and I'm the only MCSD. (You'd think a huge multinational
> corporation would get one or more of the above)
>
> My speculation is that a 4-minute delay from sending a packet to the
> server receiving it could only be explained by bandwidth issues, and the
> only way I can guess we're having a bandwidth issue like this is if there
> exists excessive "daisy-chaining" of hubs -- for example, when the suits
> move a bunch of people around and then add another hub or switch with like
> 30 boxes on it, all piped through an "uplink" port to another hub that
> services another couple dozen boxes through it's own "uplink" port, etc.
>
> My problem is that I don't know enough network stuff to be able to prove
> or disprove my theory. It would be neat if I had a utility that works
> like TRACERT that I can use to see how many hubs / switches are between
> point A and point B, not just how many subnets.
>
> Anyone have some tips?
>
> --
> Peace & happy computing,
>
> Mike Labosh, MCSD
> "Working here is like living inside a Salvador Dali painting." -- Me.
> Yeah, ME! [Oh fer cryin out loud]
>