Optimization tips?

Ask your host what specific scripts were going over

Hah! I once worked with a young web programmer who, while he was learning PHP, regularly sent a quad-CPU web server to 100% CPU utilisation with just the simplest chunks of code. I had to spend a lot of time watching over the apps he was working on, and his access to our production web server at the time.

Aside from simple bad code, the main issue with shared hosts running PHP web apps is usually MySQL related:  too many open connections, too many simultaneous queries etc. MySQL can be such a pig. Minimise any queries your PHP app generates - via caching or turning off bells and whistles in your app (even in PunBB) - and you generally won't go far wrong.

It is interesting to watch the output of the 'top' command on a shared host with lots of users. Sure MySQL is there at the top of the CPU pile a lot, and PHP too less frequently, but both are regularly outdone by spamd (SpamAssassin) and exim (SMTP service) grabbing a LOT of CPU a LOT of the time.

Your host better be certain that PHP is the culprit in your CPU woes - it usually has a lot of competition for CPU on most shared servers.

PHP caches = good.

You might want to look at this benchmarks page if you are exploring PHP caches:

http://itst.net/wp-content/uploads/2006 … eview.html

Xcache is the latest and greatest open-source PHP cache, and seemingly the most up-to-date and well supported. It's what all the vBulletin kiddies are using nowadays to eke the most performance out of their hosting accounts.

Of those on that list, I've only used eAccelerator (installed in a VPS environment as a RPM = easy, so far trouble free).

You may also want to look at a simple PHP cache called jpcache - http://www.jpcache.com - as well. Unlike some of the others,  jpcache is relatively simple to set up and doesn't require the deeper level of system access to install that things like APC and eAccelerator do.

As a general guide to optimizing MySQL/PHP apps, the following is also a good reference I always point people to, even though it is focussed on the Typo 3 CMS.

http://typo3.org/development/articles/t … rformance/

The page on PHP tuning at:

http://typo3.org/development/articles/t … ce/page/4/

illustrates very well the virtues of using a PHP cache.

FYI

No problems. I have successfully run jpcache for over 18 months on a site on a shared hosting account (PHP4) with no problems. It was indeed effective in speeding up a CMS I needed to use, since the web host didn't offer support for any other PHP cache. That site is now dis-continued, but if I needed to I would use jpcache again.

I haven't tried it with punBB though.

Any cache may cause problems with dynamic services like RSS feeds, I guess. Caches love relatively 'slow moving' pages, not pages that need to show changes all the time.

Anyway, clear your jpcache cache directory on your server of any old previously generated cache files, clear your browser cache, and try again.

Re those IE errors - perhaps have a look at your settings for jpcache too - you might want to check that your settings for output compression aren't conflicting with something that for example Apache may also be trying to do - ie jpcache may be trying to do compression whilst so too may be Apache. IE supports receiving GZIP compressed content very well, but not if it is mangled. Set the compression level to the lower end of the scale and see if that works better.

You also face the issue when using a php app like PunBB (which does come caching of its own) with jpcache that you may see caching upon caching, the results of which may not be OK. Wherever possible, I suggest always ensuring that just one caching/compression tool is at work.

But I am sure with just a bit of tuning, jpcache will probably settle down and start to work reliably.

In terms of other caches, as an alternative maybe check out xcache - http://xcache.lighttpd.net/

A guide to installing it is here:

http://www.ibm.com/developerworks/libra … fastapps1/

It seems on the way to becoming the cache of choice for a lot of PHP folks, and it certainly is more actively supported than jpcache