named pipes?

Hello
Which is the difference between using named pipes and TCP/IP?
Is it possible to enable TCP/IP and disable named pipes at the same time for
the server communication?
What happens if I disable named pipes?
Tanx
Alejandra Parra
Mexico
Named Pipes is MUCH slower, unless it is between servers, where it runs in
the kernal. I believe it has to do with the ability to queue requests - but
I'm not sure about that.
I usually disable named pipes on my servers. Otherwise people create DSNs
to connect and indicate Named Pipes, then wonder why the application is so
slow.
"Alejandra Parra" wrote:

> Hello
> Which is the difference between using named pipes and TCP/IP?
> Is it possible to enable TCP/IP and disable named pipes at the same time for
> the server communication?
> What happens if I disable named pipes?
> Tanx
> Alejandra Parra
> Mexico
>
>
|||"Alejandra Parra" <alparrita@.hotmail.com> wrote in message
news:OzuMkbRkEHA.2908@.tk2msftngp13.phx.gbl...

> Which is the difference between using named pipes and TCP/IP?
SQL Server BOL has a good write-up on the differences between these two
libraries see 'Named Pipes vs. TCP/IP Sockets'.

> Is it possible to enable TCP/IP and disable named pipes at the same time
for
> the server communication?
Yes, just make sure the network libraries are set up the same way on the
client side.

> What happens if I disable named pipes?
Most likely nothing... I've seen some old utilities and software dependent
on named pipes, however it's unlikely to effect you. As always, test before
deploying to production.
Steve

named pipes?

Hello
Which is the difference between using named pipes and TCP/IP?
Is it possible to enable TCP/IP and disable named pipes at the same time for
the server communication?
What happens if I disable named pipes?
Tanx
Alejandra Parra
MexicoNamed Pipes is MUCH slower, unless it is between servers, where it runs in
the kernal. I believe it has to do with the ability to queue requests - but
I'm not sure about that.
I usually disable named pipes on my servers. Otherwise people create DSNs
to connect and indicate Named Pipes, then wonder why the application is so
slow.
"Alejandra Parra" wrote:

> Hello
> Which is the difference between using named pipes and TCP/IP?
> Is it possible to enable TCP/IP and disable named pipes at the same time f
or
> the server communication?
> What happens if I disable named pipes?
> Tanx
> Alejandra Parra
> Mexico
>
>|||"Alejandra Parra" <alparrita@.hotmail.com> wrote in message
news:OzuMkbRkEHA.2908@.tk2msftngp13.phx.gbl...

> Which is the difference between using named pipes and TCP/IP?
SQL Server BOL has a good write-up on the differences between these two
libraries see 'Named Pipes vs. TCP/IP Sockets'.

> Is it possible to enable TCP/IP and disable named pipes at the same time
for
> the server communication?
Yes, just make sure the network libraries are set up the same way on the
client side.

> What happens if I disable named pipes?
Most likely nothing... I've seen some old utilities and software dependent
on named pipes, however it's unlikely to effect you. As always, test before
deploying to production.
Steve

named pipes?

Hello
Which is the difference between using named pipes and TCP/IP?
Is it possible to enable TCP/IP and disable named pipes at the same time for
the server communication?
What happens if I disable named pipes?
Tanx
Alejandra Parra
Mexico"Alejandra Parra" <alparrita@.hotmail.com> wrote in message
news:OzuMkbRkEHA.2908@.tk2msftngp13.phx.gbl...
> Which is the difference between using named pipes and TCP/IP?
SQL Server BOL has a good write-up on the differences between these two
libraries see 'Named Pipes vs. TCP/IP Sockets'.
> Is it possible to enable TCP/IP and disable named pipes at the same time
for
> the server communication?
Yes, just make sure the network libraries are set up the same way on the
client side.
> What happens if I disable named pipes?
Most likely nothing... I've seen some old utilities and software dependent
on named pipes, however it's unlikely to effect you. As always, test before
deploying to production.
Steve

Named pipes vs TCP/IP and NETWORKIO wait type

I am experiencing a problem whereby a 3rd party application is performing data transfers between tables in a database and they are taking enormous amounts of time.
I have no way of knowing what it is actually doing but when I examine the current activity, the RUNNABLE process shows NETWORKIO in the Wait Type column. What is this as I have not been able to find anything in BOL.
Related to this, what is the faster way of connection: named pipes or TCP/IP ? Both the client and the server have both enabled but the application is using TCP/IP to connect. Would named pipes be faster ?
Regards,
Peter Apostolakopoulos.
Check this out: http://sqldev.net/misc/WaitTypes.htm
Are both these tables in the same DB? What command is it using?
Andrew J. Kelly SQL MVP
"Peter Apostolakopoulos" <apostolp@.britannic.co.uk> wrote in message
news:BDFFD198-0B85-44EE-9CC3-55863CD7F980@.microsoft.com...
> I am experiencing a problem whereby a 3rd party application is performing
data transfers between tables in a database and they are taking enormous
amounts of time.
> I have no way of knowing what it is actually doing but when I examine the
current activity, the RUNNABLE process shows NETWORKIO in the Wait Type
column. What is this as I have not been able to find anything in BOL.
> Related to this, what is the faster way of connection: named pipes or
TCP/IP ? Both the client and the server have both enabled but the
application is using TCP/IP to connect. Would named pipes be faster ?
> Regards,
> Peter Apostolakopoulos.
|||Andrew,
Many thanks for the info. It is very useful. I am still having problems but I am pursuing this with the suppliers as I they have written some custom SQL to do the data migration which is "not the best" !!
Peter Apostolakopoulos
sql

Named pipes vs TCP/IP and NETWORKIO wait type

I am experiencing a problem whereby a 3rd party application is performing da
ta transfers between tables in a database and they are taking enormous amoun
ts of time.
I have no way of knowing what it is actually doing but when I examine the cu
rrent activity, the RUNNABLE process shows NETWORKIO in the Wait Type column
. What is this as I have not been able to find anything in BOL.
Related to this, what is the faster way of connection: named pipes or TCP/IP
? Both the client and the server have both enabled but the application is u
sing TCP/IP to connect. Would named pipes be faster ?
Regards,
Peter Apostolakopoulos.Check this out: http://sqldev.net/misc/WaitTypes.htm
Are both these tables in the same DB? What command is it using?
Andrew J. Kelly SQL MVP
"Peter Apostolakopoulos" <apostolp@.britannic.co.uk> wrote in message
news:BDFFD198-0B85-44EE-9CC3-55863CD7F980@.microsoft.com...
> I am experiencing a problem whereby a 3rd party application is performing
data transfers between tables in a database and they are taking enormous
amounts of time.
> I have no way of knowing what it is actually doing but when I examine the
current activity, the RUNNABLE process shows NETWORKIO in the Wait Type
column. What is this as I have not been able to find anything in BOL.
> Related to this, what is the faster way of connection: named pipes or
TCP/IP ? Both the client and the server have both enabled but the
application is using TCP/IP to connect. Would named pipes be faster ?
> Regards,
> Peter Apostolakopoulos.|||Andrew,
Many thanks for the info. It is very useful. I am still having problems but
I am pursuing this with the suppliers as I they have written some custom SQL
to do the data migration which is "not the best" !!
Peter Apostolakopoulos

Named pipes vs TCP/IP

Hi all.
We have a customer with some connection problems running Remote desctop
(Terminal server). In the startuplog of the SQL2000 server we can't find
anything else than:
2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
Pipes.
On our server we have the following started. What should we do to get the
server listening on the TCP/IP too? We think this could be the problem.
2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
Named Pipes.
Thanks all.
geir
Is the IP netlib enabled (Server Network Utility)?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Geir Holme" <geir@.multicase.no> wrote in message news:u1OjFIJ5FHA.1032@.TK2MSFTNGP11.phx.gbl...
> Hi all.
> We have a customer with some connection problems running Remote desctop
> (Terminal server). In the startuplog of the SQL2000 server we can't find
> anything else than:
> 2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
> Pipes.
> On our server we have the following started. What should we do to get the
> server listening on the TCP/IP too? We think this could be the problem.
>
> 2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
> 2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
> 2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
> Named Pipes.
>
>
> Thanks all.
> geir
>

Named Pipes vs TCP/IP

Why would one choose Named Pipes over TCP/IP for the client net lib? We have
noticed for some of our customers that changing to named pipes speeds up the
response times of our application. But it is my understanding that a
properly configured LAN should work fine with TCP/IP.
Thanks,
Bob Castleman
SuccessWare Software
It is my understanding that named pipes have slightly less overhead than
TCP/IP but there it is usually not enough to warrant using named pipes. TCP
is much more versatile and should be encouraged in general over named pipes.
One thing to note is that WIN2003 has a 25% higher throuput in TCP over
Win2000 and DNS lookups are up to 120% faster as well. If your clients are
looking for speed improvements and are not on Win2003 they should try it
out. Another thing to note is that usually when clients tell me one
protocol is faster than another I tend to find there is too much chatter
from the client to the server in the first place. The more packets sent
back and forth the more likely you will have performance issues under heavy
load.
Andrew J. Kelly SQL MVP
"Bob Castleman" <nomail@.here> wrote in message
news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> Why would one choose Named Pipes over TCP/IP for the client net lib? We
have
> noticed for some of our customers that changing to named pipes speeds up
the
> response times of our application. But it is my understanding that a
> properly configured LAN should work fine with TCP/IP.
> Thanks,
> Bob Castleman
> SuccessWare Software
>
|||A specific example of what we are running into happened this morning. A
customer called complaining of speed problems. Everything was "fine" on
Friday and today it was slow. CPU load on the database server was around 2%.
Disks weren't thrasing, etc. I had him change a workstation from TCP/IP to
Named Pipes and the time it took to load our application went from 20
seconds to 2 seconds. He reported a similar effect on the other
workstations. Nothing I have been able to find about TCP/IP and Named Pipes
would explain this behavior. This seems like some problem in network
communication, especially since the server was basically sitting idle.
I personally don't like "quick fixes". We run into this with just enough
regularity that it would be good to know what's really happening so we can
address the underlying problem.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> It is my understanding that named pipes have slightly less overhead than
> TCP/IP but there it is usually not enough to warrant using named pipes.
> TCP
> is much more versatile and should be encouraged in general over named
> pipes.
> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
> Win2000 and DNS lookups are up to 120% faster as well. If your clients
> are
> looking for speed improvements and are not on Win2003 they should try it
> out. Another thing to note is that usually when clients tell me one
> protocol is faster than another I tend to find there is too much chatter
> from the client to the server in the first place. The more packets sent
> back and forth the more likely you will have performance issues under
> heavy
> load.
> --
> Andrew J. Kelly SQL MVP
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> have
> the
>
|||Simply some facts top start with: Named Pipes is a OSI level 7 (Application)
protocol, WinSock is OSI level 5 (Session), therefore in a TCP only based
network, Named Pipes actually goes over WinSock, so it does not make any
sense that TCP Winsock is slower in that case, which is also not the
experience, and this is why we use TCP to perform client server benchmarks
for SQL Server. When running on the same machine, Named Pipes is faster then
TCP, because it becomes a Local Pipe call (this is where the magic . (dot)
notation is coming from).
Also since Named Pipes are file system objects at kernel level the
scalability compared to WinSock is much less, which is why if you need to
handle large number of connections you always have to use TCP sockets
instead of named pipes. Which each OS release thresholds move, like Andrew
said in Windows Server 2003, TCP sockets and DNS performance increase
dramatically. For example in NT 4.0 you would run out of file handles when
you would have more then 100-150 named pipes connections, this is not longer
a problem with Windows 2000 and Windows Server 2004, but this is to indicate
that each protocol have there own characteristics and scalability
thresholds.
In general the default choice is and should be TCP sockets for all remote
connections, if you are running on the same server like batch process you
might consider named pipes using a local pipe (using the . (dot) notation).
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> It is my understanding that named pipes have slightly less overhead than
> TCP/IP but there it is usually not enough to warrant using named pipes.
> TCP
> is much more versatile and should be encouraged in general over named
> pipes.
> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
> Win2000 and DNS lookups are up to 120% faster as well. If your clients
> are
> looking for speed improvements and are not on Win2003 they should try it
> out. Another thing to note is that usually when clients tell me one
> protocol is faster than another I tend to find there is too much chatter
> from the client to the server in the first place. The more packets sent
> back and forth the more likely you will have performance issues under
> heavy
> load.
> --
> Andrew J. Kelly SQL MVP
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> have
> the
>
|||Anti.virus program trying to AV check the named pipes stuff?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bob Castleman" <nomail@.here> wrote in message news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>A specific example of what we are running into happened this morning. A customer called complaining
>of speed problems. Everything was "fine" on Friday and today it was slow. CPU load on the database
>server was around 2%. Disks weren't thrasing, etc. I had him change a workstation from TCP/IP to
>Named Pipes and the time it took to load our application went from 20 seconds to 2 seconds. He
>reported a similar effect on the other workstations. Nothing I have been able to find about TCP/IP
>and Named Pipes would explain this behavior. This seems like some problem in network communication,
>especially since the server was basically sitting idle.
> I personally don't like "quick fixes". We run into this with just enough regularity that it would
> be good to know what's really happening so we can address the underlying problem.
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>
|||An other option we see often are a DNS name resolution problems, use tracert
to determine the route taken.
An other thought are these notebooks, that connect wireless as well, or at
home? In which case it most of the times helps to dump the DNS resolver
cache of the workstation. See IPCONFIG /flushdns
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
> Anti.virus program trying to AV check the named pipes stuff?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>
|||"Bob Castleman" <nomail@.here> wrote in message
news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> Why would one choose Named Pipes over TCP/IP for the client net lib? We
have
> noticed for some of our customers that changing to named pipes speeds up
the
> response times of our application. But it is my understanding that a
> properly configured LAN should work fine with TCP/IP.
Don't know if this is your problem, but there was a bug a while ago in SQL
Server 2000 to do with the introduction of Kerberos aware authentication
using DBLibrary connections over TCP/IP.
IIRC, the SQL Client and SQL Server would not correctly negotiate packet
sizes. This could be circumvented by explicitly overriding the default
packet size in the client app. This was resolved in SQL Server SP2.
Kind Regards, Howard
|||Yes I have seen where issues with DNS have caused situations such as this as
well.
Andrew J. Kelly SQL MVP
"Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
> An other option we see often are a DNS name resolution problems, use
tracert
> to determine the route taken.
> An other thought are these notebooks, that connect wireless as well, or at
> home? In which case it most of the times helps to dump the DNS resolver
> cache of the workstation. See IPCONFIG /flushdns
> GertD@.SQLDev.Net
> Please reply only to the newsgroups.
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> You assume all risk for your use.
> Copyright SQLDev.Net 1991-2004 All rights reserved.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in[vbcol=seagreen]
> message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
network[vbcol=seagreen]
enough[vbcol=seagreen]
than[vbcol=seagreen]
pipes.[vbcol=seagreen]
over[vbcol=seagreen]
clients[vbcol=seagreen]
it[vbcol=seagreen]
chatter[vbcol=seagreen]
sent[vbcol=seagreen]
We
>
|||Same here.
Basically if the DNS server is unavailable the client will wait for 20-30
seconds, and then resolve the servername in a different way.
You can do a quick check if this is the issue by connecting to the server
via both the IP-address and the servername. IP-address should behave
normally and the servername will have the 30 second delay.
Jacco Schalkwijk
SQL Server MVP
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:uD8FsIPlEHA.3356@.TK2MSFTNGP14.phx.gbl...
> Yes I have seen where issues with DNS have caused situations such as this
> as
> well.
> --
> Andrew J. Kelly SQL MVP
>
> "Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
> news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
> tracert
> rights.
> in
> network
> enough
> than
> pipes.
> over
> clients
> it
> chatter
> sent
> We
>
|||Thanks,
I'll try that.
"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid > wrote
in message news:uXQM9FQlEHA.3876@.TK2MSFTNGP15.phx.gbl...
> Same here.
> Basically if the DNS server is unavailable the client will wait for 20-30
> seconds, and then resolve the servername in a different way.
> You can do a quick check if this is the issue by connecting to the server
> via both the IP-address and the servername. IP-address should behave
> normally and the servername will have the 30 second delay.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:uD8FsIPlEHA.3356@.TK2MSFTNGP14.phx.gbl...
>

Named pipes vs TCP/IP

Hi all.
We have a customer with some connection problems running Remote desctop
(Terminal server). In the startuplog of the SQL2000 server we can't find
anything else than:
2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
Pipes.
On our server we have the following started. What should we do to get the
server listening on the TCP/IP too? We think this could be the problem.
2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
Named Pipes.
Thanks all.
geirIs the IP netlib enabled (Server Network Utility)?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Geir Holme" <geir@.multicase.no> wrote in message news:u1OjFIJ5FHA.1032@.TK2MSFTNGP11.phx.gbl...
> Hi all.
> We have a customer with some connection problems running Remote desctop
> (Terminal server). In the startuplog of the SQL2000 server we can't find
> anything else than:
> 2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
> Pipes.
> On our server we have the following started. What should we do to get the
> server listening on the TCP/IP too? We think this could be the problem.
>
> 2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
> 2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
> 2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
> Named Pipes.
>
>
> Thanks all.
> geir
>

Named Pipes vs TCP/IP

Why would one choose Named Pipes over TCP/IP for the client net lib? We have
noticed for some of our customers that changing to named pipes speeds up the
response times of our application. But it is my understanding that a
properly configured LAN should work fine with TCP/IP.
Thanks,
Bob Castleman
SuccessWare SoftwareIt is my understanding that named pipes have slightly less overhead than
TCP/IP but there it is usually not enough to warrant using named pipes. TCP
is much more versatile and should be encouraged in general over named pipes.
One thing to note is that WIN2003 has a 25% higher throuput in TCP over
Win2000 and DNS lookups are up to 120% faster as well. If your clients are
looking for speed improvements and are not on Win2003 they should try it
out. Another thing to note is that usually when clients tell me one
protocol is faster than another I tend to find there is too much chatter
from the client to the server in the first place. The more packets sent
back and forth the more likely you will have performance issues under heavy
load.
--
Andrew J. Kelly SQL MVP
"Bob Castleman" <nomail@.here> wrote in message
news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> Why would one choose Named Pipes over TCP/IP for the client net lib? We
have
> noticed for some of our customers that changing to named pipes speeds up
the
> response times of our application. But it is my understanding that a
> properly configured LAN should work fine with TCP/IP.
> Thanks,
> Bob Castleman
> SuccessWare Software
>|||http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/optimsql/odp_tun_1a_7fcj.asp
Peter
"Status quo, you know, that is Latin for "the mess we're
in."
Ronald Reagan
>--Original Message--
>Why would one choose Named Pipes over TCP/IP for the
client net lib? We have
>noticed for some of our customers that changing to named
pipes speeds up the
>response times of our application. But it is my
understanding that a
>properly configured LAN should work fine with TCP/IP.
>Thanks,
>Bob Castleman
>SuccessWare Software
>
>.
>|||A specific example of what we are running into happened this morning. A
customer called complaining of speed problems. Everything was "fine" on
Friday and today it was slow. CPU load on the database server was around 2%.
Disks weren't thrasing, etc. I had him change a workstation from TCP/IP to
Named Pipes and the time it took to load our application went from 20
seconds to 2 seconds. He reported a similar effect on the other
workstations. Nothing I have been able to find about TCP/IP and Named Pipes
would explain this behavior. This seems like some problem in network
communication, especially since the server was basically sitting idle.
I personally don't like "quick fixes". We run into this with just enough
regularity that it would be good to know what's really happening so we can
address the underlying problem.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> It is my understanding that named pipes have slightly less overhead than
> TCP/IP but there it is usually not enough to warrant using named pipes.
> TCP
> is much more versatile and should be encouraged in general over named
> pipes.
> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
> Win2000 and DNS lookups are up to 120% faster as well. If your clients
> are
> looking for speed improvements and are not on Win2003 they should try it
> out. Another thing to note is that usually when clients tell me one
> protocol is faster than another I tend to find there is too much chatter
> from the client to the server in the first place. The more packets sent
> back and forth the more likely you will have performance issues under
> heavy
> load.
> --
> Andrew J. Kelly SQL MVP
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
> have
>> noticed for some of our customers that changing to named pipes speeds up
> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>|||Simply some facts top start with: Named Pipes is a OSI level 7 (Application)
protocol, WinSock is OSI level 5 (Session), therefore in a TCP only based
network, Named Pipes actually goes over WinSock, so it does not make any
sense that TCP Winsock is slower in that case, which is also not the
experience, and this is why we use TCP to perform client server benchmarks
for SQL Server. When running on the same machine, Named Pipes is faster then
TCP, because it becomes a Local Pipe call (this is where the magic . (dot)
notation is coming from).
Also since Named Pipes are file system objects at kernel level the
scalability compared to WinSock is much less, which is why if you need to
handle large number of connections you always have to use TCP sockets
instead of named pipes. Which each OS release thresholds move, like Andrew
said in Windows Server 2003, TCP sockets and DNS performance increase
dramatically. For example in NT 4.0 you would run out of file handles when
you would have more then 100-150 named pipes connections, this is not longer
a problem with Windows 2000 and Windows Server 2004, but this is to indicate
that each protocol have there own characteristics and scalability
thresholds.
In general the default choice is and should be TCP sockets for all remote
connections, if you are running on the same server like batch process you
might consider named pipes using a local pipe (using the . (dot) notation).
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright © SQLDev.Net 1991-2004 All rights reserved.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> It is my understanding that named pipes have slightly less overhead than
> TCP/IP but there it is usually not enough to warrant using named pipes.
> TCP
> is much more versatile and should be encouraged in general over named
> pipes.
> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
> Win2000 and DNS lookups are up to 120% faster as well. If your clients
> are
> looking for speed improvements and are not on Win2003 they should try it
> out. Another thing to note is that usually when clients tell me one
> protocol is faster than another I tend to find there is too much chatter
> from the client to the server in the first place. The more packets sent
> back and forth the more likely you will have performance issues under
> heavy
> load.
> --
> Andrew J. Kelly SQL MVP
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
> have
>> noticed for some of our customers that changing to named pipes speeds up
> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>|||Anti.virus program trying to AV check the named pipes stuff?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bob Castleman" <nomail@.here> wrote in message news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>A specific example of what we are running into happened this morning. A customer called complaining
>of speed problems. Everything was "fine" on Friday and today it was slow. CPU load on the database
>server was around 2%. Disks weren't thrasing, etc. I had him change a workstation from TCP/IP to
>Named Pipes and the time it took to load our application went from 20 seconds to 2 seconds. He
>reported a similar effect on the other workstations. Nothing I have been able to find about TCP/IP
>and Named Pipes would explain this behavior. This seems like some problem in network communication,
>especially since the server was basically sitting idle.
> I personally don't like "quick fixes". We run into this with just enough regularity that it would
> be good to know what's really happening so we can address the underlying problem.
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> It is my understanding that named pipes have slightly less overhead than
>> TCP/IP but there it is usually not enough to warrant using named pipes. TCP
>> is much more versatile and should be encouraged in general over named pipes.
>> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
>> Win2000 and DNS lookups are up to 120% faster as well. If your clients are
>> looking for speed improvements and are not on Win2003 they should try it
>> out. Another thing to note is that usually when clients tell me one
>> protocol is faster than another I tend to find there is too much chatter
>> from the client to the server in the first place. The more packets sent
>> back and forth the more likely you will have performance issues under heavy
>> load.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Bob Castleman" <nomail@.here> wrote in message
>> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
>> have
>> noticed for some of our customers that changing to named pipes speeds up
>> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>>
>|||An other option we see often are a DNS name resolution problems, use tracert
to determine the route taken.
An other thought are these notebooks, that connect wireless as well, or at
home? In which case it most of the times helps to dump the DNS resolver
cache of the workstation. See IPCONFIG /flushdns
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright © SQLDev.Net 1991-2004 All rights reserved.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
> Anti.virus program trying to AV check the named pipes stuff?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>>A specific example of what we are running into happened this morning. A
>>customer called complaining of speed problems. Everything was "fine" on
>>Friday and today it was slow. CPU load on the database server was around
>>2%. Disks weren't thrasing, etc. I had him change a workstation from
>>TCP/IP to Named Pipes and the time it took to load our application went
>>from 20 seconds to 2 seconds. He reported a similar effect on the other
>>workstations. Nothing I have been able to find about TCP/IP and Named
>>Pipes would explain this behavior. This seems like some problem in network
>>communication, especially since the server was basically sitting idle.
>> I personally don't like "quick fixes". We run into this with just enough
>> regularity that it would be good to know what's really happening so we
>> can address the underlying problem.
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> It is my understanding that named pipes have slightly less overhead than
>> TCP/IP but there it is usually not enough to warrant using named pipes.
>> TCP
>> is much more versatile and should be encouraged in general over named
>> pipes.
>> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
>> Win2000 and DNS lookups are up to 120% faster as well. If your clients
>> are
>> looking for speed improvements and are not on Win2003 they should try it
>> out. Another thing to note is that usually when clients tell me one
>> protocol is faster than another I tend to find there is too much chatter
>> from the client to the server in the first place. The more packets sent
>> back and forth the more likely you will have performance issues under
>> heavy
>> load.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Bob Castleman" <nomail@.here> wrote in message
>> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
>> have
>> noticed for some of our customers that changing to named pipes speeds
>> up
>> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>>
>>
>|||"Bob Castleman" <nomail@.here> wrote in message
news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> Why would one choose Named Pipes over TCP/IP for the client net lib? We
have
> noticed for some of our customers that changing to named pipes speeds up
the
> response times of our application. But it is my understanding that a
> properly configured LAN should work fine with TCP/IP.
Don't know if this is your problem, but there was a bug a while ago in SQL
Server 2000 to do with the introduction of Kerberos aware authentication
using DBLibrary connections over TCP/IP.
IIRC, the SQL Client and SQL Server would not correctly negotiate packet
sizes. This could be circumvented by explicitly overriding the default
packet size in the client app. This was resolved in SQL Server SP2.
Kind Regards, Howard|||Yes I have seen where issues with DNS have caused situations such as this as
well.
--
Andrew J. Kelly SQL MVP
"Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
> An other option we see often are a DNS name resolution problems, use
tracert
> to determine the route taken.
> An other thought are these notebooks, that connect wireless as well, or at
> home? In which case it most of the times helps to dump the DNS resolver
> cache of the workstation. See IPCONFIG /flushdns
> GertD@.SQLDev.Net
> Please reply only to the newsgroups.
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> You assume all risk for your use.
> Copyright © SQLDev.Net 1991-2004 All rights reserved.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in
> message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
> > Anti.virus program trying to AV check the named pipes stuff?
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Bob Castleman" <nomail@.here> wrote in message
> > news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
> >>A specific example of what we are running into happened this morning. A
> >>customer called complaining of speed problems. Everything was "fine" on
> >>Friday and today it was slow. CPU load on the database server was around
> >>2%. Disks weren't thrasing, etc. I had him change a workstation from
> >>TCP/IP to Named Pipes and the time it took to load our application went
> >>from 20 seconds to 2 seconds. He reported a similar effect on the other
> >>workstations. Nothing I have been able to find about TCP/IP and Named
> >>Pipes would explain this behavior. This seems like some problem in
network
> >>communication, especially since the server was basically sitting idle.
> >>
> >> I personally don't like "quick fixes". We run into this with just
enough
> >> regularity that it would be good to know what's really happening so we
> >> can address the underlying problem.
> >>
> >> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> >> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> >> It is my understanding that named pipes have slightly less overhead
than
> >> TCP/IP but there it is usually not enough to warrant using named
pipes.
> >> TCP
> >> is much more versatile and should be encouraged in general over named
> >> pipes.
> >> One thing to note is that WIN2003 has a 25% higher throuput in TCP
over
> >> Win2000 and DNS lookups are up to 120% faster as well. If your
clients
> >> are
> >> looking for speed improvements and are not on Win2003 they should try
it
> >> out. Another thing to note is that usually when clients tell me one
> >> protocol is faster than another I tend to find there is too much
chatter
> >> from the client to the server in the first place. The more packets
sent
> >> back and forth the more likely you will have performance issues under
> >> heavy
> >> load.
> >>
> >> --
> >> Andrew J. Kelly SQL MVP
> >>
> >>
> >> "Bob Castleman" <nomail@.here> wrote in message
> >> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> >> Why would one choose Named Pipes over TCP/IP for the client net lib?
We
> >> have
> >> noticed for some of our customers that changing to named pipes speeds
> >> up
> >> the
> >> response times of our application. But it is my understanding that a
> >> properly configured LAN should work fine with TCP/IP.
> >>
> >> Thanks,
> >>
> >> Bob Castleman
> >> SuccessWare Software
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>|||Same here.
Basically if the DNS server is unavailable the client will wait for 20-30
seconds, and then resolve the servername in a different way.
You can do a quick check if this is the issue by connecting to the server
via both the IP-address and the servername. IP-address should behave
normally and the servername will have the 30 second delay.
--
Jacco Schalkwijk
SQL Server MVP
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:uD8FsIPlEHA.3356@.TK2MSFTNGP14.phx.gbl...
> Yes I have seen where issues with DNS have caused situations such as this
> as
> well.
> --
> Andrew J. Kelly SQL MVP
>
> "Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
> news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
>> An other option we see often are a DNS name resolution problems, use
> tracert
>> to determine the route taken.
>> An other thought are these notebooks, that connect wireless as well, or
>> at
>> home? In which case it most of the times helps to dump the DNS resolver
>> cache of the workstation. See IPCONFIG /flushdns
>> GertD@.SQLDev.Net
>> Please reply only to the newsgroups.
>> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>> You assume all risk for your use.
>> Copyright © SQLDev.Net 1991-2004 All rights reserved.
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in
>> message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
>> > Anti.virus program trying to AV check the named pipes stuff?
>> >
>> > --
>> > Tibor Karaszi, SQL Server MVP
>> > http://www.karaszi.com/sqlserver/default.asp
>> > http://www.solidqualitylearning.com/
>> >
>> >
>> > "Bob Castleman" <nomail@.here> wrote in message
>> > news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>> >>A specific example of what we are running into happened this morning. A
>> >>customer called complaining of speed problems. Everything was "fine" on
>> >>Friday and today it was slow. CPU load on the database server was
>> >>around
>> >>2%. Disks weren't thrasing, etc. I had him change a workstation from
>> >>TCP/IP to Named Pipes and the time it took to load our application went
>> >>from 20 seconds to 2 seconds. He reported a similar effect on the other
>> >>workstations. Nothing I have been able to find about TCP/IP and Named
>> >>Pipes would explain this behavior. This seems like some problem in
> network
>> >>communication, especially since the server was basically sitting idle.
>> >>
>> >> I personally don't like "quick fixes". We run into this with just
> enough
>> >> regularity that it would be good to know what's really happening so we
>> >> can address the underlying problem.
>> >>
>> >> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> >> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> >> It is my understanding that named pipes have slightly less overhead
> than
>> >> TCP/IP but there it is usually not enough to warrant using named
> pipes.
>> >> TCP
>> >> is much more versatile and should be encouraged in general over named
>> >> pipes.
>> >> One thing to note is that WIN2003 has a 25% higher throuput in TCP
> over
>> >> Win2000 and DNS lookups are up to 120% faster as well. If your
> clients
>> >> are
>> >> looking for speed improvements and are not on Win2003 they should try
> it
>> >> out. Another thing to note is that usually when clients tell me one
>> >> protocol is faster than another I tend to find there is too much
> chatter
>> >> from the client to the server in the first place. The more packets
> sent
>> >> back and forth the more likely you will have performance issues under
>> >> heavy
>> >> load.
>> >>
>> >> --
>> >> Andrew J. Kelly SQL MVP
>> >>
>> >>
>> >> "Bob Castleman" <nomail@.here> wrote in message
>> >> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> >> Why would one choose Named Pipes over TCP/IP for the client net lib?
> We
>> >> have
>> >> noticed for some of our customers that changing to named pipes
>> >> speeds
>> >> up
>> >> the
>> >> response times of our application. But it is my understanding that a
>> >> properly configured LAN should work fine with TCP/IP.
>> >>
>> >> Thanks,
>> >>
>> >> Bob Castleman
>> >> SuccessWare Software
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>|||Thanks,
I'll try that.
"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid> wrote
in message news:uXQM9FQlEHA.3876@.TK2MSFTNGP15.phx.gbl...
> Same here.
> Basically if the DNS server is unavailable the client will wait for 20-30
> seconds, and then resolve the servername in a different way.
> You can do a quick check if this is the issue by connecting to the server
> via both the IP-address and the servername. IP-address should behave
> normally and the servername will have the 30 second delay.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:uD8FsIPlEHA.3356@.TK2MSFTNGP14.phx.gbl...
>> Yes I have seen where issues with DNS have caused situations such as this
>> as
>> well.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
>> news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
>> An other option we see often are a DNS name resolution problems, use
>> tracert
>> to determine the route taken.
>> An other thought are these notebooks, that connect wireless as well, or
>> at
>> home? In which case it most of the times helps to dump the DNS resolver
>> cache of the workstation. See IPCONFIG /flushdns
>> GertD@.SQLDev.Net
>> Please reply only to the newsgroups.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> You assume all risk for your use.
>> Copyright © SQLDev.Net 1991-2004 All rights reserved.
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
>> in
>> message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
>> > Anti.virus program trying to AV check the named pipes stuff?
>> >
>> > --
>> > Tibor Karaszi, SQL Server MVP
>> > http://www.karaszi.com/sqlserver/default.asp
>> > http://www.solidqualitylearning.com/
>> >
>> >
>> > "Bob Castleman" <nomail@.here> wrote in message
>> > news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>> >>A specific example of what we are running into happened this morning.
>> >>A
>> >>customer called complaining of speed problems. Everything was "fine"
>> >>on
>> >>Friday and today it was slow. CPU load on the database server was
>> >>around
>> >>2%. Disks weren't thrasing, etc. I had him change a workstation from
>> >>TCP/IP to Named Pipes and the time it took to load our application
>> >>went
>> >>from 20 seconds to 2 seconds. He reported a similar effect on the
>> >>other
>> >>workstations. Nothing I have been able to find about TCP/IP and Named
>> >>Pipes would explain this behavior. This seems like some problem in
>> network
>> >>communication, especially since the server was basically sitting idle.
>> >>
>> >> I personally don't like "quick fixes". We run into this with just
>> enough
>> >> regularity that it would be good to know what's really happening so
>> >> we
>> >> can address the underlying problem.
>> >>
>> >> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> >> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> >> It is my understanding that named pipes have slightly less overhead
>> than
>> >> TCP/IP but there it is usually not enough to warrant using named
>> pipes.
>> >> TCP
>> >> is much more versatile and should be encouraged in general over
>> >> named
>> >> pipes.
>> >> One thing to note is that WIN2003 has a 25% higher throuput in TCP
>> over
>> >> Win2000 and DNS lookups are up to 120% faster as well. If your
>> clients
>> >> are
>> >> looking for speed improvements and are not on Win2003 they should
>> >> try
>> it
>> >> out. Another thing to note is that usually when clients tell me one
>> >> protocol is faster than another I tend to find there is too much
>> chatter
>> >> from the client to the server in the first place. The more packets
>> sent
>> >> back and forth the more likely you will have performance issues
>> >> under
>> >> heavy
>> >> load.
>> >>
>> >> --
>> >> Andrew J. Kelly SQL MVP
>> >>
>> >>
>> >> "Bob Castleman" <nomail@.here> wrote in message
>> >> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> >> Why would one choose Named Pipes over TCP/IP for the client net
>> >> lib?
>> We
>> >> have
>> >> noticed for some of our customers that changing to named pipes
>> >> speeds
>> >> up
>> >> the
>> >> response times of our application. But it is my understanding that
>> >> a
>> >> properly configured LAN should work fine with TCP/IP.
>> >>
>> >> Thanks,
>> >>
>> >> Bob Castleman
>> >> SuccessWare Software
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>|||Bob,
Named-pipes is a "netbios" thing so it uses WINS (and LMHOSTS) to resolve
names.
TCP/IP Sockets uses DNS (and HOSTS).
Hence the reason DNS issues affect tcp-ip net-lib and not named-pipes net-lib.
(Even though both fundamentally run over tcp-ip. You can run named-pipes over
other protocols, but that's extremely rare these days)
Neil Pike MVP/MCSE. Protech Computing Ltd
Reply here - no email
SQL FAQ (484 entries) see
http://forumsb.compuserve.com/gvforums/UK/default.asp?SRV=MSDevApps
(faqxxx.zip in lib 7)
or www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
or www.sqlserverfaq.com
or www.mssqlserver.com/faqsql

Named pipes vs TCP/IP

Hi all.
We have a customer with some connection problems running Remote desctop
(Terminal server). In the startuplog of the SQL2000 server we can't find
anything else than:
2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
Pipes.
On our server we have the following started. What should we do to get the
server listening on the TCP/IP too? We think this could be the problem.
2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
Named Pipes.
Thanks all.
geirIs the IP netlib enabled (Server Network Utility)?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Geir Holme" <geir@.multicase.no> wrote in message news:u1OjFIJ5FHA.1032@.TK2MSFTNGP11.phx.gbl
..
> Hi all.
> We have a customer with some connection problems running Remote desctop
> (Terminal server). In the startuplog of the SQL2000 server we can't find
> anything else than:
> 2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
> Pipes.
> On our server we have the following started. What should we do to get the
> server listening on the TCP/IP too? We think this could be the problem.
>
> 2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
> 2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
> 2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
> Named Pipes.
>
>
> Thanks all.
> geir
>

named pipes vs tcp

Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
enable in network libraries. I noticed in EM under current activity and
process info for some processes named pipes is used and for other processes
something called LPC is used. Is LPC aka TCP/IP? It looks like when the
"host" for the process is the server, then it uses LPC but when the "host" i
s
a workstation it uses named pipes. Does it use named pipes for the
workstations because it is listed first in the network libraries? Is named
pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
second or just remove named pipes?
Thanks,
--
Dan D.Hi Dan
"Dan D." wrote:

> Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
> enable in network libraries. I noticed in EM under current activity and
> process info for some processes named pipes is used and for other processe
s
> something called LPC is used. Is LPC aka TCP/IP? It looks like when the
> "host" for the process is the server, then it uses LPC but when the "host"
is
> a workstation it uses named pipes. Does it use named pipes for the
> workstations because it is listed first in the network libraries? Is named
> pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
> second or just remove named pipes?
> Thanks,
> --
> Dan D.
LPC is a shared memory connection, that is why the host is the server
itself. The protocol used will be order by they are listed on the client, if
you client had TCP as the first protocol to use and the server has TCP/IP
enabled then that would be used. TCP/IP was made the primary protocol in SP3
a
so you may want to check what versions you are using. To see the client
protocols installed use the Client Networking Utility (on the client) there
are buttons that will let you change the order, and to check the for server
protocols use the Server Networking Utility on the server.
As far as speed, I believe they can be about the same, but with names pipes
there are potential security issues as you are connecting directly through
the filesystem of the server.
As far as removing named pipes, it is your choice.
John|||I understand. Thanks.
--
Dan D.
"John Bell" wrote:

> Hi Dan
> "Dan D." wrote:
>
> LPC is a shared memory connection, that is why the host is the server
> itself. The protocol used will be order by they are listed on the client,
if
> you client had TCP as the first protocol to use and the server has TCP/IP
> enabled then that would be used. TCP/IP was made the primary protocol in S
P3a
> so you may want to check what versions you are using. To see the client
> protocols installed use the Client Networking Utility (on the client) ther
e
> are buttons that will let you change the order, and to check the for serve
r
> protocols use the Server Networking Utility on the server.
> As far as speed, I believe they can be about the same, but with names pipe
s
> there are potential security issues as you are connecting directly through
> the filesystem of the server.
> As far as removing named pipes, it is your choice.
> John|||"Dan D." wrote:

> I understand. Thanks.
> --
> Dan D.
That is one of us then! I didn't realise it read so badly!
John

Named Pipes vs TCP

How would one go about adjusting the default connection to the SQL Server on the client side, using either Named Pipes or TCP as the default?Look for the Client Network Utility tool in the SQL Server program group. Or start->run CliConfig.exe.|||any way to pull of the defaulting programmatically??|||Yes, but the mechanics vary a lot depending on how you are programming. The easiest/surest way is to use the NETWORK parameter within DSN-Less connection strings (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnodbc/html/odbcsql.asp).

-PatP|||Looks like the ticket, thanks for your assistance...

named pipes vs tcp

Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
enable in network libraries. I noticed in EM under current activity and
process info for some processes named pipes is used and for other processes
something called LPC is used. Is LPC aka TCP/IP? It looks like when the
"host" for the process is the server, then it uses LPC but when the "host" is
a workstation it uses named pipes. Does it use named pipes for the
workstations because it is listed first in the network libraries? Is named
pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
second or just remove named pipes?
Thanks,
Dan D.
Hi Dan
"Dan D." wrote:

> Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
> enable in network libraries. I noticed in EM under current activity and
> process info for some processes named pipes is used and for other processes
> something called LPC is used. Is LPC aka TCP/IP? It looks like when the
> "host" for the process is the server, then it uses LPC but when the "host" is
> a workstation it uses named pipes. Does it use named pipes for the
> workstations because it is listed first in the network libraries? Is named
> pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
> second or just remove named pipes?
> Thanks,
> --
> Dan D.
LPC is a shared memory connection, that is why the host is the server
itself. The protocol used will be order by they are listed on the client, if
you client had TCP as the first protocol to use and the server has TCP/IP
enabled then that would be used. TCP/IP was made the primary protocol in SP3a
so you may want to check what versions you are using. To see the client
protocols installed use the Client Networking Utility (on the client) there
are buttons that will let you change the order, and to check the for server
protocols use the Server Networking Utility on the server.
As far as speed, I believe they can be about the same, but with names pipes
there are potential security issues as you are connecting directly through
the filesystem of the server.
As far as removing named pipes, it is your choice.
John
|||I understand. Thanks.
Dan D.
"John Bell" wrote:

> Hi Dan
> "Dan D." wrote:
>
> LPC is a shared memory connection, that is why the host is the server
> itself. The protocol used will be order by they are listed on the client, if
> you client had TCP as the first protocol to use and the server has TCP/IP
> enabled then that would be used. TCP/IP was made the primary protocol in SP3a
> so you may want to check what versions you are using. To see the client
> protocols installed use the Client Networking Utility (on the client) there
> are buttons that will let you change the order, and to check the for server
> protocols use the Server Networking Utility on the server.
> As far as speed, I believe they can be about the same, but with names pipes
> there are potential security issues as you are connecting directly through
> the filesystem of the server.
> As far as removing named pipes, it is your choice.
> John
|||"Dan D." wrote:

> I understand. Thanks.
> --
> Dan D.
That is one of us then! I didn't realise it read so badly!
John

named pipes vs tcp

Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
enable in network libraries. I noticed in EM under current activity and
process info for some processes named pipes is used and for other processes
something called LPC is used. Is LPC aka TCP/IP? It looks like when the
"host" for the process is the server, then it uses LPC but when the "host" is
a workstation it uses named pipes. Does it use named pipes for the
workstations because it is listed first in the network libraries? Is named
pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
second or just remove named pipes?
Thanks,
--
Dan D.Hi Dan
"Dan D." wrote:
> Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
> enable in network libraries. I noticed in EM under current activity and
> process info for some processes named pipes is used and for other processes
> something called LPC is used. Is LPC aka TCP/IP? It looks like when the
> "host" for the process is the server, then it uses LPC but when the "host" is
> a workstation it uses named pipes. Does it use named pipes for the
> workstations because it is listed first in the network libraries? Is named
> pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
> second or just remove named pipes?
> Thanks,
> --
> Dan D.
LPC is a shared memory connection, that is why the host is the server
itself. The protocol used will be order by they are listed on the client, if
you client had TCP as the first protocol to use and the server has TCP/IP
enabled then that would be used. TCP/IP was made the primary protocol in SP3a
so you may want to check what versions you are using. To see the client
protocols installed use the Client Networking Utility (on the client) there
are buttons that will let you change the order, and to check the for server
protocols use the Server Networking Utility on the server.
As far as speed, I believe they can be about the same, but with names pipes
there are potential security issues as you are connecting directly through
the filesystem of the server.
As far as removing named pipes, it is your choice.
John|||I understand. Thanks.
--
Dan D.
"John Bell" wrote:
> Hi Dan
> "Dan D." wrote:
> > Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
> > enable in network libraries. I noticed in EM under current activity and
> > process info for some processes named pipes is used and for other processes
> > something called LPC is used. Is LPC aka TCP/IP? It looks like when the
> > "host" for the process is the server, then it uses LPC but when the "host" is
> > a workstation it uses named pipes. Does it use named pipes for the
> > workstations because it is listed first in the network libraries? Is named
> > pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
> > second or just remove named pipes?
> >
> > Thanks,
> > --
> > Dan D.
> LPC is a shared memory connection, that is why the host is the server
> itself. The protocol used will be order by they are listed on the client, if
> you client had TCP as the first protocol to use and the server has TCP/IP
> enabled then that would be used. TCP/IP was made the primary protocol in SP3a
> so you may want to check what versions you are using. To see the client
> protocols installed use the Client Networking Utility (on the client) there
> are buttons that will let you change the order, and to check the for server
> protocols use the Server Networking Utility on the server.
> As far as speed, I believe they can be about the same, but with names pipes
> there are potential security issues as you are connecting directly through
> the filesystem of the server.
> As far as removing named pipes, it is your choice.
> John|||"Dan D." wrote:
> I understand. Thanks.
> --
> Dan D.
That is one of us then! I didn't realise it read so badly!
Johnsql

Named Pipes or TCP IP in LAN

I have read that Named pipes work faster/better in a LAN environment ? I
have a question.. so would it make sense if the Web Servers (IIS on Windows
2000) that talk to the database servers on the same LAN communicate via
Named pipes as opposed to TCPIP . Also same with regards to the business
tier thats also on the same LAN that talks to the databases that can
communicate using Named pipes
Please provide your inputs here . Currently we use TCPIP. Using SQL 2000HASSAN AFTER READING THIS YOU BE THE JUDGE
Named Pipes vs. TCP/IP Sockets
In a fast local area network (LAN) environment, Transmission Control
Protocol/Internet Protocol (TCP/IP) Sockets and Named Pipes clients are
comparable in terms of performance. However, the performance difference
between the TCP/IP Sockets and Named Pipes clients becomes apparent with
slower networks, such as across wide area networks (WANs) or dial-up
networks. This is because of the different ways the interprocess
communication (IPC) mechanisms communicate between peers.
For named pipes, network communications are typically more interactive. A
peer does not send data until another peer asks for it using a read command.
A network read typically involves a series of peek named pipes messages
before it begins to read the data. These can be very costly in a slow
network and cause excessive network traffic, which in turn affects other
network clients.
It is also important to clarify if you are talking about local pipes or
network pipes. If the server application is running locally on the computer
running an instance of Microsoft SQL ServerT 2000, the local Named Pipes
protocol is an option. Local named pipes runs in kernel mode and is
extremely fast.
For TCP/IP Sockets, data transmissions are more streamlined and have less
overhead. Data transmissions can also take advantage of TCP/IP Sockets
performance enhancement mechanisms such as windowing, delayed
acknowledgements, and so on, which can be very beneficial in a slow network.
Depending on the type of applications, such performance differences can be
significant.
TCP/IP Sockets also support a backlog queue, which can provide a limited
smoothing effect compared to named pipes that may lead to pipe busy errors
when you are attempting to connect to SQL Server.
In general, sockets are preferred in a slow LAN, WAN, or dial-up network,
whereas named pipes can be a better choice when network speed is not the
issue, as it offers more functionality, ease of use, and configuration
options.
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:ORNMyEE8DHA.3360@.tk2msftngp13.phx.gbl...
> I have read that Named pipes work faster/better in a LAN environment ? I
> have a question.. so would it make sense if the Web Servers (IIS on
Windows
> 2000) that talk to the database servers on the same LAN communicate via
> Named pipes as opposed to TCPIP . Also same with regards to the business
> tier thats also on the same LAN that talks to the databases that can
> communicate using Named pipes
> Please provide your inputs here . Currently we use TCPIP. Using SQL 2000
>

Named Pipes or TCP IP in LAN

I have read that Named pipes work faster/better in a LAN environment ? I
have a question.. so would it make sense if the Web Servers (IIS on Windows
2000) that talk to the database servers on the same LAN communicate via
Named pipes as opposed to TCPIP . Also same with regards to the business
tier thats also on the same LAN that talks to the databases that can
communicate using Named pipes
Please provide your inputs here . Currently we use TCPIP. Using SQL 2000HASSAN AFTER READING THIS YOU BE THE JUDGE
Named Pipes vs. TCP/IP Sockets
In a fast local area network (LAN) environment, Transmission Control
Protocol/Internet Protocol (TCP/IP) Sockets and Named Pipes clients are
comparable in terms of performance. However, the performance difference
between the TCP/IP Sockets and Named Pipes clients becomes apparent with
slower networks, such as across wide area networks (WANs) or dial-up
networks. This is because of the different ways the interprocess
communication (IPC) mechanisms communicate between peers.
For named pipes, network communications are typically more interactive. A
peer does not send data until another peer asks for it using a read command.
A network read typically involves a series of peek named pipes messages
before it begins to read the data. These can be very costly in a slow
network and cause excessive network traffic, which in turn affects other
network clients.
It is also important to clarify if you are talking about local pipes or
network pipes. If the server application is running locally on the computer
running an instance of Microsoft® SQL ServerT 2000, the local Named Pipes
protocol is an option. Local named pipes runs in kernel mode and is
extremely fast.
For TCP/IP Sockets, data transmissions are more streamlined and have less
overhead. Data transmissions can also take advantage of TCP/IP Sockets
performance enhancement mechanisms such as windowing, delayed
acknowledgements, and so on, which can be very beneficial in a slow network.
Depending on the type of applications, such performance differences can be
significant.
TCP/IP Sockets also support a backlog queue, which can provide a limited
smoothing effect compared to named pipes that may lead to pipe busy errors
when you are attempting to connect to SQL Server.
In general, sockets are preferred in a slow LAN, WAN, or dial-up network,
whereas named pipes can be a better choice when network speed is not the
issue, as it offers more functionality, ease of use, and configuration
options.
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:ORNMyEE8DHA.3360@.tk2msftngp13.phx.gbl...
> I have read that Named pipes work faster/better in a LAN environment ? I
> have a question.. so would it make sense if the Web Servers (IIS on
Windows
> 2000) that talk to the database servers on the same LAN communicate via
> Named pipes as opposed to TCPIP . Also same with regards to the business
> tier thats also on the same LAN that talks to the databases that can
> communicate using Named pipes
> Please provide your inputs here . Currently we use TCPIP. Using SQL 2000
>|||Another thing to consider with Named Pipes is that the
user's Windows user accounts must have permission to
establish a NetBEUI connection to the Windows box that
SQL Server is running on. This is not the case when
using TCP/IP Sockets.
Just out of curiosity, where did you read that Named
Pipes was faster/better in a LAN environment? The last
time I experienced Named Pipes to be noticeably faster
was with a 16 bit client.
Matthew Bando
matthew.bando@.CSCTGI(Remove this).com
>--Original Message--
>I have read that Named pipes work faster/better in a LAN
environment ? I
>have a question.. so would it make sense if the Web
Servers (IIS on Windows
>2000) that talk to the database servers on the same LAN
communicate via
>Named pipes as opposed to TCPIP . Also same with regards
to the business
>tier thats also on the same LAN that talks to the
databases that can
>communicate using Named pipes
>Please provide your inputs here . Currently we use
TCPIP. Using SQL 2000
>
>.
>

Named Pipes

I am using TCP/IP for my network protocol. Is there any
need to use Named Pipes? I would like to remove this
protocol in SQL Server Network Utility.
Thank you.There's really no reason to remove it. It gives you an alternate IPC to
connect to the server with if for example we're unable to bind to the TCP
port. MDAC 2.6 clients then also have alternate means to connect to your
server. If they attempt to connect via sockets and fail, the client
transparently will attempt making a Named Pipe connection. This is of
great benefit to users who are no interested in how SQL connects, just that
it connects.
If your SQL Server is behind a firewall, the firewall should be configured
to only allow the tcp traffic for SQL. There's no additional overhead on
the server to listen on both netlibs.
If you're using a SQL Cluster then you won't be able to remove Named Pipes
after applying sp3.
831127 Named Pipes Support Cannot Be Removed on a Virtual Server That Is
http://support.microsoft.com/?id=831127
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||If the SQL instance runs in a cluster, Microsoft advises
you not to remove the support for named pipes. Otherwise,
bad things can happen (See KB article 831127).
Also check out KB 818806 -- Some Named Pipes Features Are
Not Disabled After You Disable the Named Pipes Protocol.
I hate to run into an unexpected dependency at a most
inconvenient time, and have chosen to keep both named
pipes and TCP sockets as a standard.
Do you have any specific reasons for preventing SQL Server
from listening on named pipes?
Linchi

quote:

---

>--Original Message--
>I am using TCP/IP for my network protocol. Is there any
>need to use Named Pipes? I would like to remove this
>protocol in SQL Server Network Utility.
>Thank you.
>.
>

---

|||Kevin;

quote:

---

> If they attempt to connect via sockets and fail,
> the client transparently will attempt making a
> Named Pipe connection. This is of

---

What are the exactly conditions for this 'transparent
attempt of making a Named Pipe connection' to occur? What
are scenarios in which this transparent attempt will not
be 'attempted'? I'm thinking about the situation when you
use a server alias or prefix your server name with 'tcp:'.
Linchi

quote:

---

>--Original Message--
>There's really no reason to remove it. It gives you an

---

alternate IPC to

quote:

---

>connect to the server with if for example we're unable to

---

bind to the TCP

quote:

---

>port. MDAC 2.6 clients then also have alternate means to

---

connect to your

quote:

---

>server. If they attempt to connect via sockets and fail,

---

the client

quote:

---

>transparently will attempt making a Named Pipe

---

connection. This is of

quote:

---

>great benefit to users who are no interested in how SQL

---

connects, just that

quote:

---

>it connects.
>If your SQL Server is behind a firewall, the firewall

---

should be configured

quote:

---

>to only allow the tcp traffic for SQL. There's no

---

additional overhead on

quote:

---

>the server to listen on both netlibs.
>If you're using a SQL Cluster then you won't be able to

---

remove Named Pipes

quote:

---

>after applying sp3.
>831127 Named Pipes Support Cannot Be Removed on a Virtual

---

Server That Is

quote:

---

>http://support.microsoft.com/?id=831127
>
>Thanks,
>Kevin McDonnell
>Microsoft Corporation
>This posting is provided AS IS with no warranties, and

---

confers no rights.

quote:

---

>
>.
>

---

name pipe VS tcpip

I found that I can only use name pipe to connect to the sql server.
When I use tcpip, it fails to connect.
I am sure I have enabled the TCP/IP protocol in SQL server
What causes it?
sql is using port no.1433 and I have try using dynamically determine port
and force it to 1433 in ODBC setting.
thank you very much
"!" <!@.!.!> wrote in message news:%236FqHb0qEHA.3416@.TK2MSFTNGP15.phx.gbl...
> I found that I can only use name pipe to connect to the sql server.
> When I use tcpip, it fails to connect.
> I am sure I have enabled the TCP/IP protocol in SQL server
> What causes it?
> sql is using port no.1433 and I have try using dynamically determine port
> and force it to 1433 in ODBC setting.
There are a lot of reasons that this can fail, application type being one of
them. Reference the following as a troubleshooting guide:
http://support.microsoft.com/default...b;en-us;827422
Steve