Php class performance question…what should I do

includeperformancePHPserver-side-includes

I'm building a webapp using php, ajax, javascript, mysql. I've been worring about something for a while, but not sure if it's really a problem or not. Here's the basic concept of how the code is working…I would like to know if I should change it now, or if it is o.k to use as is. Performance is important to me…over 5,000 users should be able to use the app without much of a performance problem. Part of my worrying is just paranoia of being self taught developer and not knowing all the best practices out there.

Here's the basic webapp functionality:

user executes a call via the browser through onclick event –> ajax call to phpPG1.php. –> phpPG1.php runs a query against the db and stores the results in array, then includes another php page called HTMLphp.php, instantiates new object from HTMLphp.php page, which is a class –> calles function of the class and passes the array that contains the results of a query–>the class functions builds the HTML table and passes back a string –> the phpPG1.php page sends back the string with the table data to the ajax call which displays the string in the given DIV tag it belongs in.

The HTMLphp.php contains all the functions that are used to return HTML tables for the whole webapp. HTMLphp.php would look something like this:

Class HTML_stuff
{
   function html_TABLE1($results_array)
   {

      $string = 'THE HTML TABLE WITH ITS DATA IN IT'
      return $string
   }

   function html_TABLE2($results_array)
   {

      $string = 'THE HTML TABLE WITH ITS DATA IN IT'
      return $string
   }

}

So, here's my question. the HTMLphp.php page has 5,606 lines of code in it right now, which represents 100 or so functions in the class. Basically, every page in my webapp "includes" this page into it in order to be able to use the class functions to display the html tables. I'm about half way done with the webapp, so there will be a lot more lines of code do add to this file. I'm not exactly up to par on how computers execute code, especially when using class objects, but I understand the basics if "interpretive languages" like php.

I'm wondering if this is a bad idea and if I should do something like this: For each function inside the HTML_stuff class just simply remove the code for each function and place it in it's own separate .php page that gets included like this:

Class HTML_stuff
{
   function html_TABLE1($results_array)
   {
      include_once 'TABLE1.php'; //the html table for this function.
      return $string;
   }

   function html_TABLE2($results_array)
   {
      include_once 'TABLE2.php';
      return $string;
   }
}

My basic assumption is that I only include the HTML needed when I make the call to the particular function, thus reducing the overall size of the HTMLphp.php page assuming this would help in overall site performance…am i in left field with this thinking? Part of me is thinking that this is simply the same as the first option, just organized differently and it would do anything to the overall performance. However, I did read somewhere that fewer "includes" is better for performance.

What do other people do, or are there other best practices on how to do this sort of thing? Is it negligible to worry about this with a site of say 5,000 – 10,000 users?

Thanks.

Best Answer

Including the specific PHP file inside a function/method rather than an open include will definitely help things as only the needed items will get included and interpreted. But the PHP intrepreter will still need to go through those 5000 lines code of that huge class, which IMHO is a really bad way to go about it, and will be a major bottleneck.

In reality, 5000-10000 users is not a whole lot, but it again depends on how the usage is going to be. If all of them could be logged in simultaneously, and shooting out requests at your server (something like 10k requests per minute or 166 req/s approx.) and there's little or no caching involved, then it could be a serious bottleneck but that again depends on a lot of factors. Instead, a good way to go about it would be to use some sort of load testing tool like ab or JMeter and find it out for real.

If the results don't look so good after doing these tests, then find out what the bottleneck is. You could use APC or Memcache to implement caching, or various other ways to improve performance. But taking a wild shot in the dark, I'd say that 5k line class is something that you should consider splitting, not just for performance reasons but also for a good design. And perhaps, if the logic of building those HTML pieces is not too complex, you could offload that to the client by sending the data as JSON/XML, and letting Javascript construct the table using this data.

Related Solutions

C++ – the difference between #include and #include “filename”

In practice, the difference is in the location where the preprocessor searches for the included file.

For #include <filename> the preprocessor searches in an implementation dependent manner, normally in search directories pre-designated by the compiler/IDE. This method is normally used to include standard library header files.

For #include "filename" the preprocessor searches first in the same directory as the file containing the directive, and then follows the search path used for the #include <filename> form. This method is normally used to include programmer-defined header files.

A more complete description is available in the GCC documentation on search paths.

Php – How to prevent SQL injection in PHP

The correct way to avoid SQL injection attacks, no matter which database you use, is to separate the data from SQL, so that data stays data and will never be interpreted as commands by the SQL parser. It is possible to create SQL statement with correctly formatted data parts, but if you don't fully understand the details, you should always use prepared statements and parameterized queries. These are SQL statements that are sent to and parsed by the database server separately from any parameters. This way it is impossible for an attacker to inject malicious SQL.

You basically have two options to achieve this:

Using PDO (for any supported database driver):

 $stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name');

 $stmt->execute([ 'name' => $name ]);

 foreach ($stmt as $row) {
     // Do something with $row
 }

Using MySQLi (for MySQL):

 $stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?');
 $stmt->bind_param('s', $name); // 's' specifies the variable type => 'string'

 $stmt->execute();

 $result = $stmt->get_result();
 while ($row = $result->fetch_assoc()) {
     // Do something with $row
 }

If you're connecting to a database other than MySQL, there is a driver-specific second option that you can refer to (for example, pg_prepare() and pg_execute() for PostgreSQL). PDO is the universal option.

Correctly setting up the connection

Note that when using PDO to access a MySQL database real prepared statements are not used by default. To fix this you have to disable the emulation of prepared statements. An example of creating a connection using PDO is:

$dbConnection = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8', 'user', 'password');

$dbConnection->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$dbConnection->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

In the above example the error mode isn't strictly necessary, but it is advised to add it. This way the script will not stop with a Fatal Error when something goes wrong. And it gives the developer the chance to catch any error(s) which are thrown as PDOExceptions.

What is mandatory, however, is the first setAttribute() line, which tells PDO to disable emulated prepared statements and use real prepared statements. This makes sure the statement and the values aren't parsed by PHP before sending it to the MySQL server (giving a possible attacker no chance to inject malicious SQL).

Although you can set the charset in the options of the constructor, it's important to note that 'older' versions of PHP (before 5.3.6) silently ignored the charset parameter in the DSN.

Explanation

The SQL statement you pass to prepare is parsed and compiled by the database server. By specifying parameters (either a ? or a named parameter like :name in the example above) you tell the database engine where you want to filter on. Then when you call execute, the prepared statement is combined with the parameter values you specify.

The important thing here is that the parameter values are combined with the compiled statement, not an SQL string. SQL injection works by tricking the script into including malicious strings when it creates SQL to send to the database. So by sending the actual SQL separately from the parameters, you limit the risk of ending up with something you didn't intend.

Any parameters you send when using a prepared statement will just be treated as strings (although the database engine may do some optimization so parameters may end up as numbers too, of course). In the example above, if the $name variable contains 'Sarah'; DELETE FROM employees the result would simply be a search for the string "'Sarah'; DELETE FROM employees", and you will not end up with an empty table.

Another benefit of using prepared statements is that if you execute the same statement many times in the same session it will only be parsed and compiled once, giving you some speed gains.

Oh, and since you asked about how to do it for an insert, here's an example (using PDO):

$preparedStatement = $db->prepare('INSERT INTO table (column) VALUES (:column)');

$preparedStatement->execute([ 'column' => $unsafeValue ]);

Can prepared statements be used for dynamic queries?

While you can still use prepared statements for the query parameters, the structure of the dynamic query itself cannot be parametrized and certain query features cannot be parametrized.

For these specific scenarios, the best thing to do is use a whitelist filter that restricts the possible values.

// Value whitelist
// $dir can only be 'DESC', otherwise it will be 'ASC'
if (empty($dir) || $dir !== 'DESC') {
   $dir = 'ASC';
}