Posts by Tag "Caching"

I managed to work a bit on the blog, enabling me to have new instance in the series, How to refactor and extend your own blog software using Zend Framework. This time: Implementing meaningful Auth and ACL mechanisms and fixing view caching, which did not work in its original implementation due to different users groups sharing the same cached views.

In the last days I came across two in depth tutorials on Zend_Acl and Zend_Auth integration to MVC. Most people propably saw the DevZone article "Zend_Acl and MVC Integration (part 1)" by Aldemar Bernal on the Frameworks Frontpage. Another good article was written by Frank Ruske in the latest german PHP Magazin (Zipped Source Code of the Example). I took the best ideas of both articles and merged them into the existing components of my blog.

This now enables me to cache the site depending on the Auth status of the page user agent. The blog is now caching all views that are generated for guest users. Since there is no "registered" or "member" account yet, this means the blogs content is cached and served from cache for everyone except me when I am logged in. To get this work I added some simple additional check in Matthews Cache View Controller Plugin:

public function dispatchLoopStartup(Zend_Controller_Request_Abstract $request)
{
    $auth = Zend_Auth::getInstance();
    if($auth->hasIdentity()) {
        self::$doNotCache = true;
        return;   
    }
    [..]
}

This prevents caching for registered identities.

Today I implemented caching using a front controller plugin (see Matthews post on Zend Devzone) into the Whitewashing blog software via Zend_Cache and the Filesystem Backend. I ran some superficial Apache Benachmark tests to have a look at the gain change in performance.

First of all i used the complete Plugin from Matthews article on Zend Devzone and a missing function getCache() in the code fragment:

public function getCache()
{
    if( ($response = $this->cache->load($this->key)) != false) {
        return $response;
    }
    return false;
}

I loaded the Plugin into the front controller and initialized it with a Zend_Config_Ini object. This all works very smoothly and caching is ready to begin.

Testing came to the result that with 1000 requests, 10 of them concurent (ab -n 1000 -c 10), which I know is a rather unrealistic assumption for this blog, the request time dropped by half, from six to three seconds (still lot of time, but this isn't the best webserver).

Results without caching

Requests per second:    1.49 [#/sec] (mean)
Time per request:       6695.213 [ms] (mean)

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       26   30   4.0     30      43
Processing:  1556 6452 3372.1   5511   14768
Waiting:     1436 6129 3174.1   5145   14595
Total:       1583 6483 3373.2   5538   14810

Results with caching

Requests per second:    3.03 [#/sec] (mean)
Time per request:       3304.534 [ms] (mean)

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       26   31   6.3     30      73
Processing:   781 3214 1757.7   3103    7445
Waiting:      650 3055 1731.4   2928    7190
Total:        809 3245 1757.8   3135    7475

As said before this testing is superficial, but its gives a broad sense of what perfomance gain is possible with just some lines of code and a temporary directory. Using memcache will probably speed up the process another good amount.

Later I realized that complete page caching (rather than block element caching) sucks when you inject admin area linkes into the navigation, which would allow non-logged in users to see parts of the admin area so I had to disable caching totally. You never know in the first place (you should though). I have to rework my admin area or extend my authentication or the caching plugin somehow. This will probably be the topic another time.