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
>
>.
>
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment