We help IT Professionals succeed at work.

PHP 4.4.4, Apache 2.0.x and MS SQL 2005 SLOW/Performance Issues

jgantes asked
Medium Priority
Last Modified: 2013-12-13
We just moved from MySQL to MS SQL ... It was a group decision based on our dept. needs.  

When we hosted MySQL previously it was on the same machine as Apache and was lightning fast.

Now that we've moved to MsSQL 2005 on a remote machine (still local network) with Apache our site are ALL super slow.

I have run any checks, but I have done some reading and it seems these is a common problem.

Pages w/o SQL are still quick and without delay.  I'm not too found of the soon to become extinct DLL that allows for connectivity between PHP in Windows w/ Apache and MS SQL.  But I don't think that's the problem (or could it be?).

Our PHP queries are simple... Select * which returns maybe 10 lines.  I'd say it's at least twice as slow, if now worse.

Any ideas?

Watch Question

Guy Hengel [angelIII / a3]Billing Engineer
Most Valuable Expert 2014
Top Expert 2009


I have a similar problem with having mysql on another domain than the web server with asp.net + c# + mysql 4...


I can't figure it out for the life of me...  It's slow as heck.  It can't JUST be that it's remote.  The servres are each Core DUO w/ 3GB RAM on their own Gigabit switch.  

And if you're having issues with MY SQL and not MS SQL, that says that maybe it's a PHP windows or Apache issue?


Interesting... We rebooted and it was still slow.  But now, a day later, it's quick agian.  I can't figure this out!!  It must be something to do with Apache or PHP
Senior Software Developer
I'm been using PHP5 with Sambar Server and MS SQL 2000 (Developer Edition locally and Enterprise Edition in production).

I used to use the php_mssql.dll extension, but this was just too flawed.

Instead, I use the ODBC mechanism.

I have a simple OOP factory to wrap MS SQL, MS Access and Sage Retrieve 4GL databases.

Whilst ODBC is NOT the best way to go, it does provide a simple route for me.

In terms of performance, I'm very happy with it.

I DO use persistent connections.

I ALWAYS put the full table names in the SQL statements (db.owner.table) rather than just the table name as I have multiple SQL servers with multiple databases but using the same connection credentials.

I make use of views and stored procedures where appropriate. I also run the Index Optimizer on the queries on a semi regular basis to see if I can increase performance of the server.

Persistent connections are probably going to help and not using plain CGI (I think FastCGI for Apache supports persistent database connections).


Other than that, just the usual stuff.

1 - Always make sure you name ALL the columns you NEED. Don't use SELECT * as this is wasteful.
2 - Take care when making joins to make sure you select the smallest amount of data on the left before you start joining/filtering. Not 100% sure that this makes any real difference any more for MSSQL, but certainly does for Access and Sage DBs. I can restructure the joins on a query and make it VERY VERY slow with Access - even though the results are 100% identical.
3 - Run the optimizer to make sure you have appropriate indexes available to speed the query.
4 - Sort the data only if needed - I was surprised to see how often I did not need the results sorted.
5 - Make sure the SQL server has access to as much RAM and Processors as possible.
6 - Make sure you have the right licenses for SQL server - too many connections may either result in a slow down on the server or no access!
7 - Do not run the development dbs on the same server as production as the memory will be effectively shared between the DBs. Sure, LRU and MRU mechanisms are in place but for the same of £35 for the 5 user Developer Edition, it sure isn't worth the hassle and slow down.
8 - Don't have compression enabled on the SQL data storage! You'd be surprised the number of times I've seen customers being cheap on upgrading disk space and have enabled compression and just how nicely SQL MDF/LDFs compress! Joy!
9 - Something I read, but have not been able to adequately test ... If your DB is read only with regard to a specific application, then use a db_readonly/db_denywrite role. I've read that this makes certain improvements, but I'm not sure (and I can't find the link - sorry).

Hope that helps some.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


There doesn't seem to be a concrete answer (so far) on this issue.  So thanks for the help RQ!
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.