Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

One of the pages in one of my apps runs very slowly on the web server compared to my local test server. There are some radical differences in the environments that might explain it, but I'm hoping for a more solvable solution than that.

Solaris 10
Apache 2.2.9 Prefork
PHP 5.2.6
The server is run on a cluster of 4 not-even-a-year-old Sun boxes, and shouldn't be having any issues performance-wise.

Local Test Server:
Windows XP
Apache 2.2.14 WinNT
PHP 5.3.1
This is actually my own desktop - a decent machine, but should pale in comparison to the Sun boxes.

The application is written with CodeIgniter, and I've used the profiling features within to trace the slowdown to Model::Model(). For example, Model::Model() runs in 0.0006s locally and 0.0045s on the server. When you're loading hundreds of models on a page, this is obviously an issue.

I've cross-posted this here from ServerFault, as it could, potentially, be more closely related to CodeIgniter.

From local, the page takes 2-3 seconds to load. From the server, it's 11-15.

Modules on Local, but not remote:

  • mod_actions
  • mod_asis
  • mod_dav mod_dav_fs
  • mod_dav_lock
  • mod_isapi mod_autoindex_color

Modules on remote, not Local:

  • mod_authn_dbm
  • mod_authn_anon
  • mod_authz_dbm
  • mod_authz_owner
  • mod_cache
  • mod_mem_cache
  • mod_deflate
  • mod_authnz_ldap
  • mod_ldap
  • mod_mime_magic
  • mod_expires
  • mod_unique_id
  • mod_autoindex
  • mod_suexec
  • mod_userdir
  • libphp5
  • mod_dtrace
  • mod_security2


I've been moving my benchmarking progressively down, level by level, and have found the largest discrepancy lies within this chunk of code (which is in the CodeIgniter function Model::_assign_libraries, and is called during a model's constructor):

    $time = microtime()*1000;
    foreach (array_keys(get_object_vars($CI)) as $key)
        if ( ! isset($this->$key) AND $key != $this->_parent_name)
            // In some cases using references can cause
            // problems so we'll conditionally use them
            if ($use_reference == TRUE)
                $this->$key = NULL; // Needed to prevent reference errors with some configurations
                $this->$key =& $CI->$key;
                $this->$key = $CI->$key;
    if (get_class($this) == 'SeatType')
        echo sprintf('%.5f ms|', (microtime()*1000 - $time));

Locally, this prints around 0.48ms every iteration. On the cluster, it prints around 3.9ms every iteration.

I'm beginning to wonder if this problem is outside of Apache/PHP - I copied both the php.ini and htconf files to my local server, and (after removing mod_dtrace, and pretty much nothing else), I actually saw increased performance. (The above check now prints .2ms locally.)

share|improve this question
Could you list the PHP modules as well? As I take it, you have no problem with apache itself? – Joris Aug 26 '10 at 6:18
There are vast differences in the PHP modules. I'll work on compiling a list, but I'm not sure how much it might matter as the php.ini from the server works just as well locally. – Nate Wagar Aug 26 '10 at 14:38
You could try getting the php version aligned to see if the more recent version is faster. Also, I'd contact the codeigniter guy, he's usually pretty responsive and will be interested in this kind of detail. I'm afraid I'm out of ideas.. – Joris Aug 27 '10 at 5:28
Yea, I actually ended up doing just that (set up another apache instance locally that was the same version as the cluster) and it made no difference. – Nate Wagar Aug 27 '10 at 12:59

I assume you have compared PHP/apache settings and loaded modules?

Are you sure it's the Webserver/PHP? I'm not familiar enough with CI to know for sure, but it sounds like Model would connect to a database.

If it indeed does connect to the DB, try checking

  • the connection: hetwork latency/troughput, host name lookup, persistent connections, perhaps even concurrency issues (locking), connection rate limiting in firewall, ...
  • The database: reverse dns lookup, connection rate limiting, overall load
share|improve this answer
See my edit RE the database theory. Model doesn't inherently connect to the DB, that work is done through functions. Since the primary hangup is in the Model constructor, (not to mention the DB benchmarking I have done,) I think I can rule out DB-related issues. – Nate Wagar Aug 25 '10 at 18:41
up vote 0 down vote accepted

What we have discovered is that though the SPARC servers look as though they should perform better than the core2 quad in my PC, they do this completely by threading. Any single thread will actually perform worse. The decrease in performance is likely due to this.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.