Speed of php scripts

I can’t for the life of me understand why my scripts are taking so long to run on a dedicated server. The server has more resources than the private server that I was using previously.

I had this problem with a WordPress install on another account, but it turned out to be bad directories…

My current site is all handwritten, and it screams on my dedicated server at my house, it is taking in some cases more than 3 minutes, then timeout on a page that serves in about 5 seconds on my private dedicated server.

Can someone point me in any direction - I don’t even know the question to ask.

There are so many things that may be wrong :slight_smile: It will take a bit of patience and communication but here are some ideas you can start listing to give us more clues. You can start by identifying the differences in the two environments you’re testing in: which versions of PHP (is it PHP?) running on both servers? Can you share the source code? are the scripts querying a database and are the database identical in the two environments? Do you know how to use debugging tools to identify bottlenecks? Hardware-wise, what are the differences between the two servers, RAM, disk and CPU?

Let’s start from here, there may be more questions down the road.

Hardware on my server is actually 12GB of memory vs 16GB with DreamHost. Other than that I am leary and scared about installing any type of php debugger (the last setup I had with DreamHost I had to have them re-image and it cost me…)

Maybe you could point me in a direction.

specifically one file: pulls a report and has multiple loops. it is the biggest hog on my local setup taking up to 10 seconds to run.

It uses fpdf library to generate a report as such:

mysqli_query(…,“SELECT * FROM employees”)
while ($row=mysqli_fetch_assoc($result)) {
for 1-7 {
for 1-7 {
loop {

I know it’s just skeletons, and I will be the first to admit that ALL my code could be tuned, it’s just way to slow right now and pages timeout.

I have to get it running - at least to sub-par speed before I can go page to page and optimize everything.

So - in short, there is something big I’m missing here… I appreciate the response.

You know, as I was posting a reply it hit me to just do a time test on the MySQL connects… that’s where it went bad…

I changed the connects to:
function db () {
static $conn;
if ($conn===NULL){
$conn = mysqli_connect (“host”, “usr”, “pas”, “database”);
return $conn;

function someFunction () {
$conn = db();
$result = mysqli_query ($conn, "SELECT * FROM examples);

instead of opening and closing connections… I know - I knew my code def needed touching up - it was a prototype gone production a bit too early, so I am not surprised nor offended when someone tells me to touch up my code…

The absolute BOTTLENECK shown here at db connects leads me to a few questions:

  1. should I transfer the database to my server, and not use dreamhosts dbase server?

  2. What are the tools that you - or anyone - would use to trace the PHP stack / calls in a Dream Host env?

It’s a start, good thing you caught it.

I wouldn’t know what to suggest here because all the profilers I can think of require root (or at least I think they do). If you are familiar with one already like xdebug or XHProf/XHGui or New Relic, you may ask Support if these can be installed on your dedicated. You should be able to simply disable them when you’re done.

On another note, it’s hard to tell if the mysql_conn through the network is adding time: I guess it could add something but not minutes. Another thing you may want to ask Support is to double-check that there is nothing wrong or huge network traffic between your dedi and the mysql DB host.

Also go to Dreamhost Panel > Support > Data Centers and check to make certain the mysql server is located in the same physical data center as your dedicated server. If not, tell support so they can fix that but moving your databases to a server in whatever physical location the dedicated is located.

That was the problem… MySQL was on another server - support moved it and POOF!

The good news is - the days I spent trying to isolate the bottleneck has resulted in much tighter code :slight_smile:

Thank you all - and DreamHost!