Thursday, February 3, 2011

What Apache settings might affect the speed of a CodeIgnitor page load from one server to another?

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.

Server:
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

Edit:

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;
            }
            else
            {
                $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.)

  • 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
    Nate Wagar : 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.
    From Joris
  • 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.

    From Nate Wagar

0 comments:

Post a Comment