Hello! 🙂 I'd sent this mail the the php-win mailing list but wasn't able to get any advice over there, so I thought I'd give this board a try....

I've run into a problem where connecting to our MSSQL Server from our webserver using a TCP/IP connection is a -whole- lot slower than connecting to the same server using a Named Pipes connection (we're talking 10 to 20 times slower).

We are running SQL server on a non-standard port (1533 vs 1433). I do believe we had tried running it on port 1433 and still had the slowdown though.

In the Client Configuration utility on the WEB server I use the following settings:

Server Alias: mssql_named_pipes
Network Library: Named Pipes
Connection parameters: \sqlserver\pipe\sql\query

Server Alias: mssql_tcpip
Network Library: TCP/IP
Connection parameters: 192.168.1.7,1533

I want to make sure to point out that everything -does- operate fine when using the TCP/IP connection - it's just extremely slow.

We've tried connecting to other MSSQL servers and ran into the same problems where it will run fast when using Named Pipes, but slow when using TCP/IP.

Here is are 3 benchmarks of just the mssql_connect() between Named Pipes and TCP/IP versions so you can see how much slower it is. This is a sample of running
it three times (I've run this from the web and from command line and gotten the same results both times):

Named Pipes took 13.3231ms
TCP/IP took 205.6559ms

Named Pipes took 12.3510ms
TCP/IP took 174.2430ms

Named Pipes took 13.2550ms
TCP/IP took 149.0561ms

Here's the code that generated the above:

-- snip snip --

function DoBenchmark( $name, $server, $numtimes )
{
$start_time = getmicrotime();
for ( $i = 0; $i < $numtimes; ++$i ) {
$link_id = mssql_connect( $server, DATABASE_USER, DATABASE_PASSWORD );
if ( !$link_id )
exit;
mssql_close( $link_id );
}
$total_ms = ( getmicrotime() - $start_time ) * 1000;
printf( "$name took %.4fms<br>", $total_ms );
}

function getmicrotime()
{
list( $usec, $sec ) = explode( " " , microtime() );
return (float)$usec + (float)$sec;
}

DoBenchmark( "Named Pipes", "mssql_named_pipes", $runs );
DoBenchmark( "TCP/IP", "mssql_tcpip", $runs );

-- snip snip --

Finally, here's the web server and sql server information:

SQL Server OS: Win2K Server SP1
SQL Version: MSSQL 7.0

WEB Server OS: Win2K Server SP2
WEB Server PHP: PHP 4.0.6 w/ latest extensions
WEB Server: IIS 5.0

We are using PHP in CGI mode.

The PHP.exe is compiled in-house, however there are no MSSQL related changes in our version.

Here are the results of "php -m":

Running PHP 4.0.6
Zend Engine v1.0.6, Copyright (c) 1998-2001 Zend Technologies
with Zend Optimizer v1.1.0, Copyright (c) 1998-2000, by Zend Technologies

[PHP Modules]
standard
bcmath
Calendar
com
variant
ftp
mysql
odbc
pcre
session
xml
wddx
gd
mssql
Zend Optimizer

[Zend Modules]
Zend Optimizer

--

From what I've been reading it sounds like there are a good number of people who successfully use TCP/IP connections to MSSQL, so it sounds like I may just be doing something wrong - I just don't know what.

I hope that explains the problem. All I want is to be able to connect to the MSSQL server using TCP/IP and not suffer the slowdowns we're currently suffering 🙂

Thanks in advance for any help.

-Jah

    At a risk of insulting your inetllegence have you tried the following

    Remove any unnessary protocals and services, file and print sharing,move the servers from a domain based config to workgroup based config.

    First in
    %windowsRoot%\system32\drivers\etc\ there is a list of the following files
    hosts
    networks
    protocal
    services
    lmhosts.sam

    Edit the networks file using word or note pad
    add the ip address of your winboxes ethernet card and the host name
    add the ip address of the other winbox ethernet card and the host name

    In Networks
    add the entwork range that your boxes share
    ie 192.168.0

    In Services
    Add the Service name and port number the service resides

    Apply the same for the second box

    Reboot the servers.

    If its still slow, you might want to invest in at least two, if not four additional nic cards, and use a cross over cable(s) to connect each box. 3com has a relitivly cheap card (90 bucks us) that allows for ip teaming. You can set one a pair tp push and a set to pull data across the set.

    Jah Raphael wrote:

    Hello! 🙂 I'd sent this mail the the php-win mailing list but wasn't able to get any advice over there, so I thought I'd give this board a try....

    I've run into a problem where connecting to our MSSQL Server from our webserver using a TCP/IP connection is a -whole- lot slower than connecting to the same server using a Named Pipes connection (we're talking 10 to 20 times slower).

    We are running SQL server on a non-standard port (1533 vs 1433). I do believe we had tried running it on port 1433 and still had the slowdown though.

    In the Client Configuration utility on the WEB server I use the following settings:

    Server Alias: mssql_named_pipes
    Network Library: Named Pipes
    Connection parameters: \sqlserver\pipe\sql\query

    Server Alias: mssql_tcpip
    Network Library: TCP/IP
    Connection parameters: 192.168.1.7,1533

    I want to make sure to point out that everything -does- operate fine when using the TCP/IP connection - it's just extremely slow.

    We've tried connectin....

      Thanks for the advice, Terry. I hadn't tried modifying the networks and services files on the machines - I'll give that a whirl.

      It doesn't really feel like this would be the problem though, because was have another application on the same webserver (written in ASP) that connects to the same DB server using TCP/IP, and it doesn't experience the slowdowns that we're getting with PHP.

      I've encountered the same problem (slow TCP/IP access) on two separate Web Server and DB Server boxes on three different networks. I've run into the problem with both PHP 4.0.5, and PHP 4.0.6.

      We've tried this on both a Domain and a Workgroup.

      We've made sure that the webserver isn't trying to do a dns lookup of the db server.

      Anyways.

      Thanks.

      -Jah

        2 months later

        i suffer the same problem. when the web server(IIS) and MS SQL server are installed in the same machine, the connection is very fast. When i separate Web server and DB server, the connection is extremely slow!!

        My config:
        web server machine:
        IIS 5.0 + Win 2k + php4.0.6 (CGI version)

        MS SQL server:
        MS SQL server 2000 + Win 2k

        P.S. all are connected via TCP/IP
        Tommy Cheung

          Did you read the privious ideas for a solution?

          My suggestion is to add another nic to both computers and use a cross over cable (if possible) to link the two computers via a seperate subnet

          Additionally, you may want to look at your hub/switch and see if it is "smart" YOu problem may be that your Winbox is trying to send its data to your switch, then to your router only to have it travel back to the computer with the SQL Server. If you have a programible switch you can add a static route or list table for those two machines so they are not hunting across the wide area network (or internet.. in some cases) to find the other Box.

          If i knew more about your network, I might be abel to make another stab at it. It tio me seems like your packets are routing all over the place.

            I haven't spent much time looking into this recently, but I'm not sure if I was clear enough in my previous post on the point that ONLY TCP/IP access is slow. If you use Named Pipes (which operate over SMB, I believe [I've watched network traffic to see this]...) then you will not suffer the slowdown. Therefore: Even though you're using named pipes, you're still communicating across the same NIC, which would lead me to believe the NIC is fully operational (besides, I can do any other TCP/IP access between the machines without problem - only when trying to connect through the PHP MSSQL module is there a problem).

            I've had the same slowdown issue with TCP/IP on several different network setups, with different hubs and different switches, even with different DB and client computers (therefore different NICs).. And in each case ONLY TCP/IP access is slow (and I'm not talking about a fake kinda slow - this is significantly slow - like we cannot use TCP/IP for production or even development because it's so slow).

            To me it feels like some sort of PHP MSSQL module problem (I know this just uses the MS DB library, so I wouldn't really know where the problem lies....)

            Anyone other than Tommy Cheung had this problem? And fixed it?

            -Jah

              Hi Terry and Jan!

              my network setting is very simple:
              3 PCs all are connected via cross-cable (no hub/switch)

              1. Web server machine:

              2. 2 NICs (to DB server and Dev machine)

              3. DB server machine:

              4. 1 NIC (to web server machine)

              5. Dev machine:

              6. 1 NIC (to web server machine)

              i tested the DB connection using TCP/IP is extremely slow (usually timeout). But the DB connection using named pipes is extremely fast.

              i already ping all machines and no problem is found with the network. i suspected it may be some problems with php_mssql.dll...

                a month later

                You've probably given up on this, but anyway: we had the same problem - SQL-Server TCP/IP connection to a server - 4 or 5 seconds to open a connection - otherwise everything worked fine.

                We traced it down to some kind of weird name-resolution issue in the client-network utility. If we connected to 10.0.0.6 it took 5 seconds. If, however, we added an entry to our hosts file with SERVER6 10.0.0.6 and then connected to SERVER6, it was instantaneous.

                Hope that helps!

                  Ooh... another reply!

                  I'd pretty much gotten too busy to think about this problem, and had moved on to other things (We ended up just having the client used Named Pipes until the TCP/IP issue could be resolved).

                  I'll give your advice a whirl.

                  Thanks!

                  -Jah

                    7 months later

                    THANK YOU!!! This fixed our problem!!

                      Write a Reply...