{
    "href": "/post/2006/12/29/the-interesting-case-of-diminishing-responsiveness/",
    "relId": "2006/12/29/the-interesting-case-of-diminishing-responsiveness",
    "title": "The Interesting Case of Diminishing Responsiveness",
    "author": "pmjones",
    "markup": "html",
    "tags": [
        {
            "href": "/tag/benchmarks/",
            "relId": "benchmarks",
            "title": "Benchmarks",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        },
        {
            "href": "/tag/php/",
            "relId": "php",
            "title": "PHP",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        }
    ],
    "created": "2006-12-29 20:04:09 UTC",
    "updated": [
        "2006-12-29 20:04:09 UTC"
    ],
    "html": "<p>I'm working up a second run of PHP framework benchmarks on more powerful hardware than the <a href=\"http://paul-m-jones.com/blog/?p=236\">last time</a>.  I'll talk more about that in a future entry, but in the mean time, I wanted to share an experience that may help you out.</p>\n<p>I was running the <a href=\"http://httpd.apache.org/docs/2.0/programs/ab.html\">ab</a> (Apache Benchmark) tool against <a href=\"http://framework.zend.com\">Zend Framework</a>, <a href=\"http://solarphp.com\">Solar</a>, and <a href=\"http://cakephp.org\">Cake</a>, using the minimalist \"hello world\" applications I described the previously.  The ZF requests/minute were consistent between runs, always \"Z\" amount (plus or minus a couple percentage points).</p>\n<p>But the Solar and Cake requests/minute declined considerably from run to run.  For example, the first benchmark run would yield \"X\" requests/minute; the 2nd run would yield 0.93X, the 3rd 0.85X, then 0.75X, 0.64X, 0.52X, and so on.  This was with the opcode caching turned on; without it, the decline was less severe, but it was still there.  <strong>Very</strong> depressing.</p>\n<p>Because I know Solar better than I know Cake, I started looking around the codebase for places to improve.  Was it the way I was loading classes, thus causing the opcode cache to work inefficiently?  Was it a memory leak in Solar, or PHP itself, or maybe in the web server somehow?</p>\n<p>Nope: it was sessions.</p>\n<p>Solar and Cake each call <code>session_start()</code> on new requests.  Because the \"ab\" tool sends a new request each time, the frameworks start a new session each time.  This means that 1000 requests will generate 1000 new session files. Because the benchmarking makes thousands of requests, the /tmp directory was overflowing with sess_* files (50,000 or more).  Having a very large number of files in a single directory was causing the filesystem to drag, and so response time diminished exponentially over time.</p>\n<p>Notice that Zend Framework did not have this problem, because it doesn't have a session-management class; thus, no sessions were created, explaining why its performance stayed consistent from run to run.)</p>\n<p>The solution (for benchmarking purposes) was to force the session ID value to \u2018abc' by calling <code>session_id('abc')</code> command at the top of the Solar and Cake bootstrap scripts.  This makes the script think there's already a session in place, and so it doesn't create a new file.  Once I did that, the diminishing responsiveness disappeared, and I got consistent results from run to run.</p>\n"
}