Turck MMCache Vs PHP Accelerator

After running MMCache for a day I have mixed feelings about it.
Our site felt faster when I browsed it but when I examined the logs the results were disappointing. Hourly adviews were almost all down by up to a 25% but mostly by 10%, but for an hour or two exceeded the previous day’s ones. By the end of the day, adviews were down by almost 10% in total.

I benchmarked both applications this morning using Siege.
MMCache performed marginally better in all tests, but only by a few percent.
MMCache caused a few problems for us, mainly because it reintroduced a limitation of PHP3. In PHP3 a class or function couldn’t be defined twice, but that’s changed in PHP4. I had to go around editing php files yesterday changing include/require to include_once/require_once which fixed 99.99% of the problems.
I may try it again next week but for now, it’s back to PHP Accelerator.

Out of curiosity I attempted the same benchmark without using any cache/optimizer. I stopped it halfway through when the load average of the box hit 40. Oops.

Related links: The Joy of Turck MMCache | TikiBoosting | which php compiler cache is stable? | PHP caching and optimization

mmCache Vs PHP Accelerator

Several days ago I started tuning and working on the cache and accelerator on my web server at work. Matt suggested I look at the mmCache for PHP, and I have it installed now. It’s early days yet, and adviews are down by a small amount but I’ll have a better idea of general performance tomorrow. It may pay to delete the mmCache cached files every hour like I did with PHP Accelerator too.
More later!

PHP Accelerator – Cache Size Issues

In this email to the ILUG Webdev list I pondered the effect of deleting the cache used by PHP Accelerator on our Apache webserver.

In my ramblings on my blog I (very?) occasionally post something useful.
We use PHP Accelerator( http://www.php-accelerator.co.uk/index.php ) at work and last week I played around with tuning our webserver: link

We saw a dramatic increase in traffic but I wasn’t sure which of the ideas I tried had affected our server so much!
Yesterday I deleted the PHP Accelerator cached files, and lo and behold, we hit another spike in traffic!

“Remember I did some tuning of our server at work? Well, traffic has returned to normal again, but I was told this is a quiet time in the futures market right now. As an exercise I deleted the php Accelerator cached files again and I am seeing another big jump in requests served!
It might pay to remove those files on a daily basis!”

I setup a cron job to remove the phpa files in the morning and if I see the same level of traffic today I may set it up to delete the cached files on an hourly basis tomorrow. I expect the traffic to the site to be slightly less today than yesterday simply because the cached files were deleted much earlier on in the day (4am) so by the time our server gets busy there’ll be a larger cache.

And, shock, horror, I might even try it without the cache at all!

Donncha.

ILUG Web Development
http://mail.linux.ie/mailman/listinfo/webdev/

Well, I can confidently say that deleting the cache does improve performance. In further discussion with Kae on the issue I guessed that:

  • All php files are being cached, probably using the URL of the request as a key to the cached file. This isn’t useful in a very dynamic site.
  • The cache directories can become very large with many thousands of files in one directory. That makes it much harder for the operating system to scan through the file list. Different filesystems handle this better than others.
  • Once the cache is deleted, filename traversal of the cache is faster and core include files are quickly cached again.

It’s worth using the cache despite the obvious cache problems as it makes Smarty templates much faster and we have a lot of shared code that benefits from the caching.
I’m deleting the cache every hour now and expect to see a marked improvement in the web server logs and adviews!

Accelerating PHP Applications

This set of slides from a presentation earlier this month is well worth a read-over. I knew a lot of it, but there were a few surprises too. Hopefully I can report back in a few days time if it made much of an impact on the server!
Later… I’m impressed, but here’s a short summary of what I did first:

  • Stripped the Apache modules (libphp4 went from 5.6MB down to 1.5MB!)
  • Increased the default kernel buffer size as mentioned in the docs. I had already set the max higher, but didn’t know about the default value.
  • Moved php accelerator object files into seperate virtual host directories. I did the same with PHP4 session files.
  • Increased the StartServers, MinSpareServers and MaxSpareServers settings.

The result? Double the network traffic to our web server! I haven’t examined the logfiles yet but hopefully they’ll show an increase in page views!
Much Later… You’ll be happy to hear there was a corresponding increase in page view. If you run a Apache/PHP based website take heed of the tips above and in this presentation!

Experiences of Using PHP in Large Websites

Disclaimer – I haven’t read this yet, I’m heading out the door and home to make myself some dinner! I see that this paper is from 2002 but when the author recommended using Perl I had to link this and read it later! Cracked me up. hehe.

… few languages are as bad as PHP for doing serious development work. The author and his colleagues have had good results with Perl, and believe that languages such as C++, Java, and Python should serve equally well.

PHP, MVC And Smarty Caching

Following on from previous posts on PHP and MVC and in particular on using Smarty caching in the MVC design pattern, I used Smarty to cache the output of an app at work this morning.
I agonised in my last post about where to put the caching, should it go into the viewer, or the model, or the controller?

  • I finally decided to make the viewer responsilble for deciding if the template is cached or not.
  • The controller then asks the viewer if the current page is cached, if it’s not, then it runs whatever functions the model needs to generate the page.

class mvcViewer
{
  function mvcViewer()
  {
    $this->cacheKey = md5( $_SERVER[ 'REQUEST_URI' ] );
  }

  function display()
  {
    // modified to use the cacheKey.
    $this->assign();
    $this->smarty->display( $this->formTplName . ".tpl", $this->cacheKey );
  }

  function is_cached()
  {
    return $this->smarty->is_cached( $this->formTplName . ".tpl", $this->cacheKey );
  }
}

class mvcController
{
  function main()
  {
    switch( $this->page )
    {
    default:
    $this->model = new mvcModel( $form );
    $this->view = new mvcView( $this->model, "mvc-Index" );
    if( $this->view->is_cached() == false )
    {
      $this->model->doSomethingHere();
    }
    break;
    }
  }
}

The beauty of this is that the model doesn’t need to know about the caching at all. The developer can concentrate on the business logic of his application without worrying about the underlying architecture. That’s one reason for keeping the cache key in the viewer too. Don’t lets confuse the developer!
Of course, this presumes the most simplistic caching system, but it would suffice for most cases!

Switching from PHP to Zope/Python

Now here’s an interesting discussion on kuro5hin.org
I’ve always wanted to look at Zope, as it’s based on Python I thought it’d offer me lovely OO programming and fast development. Reading some of the comments here I have to wonder, especially in light of Russell’s rant about the complexity of Java. (Picked up by Keith who might be a deceptive right-wing troll but he writes some good techie stuff!)
But then I think there’s room for both types – pure computer scientists who will most likely drive future ideas, and those that get the job done in the real world.

PHP Newsletter software

PHPList was mentioned on various blogs a few weeks back and we’ve used it here a few times. I’m not 100% happy with it however as it’s missing some glaring features and those make sending emails very difficult.
I searched freshmeat.net earlier today and installed LetterIt, a similar piece of software from Germany.
It’s a fairly simple program, doesn’t look very flash, but it does work well, and we just sent out a mailing to over 1,000 customers this afternoon with it.