Tag Archives: PHP

Aaron doesn’t explicitly list the dangers but I can guess that they include overwriting db files. I haven’t looked at SQLite yet however, it’s on the TODO list! 🙂
OK, I read the comments, it’s no more dangerous than having text files lying around, although as the file has to be writeable by the webserver that guarantees certain responsibilites when using them!

Via delicious this morning I have two titbits for your consumption!
Movable Type Ported to PHP – Apparently they’ve done what appears to be a nearly complete port of MT from Perl (bless it) to PHP. This port appears to include support for all current MT tags, it relies on Justin Vincent’s ezSQL DB library and Smarty templates, and even supports a plug-in API.
Why PHP still stinks – from a Perl coder’s perspective. 😉

This technique is an old one. Feed your content through the PHP output buffer using the gzip handler, then at the end flush it out to the browser.
Even if the text doesn’t compress well, just using the output buffer results in slightly less network traffic as the data is sent in one big blob. I have to investigate if the HTTP headers are affected yet but it seems to be working fine.

Zend in the clowns? is a lengthly article about the history of PHP. *phew*

It’s official and everyone and their mum has the news. I’ll let SitePoint PHP Blog provide the summary!

Much more interesting than the previous one is this roundup of various blog posts and articles on PHP performance issues including a link to John’s post today. A must read for all the tips contained within!

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

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!

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!

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!