How do you know if poor performace is because of bad code or a bad server?

[jimmymjb2]

So I'm in the middle of building a custom cms for a client whose site is hosted over at Network Solutions. I've had a lot of trouble with the way they run things, but can't be sure whether I have done everything on my end to get things running well.

 

The site is primarily built in php talking to a mysql db. Sometimes when I submit a form the server just seems to hang and the loading animation goes on for a very long time (sometimes I give up on waiting, because it takes so long). Other times I will submit the same forms and the results are returned almost immediately. My question is, how do I know if my code is the problem? Can php code run perfectly on one execution then run very poorly on another execution if the code isn't written well or is this just a case of a bad server?

[Zyx]

For experienced programmers, a closer look at the source code is often enough to get an idea about the general performance. If the application is overloaded with unnecessary stuff and poorly designed, it can be nondeterministic, because the code was so complex and twisted that the programmer lost his orientation and didn't know what he was actually writing.

 

There is a quite simple test to check the server - install the application somewhere else and check if it hangs there, too.

[roopurt18]

You should be developing locally under "ideal" conditions, where ideal represents your development box that has all of the necessary servers / services running on localhost.  Under these conditions everything should be lightning fast.

 

Then when you move to the production server you can accommodate for any short-comings of the server.

[whansen02]

Sometimes when I submit a form the server just seems to hang and the loading animation goes on for a very long time (sometimes I give up on waiting, because it takes so long). Other times I will submit the same forms and the results are returned almost immediately.

 

If something as simple as submitting a form is hanging - ruling out local system delay I would almost certainly think the script was performing fine and the web server was under heavy load.  Unless I knew that some large mysql queries were going on which might perform quickly if results were cached and wouldn't go quickly when it had to dig data out again.  What do your queries look like?  How large is the database? How many rows and data fields are in the tables you're querying when the form gets submitted?  If you're using lots of joins or querying massive tables, grabbing more results and data than needed, that could be an issue.

 

If delays are happening more when submitting data than when retrieving data it's likely server load. Mysql is likely waiting for it's turn to write the data changes to the hard disk.

[jimmymjb2]

Thanks for all of the input. This problem is really bugging me. The client has agreed to move the site to another, more robust server and I just want to be sure that its not my code before that happens.

 

Normally, as you mentioned, I try to do all of my development locally. This time however, the client was on such a time crunch that he wanted it deployed for testing much earlier. I did what I could to make the site portable, with no hard coded links but the server Ive put this on handles the .htaccess in a way that is extremely hard to deal with. So after I built things to accommodate that, I found lots of things wouldn't work on my own server (the site runs on SEO friendly links; everything generated by an index.php talking to the db). I know I could get it working locally, I just don't have a minute of spare time.

 

I'm still going to see if I can find the time to set up a local copy, because what has been said so far makes a lot of sense.

 

As far as what kind of stuff I'm passing back and forth to the database, it's really not much at all. In fact I just had it hang on the creation of a user group. The code that handles that is under a hundred lines once all the extra line breaks and comments are removed.

 

Here is a portion of the group creation query:

$errors = array();

// create a list of required fields and place them in an array
$required_fields = array('groupname');
$errors = array_merge($errors, check_required_fields($required_fields, $_POST));     
        
//handles whitespace and special characters using custom function mysql_prep in functions.php
$groupname   = trim(mysql_prep($_POST['groupname']));
$createfolder  =  $_POST['folder'];
$createforum  =  $_POST['forum'];
$adduser        =  $_POST['adduser'];
$group_type   = $_POST['grouptype'];
if (isset($_POST['adduser'])){$hasmembers = 1;}
else {$hasmembers = 0 ;}              
      
//If there are no errors, send the form data to the database
if ( empty($errors) ) {
     $query = "INSERT INTO groups ( group_name, group_members, group_type ) 
                      VALUES ( '{$groupname}','{$hasmembers}','{$group_type}' )";            
                      $result = mysql_query($query, $connection);
                                      if ($result) //if everything worked, send a message 
                                          {echo "Group was created.";}
                                      else  //if there was a problem with the database, tell me about it
                                          {$dbproblem =  mysql_error(); echo "There was a problem: ".$dbproblem."<br />";}} 

 

That script goes on to add members to the group, create a folder, etc. All of it generally looks like this though; just a few things being added to or pulled from the database. Today, simply loading a page returned a "MySql Server Has Gone Away" error and the only query that page makes is what group the current user is associated with.

 

The database itself is relatively small. It has 13 tables, the largest table has 19 fields but most have 6 or less.

 

Could it be too many includes or accidentally doing a require_once twice; something stupid like that? Or maybe a 'die' placed at the end of one query in a list of separate queries? I'm still pretty new to this so I'm going to assume its my fault until I can prove myself wrong. Plus I would definitely relate to the situation Zyx described. The time table this guy has me on is insane. I've been working 24-30+ hour days to build a custom cms in a month, with shared folders a forum, etc. I'm really tired and I know I am leaving a lot of sloppy code behind.

 

Thanks again guys, this has me a bit freaked out. I really don't want to go through all this and have him move to a dedicated server only to have my code be the problem. And like I said; not a lot of time to figure it out. So any more insight you would care to share, I would be extremely grateful.

 

[roopurt18]

Today, simply loading a page returned a "MySql Server Has Gone Away" error and the only query that page makes is what group the current user is associated with.

As long as your code isn't doing something fuddy-duddy like losing the database link or connecting to the database multiple times in a single execution, then I would associate this with the server being shared and possibly overloaded.  Again, you'd have to make sure that you're not killing the database connection prematurely yourself.  And you'd also have to make sure that one HTTP request to the site doesn't make multiple connections to the database.

 

Could it be too many includes or accidentally doing a require_once twice; something stupid like that? Or maybe a 'die' placed at the end of one query in a list of separate queries?

I don't think it would be the number of includes so much as what's in them that would cause these problems.  Many people connect to the db with a db.php and use include( 'db.php' ).  Are you doing this?  Does it connect to the database again even if a connection has been established? 

 

Mulitple require_once() on the same file is, IMO, unlikely to cause you severe issues; the performance hit would be more like milliseconds. 

 

die() kills the script right then and there; nothing else executes afterward.  Not sure if that helps you.

 

I really don't want to go through all this and have him move to a dedicated server only to have my code be the problem

Even more reason to set it up locally in a controlled environment.  Dedicated servers can run $200 per month.  Your time to install it locally might equate to  one to three months of dedicated server costs.  If the dedicated server turns out to be unnecessary, it would be more cost effective to your client to let you take the time to do this.

 

For your sanity's sake, I suggest in future projects you make it part of the contract that you will develop locally and push releases to a test environment of the client's choosing.  If the client will not provide a local environment for you, then you will use your PC as that environment.  You'll be able to gauge your application's hardware requirements and your client will be able to test release for stability and acceptable performance.  If they won't let you work in this manner, let some other sucker work for them. 

[corbin]

Have you tried doing some benchmarking?  It might be kind of ghetto, but you could temporarily just throw in some code to time some specific parts of code.

[Daniel0]

die() kills the script right then and there; nothing else executes afterward.

 

That's not true. Object destructors and shutdown functions will still run after a call to die() or exit().

 

daniel@daniel-laptop:~$ cat test.php
<?php
class Foo
{
public function __destruct()
{
	echo 'Destruct: ' . __CLASS__ . PHP_EOL;
}
}

function shutdown()
{
echo 'Shutdown: ' . __FUNCTION__ . PHP_EOL;
}

$foo = new Foo();
register_shutdown_function('shutdown');

die();
echo 'This will not be output.';
?>
daniel@daniel-laptop:~$ php test.php
Shutdown: shutdown
Destruct: Foo

[roopurt18]

die() kills the script right then and there; nothing else executes afterward.

 

That's not true. Object destructors and shutdown functions will still run after a call to die() or exit().

 

 

I stand corrected. 

 

However, in terms of how the OP asked the question (multiple queries separated by a die()), if the die() executes then none of the "regular" PHP code (such as additional queries) will execute.  I guess that's how I should have phrased it. 

[gizmola]

One way of answering this question is to put in timings around the scripts and major structural elements of your scripts.  Another is to use XDebug and its profiling mode.