Are execution time and memory usage the only relevant performance indicators for PHP? What about CPU?

Question

I'm using a PHP framework which has an ActiveRecord system. I quickly ran into trouble with ActiveRecord using a lot of memory and having long execution times for complex queries with large results.

For my reference page (a script generating an array with 10,000 objects) I have manage to reduce memory consumption from 100+ MB to ~15 MB, and reduced execution time from 5+ seconds to ~1.5 seconds.

Are these two measurements the only ones to consider, or should I look at other metrics available to me via PHP?

I have achieved most of the improvements by changing functions that store things in object variables to calculate it on the fly. Therefore I am concerned about CPU, because testing on my localhost there is no CPU shortage... In a live environment, however, CPU is constantly used, because of other requests etc. But how to measure CPU consumption in PHP?

Example: Whenever an active record is instantiated, fields, rules and relations were set in private properties inside each object instance. I have changed this to be functions, always compiling and returning the values, instead of using object properties.

Let the memory do it:

class Record {
  private $relations;
  private $fields;
  function __construct() {
    $this->setRelations();
    $this->setFields();
  }
  private function setRelations() {
    // This process of getting predefined relations, checking for correct data,
    // and some other calculations is done once, on every construct.
    // The result is stored in $this->relations;
    // This costs memory!
  }
  private function setFields() {
    // This process of getting predefined fields, checking for correct data,
    // and some other calculations is done once, on every construct.
    // The result is stored in $this->fields;
    // This costs memory!
  }
  private function getRelations() {
    // This is fast. Loading the set relations from memory.
    return $this->relations;
  }
  private function getFields() {
    // This is fast. Loading the set relations from memory.
    return $this->fields;
  }
}

Let the CPU do it:

class Record {
  function __construct() {
    // Drop the setter methods. Let the CPU work when using the getters.
  }
  private function getRelations() {
    // This process of getting predefined relations, checking for correct data,
    // and some other calculations is done once, on every getFields()
    // This costs CPU!
    return $relations;
  }
  private function getFields() {
    // This process of getting predefined fields, checking for correct data,
    // and some other calculations is done once, on every getFields()
    // This costs CPU!
    return $fields;
  }
}

My two main questions are:

1. What is better?
2. How can I measure CPU consumption?

Answer 1

You forgot one very important factor here: your database. Make sure that it's properly indexed. Do query profiling to see how many rows are examined in a worst case scenario. 9 times out of 10 it is the DB and not the code which leverages it that causes performance issues.

Answer 2

You're probably measuring execution time as wall clock time which will be affected by other things the CPU is doing and whether or not your processes block. For example, when you make a database call, the wall clock keeps running while the CPU is idle. This idle time can be used to handle other requests even though it looks to you like it's busy.

Use a profiler such as XHProf to measure precise memory, CPU, and wall clock costs throughout your application. It measures time taken and memory consumed for each function inclusive and exclusive of the other functions they call, allowing you to drill down into your application.

As to which is more important--time or memory--it depends on the entire application profile. If you have a lot of requests that take large amounts of memory, you'll want to tailor new requests to use more CPU. The same applies in reverse. Further, taking a lot of memory for a short amount of time matters more as you try to handle more requests concurrently.