Feed aggregator
Alternative PHP Cache (APC) and Drupal Performance
The Alternative PHP Cache (APC) is a free and open opcode cache for PHP. Its goal is to provide a free, open, and robust framework for caching and optimizing PHP intermediate code. So what does this mean for Drupal?
An opcode cache is used to keep compiled PHP code in memory. In a nutshell, when there's a request for a Drupal node, there are all kinds of PHP code that need to be compiled before PHP can execute that code to query the database, create the webpage, and send it to the browser. The more complex your Drupal site, IE the more modules you have installed, the more PHP code that needs to be compiled. This compilation process occurs on every request to your Drupal site. By installing and enabling an opcode cache, your server will compile all the PHP code once, then store it in memory for later use. When a request happens again for the same PHP code, the opcode cache is checked to see if that PHP code is already cached and if it is, the compilation process is skipped and the PHP code is executed straight away. Normally, this will improve the performance of your Drupal site, but there is a condition you should be aware of that can actually slow down your site. It's called memory fragmentation and this condition is worse than having no opcode cache at all.
Symptoms of APC Memory Fragmentation
The symptoms of APC memory fragmentation are somewhat subtle. Over time your site starts slowing to a crawl, but you've not changed anything configuration wise with your site. There's nothing in any of the logs to indicate any problems, but restarting your webserver brings the performance back. Eventually though your site starts running slow again. APC uses shared memory for it's cache. The Ubuntu server systems I use have a default shared memory size of 32MB. You'll need to copy to your site the file apc.php, which can be found with the source to APC itself. This file needs the same owner/group as your Drupal files.
APC memory is fragmented when the output of apc.php looks like this:
At the bottom of this section of the apc.php page you'll see Fragmentation: 100.00%. Not good. What's happening with APC is that it's running out of shared memory and having to discard cached PHP code before it can insert newly compiled PHP code. Keeping track of all these memory segments, their sizes, and figuring out which compiled PHP code can fit into an available memory segment is what's slowing down your Drupal site.
Configuring APC Shared Memory
In order to give APC more shared memory, first determine the existing size of your shared memory segment:
sysctl -a | grep shmmax kernel.shmmax = 33554432This server has 32MB for it's shared memory. It's possible your server may have more shared memory available than what APC is configured to use. To configure your server to use more, use the following command:
sysctl -w kernel.shmmax=50331648This configures APC shared memory for 48MB. The number above is in bytes, so to convert 48MB to bytes, just multiply 48 by 1,048,576 so 48x1,048,576=50331648 bytes.
You'll want to make this a permanent setting so it'll hold after a reboot. You'll need to add the following line to /etc/sysctl.conf file:
kernel.shmmax=50331648You'll also need to modify your APC settings as well. I keep my APC settings in it's own configuration file - apc.conf:
apc.shm_segments="1" apc.shm_size="48"
apc.shm_size is already in MB.
When you've made all the changes to APC, you'll need to restart your webserver.
Correct APC Memory
A Drupal site with a correctly configured APC shared memory size will look like this:
Notice Fragmentation: 0%, and there's a few MB of shared memory still available. You can view the APC configuration and performance of this blog at http://blog.thetajoin.com/apc.php
Hope you'll find this post helpful. If you have any questions, please comment!
-- Mark
Non-Drupal URIs and Lighttpd drupal.lua Script
I have a few other URLs that don't belong to Drupal. If these URLs are received on port 80, they get redirected to port 443 using mod_rewrite. The problem is drupal.lua script will cause non-Drupal URLs to simply get into a redirection loop. So, for example:
http://blog.example.org/nondrupalurl will send constant 301s back to the browser until it times out. What I had to do at the top of drupal.lua was this:
if lighty.env['uri.path']:match('nondrupalurl') then -- print('URI Path Match ' .. lighty.env['uri.path']) return endSo far, this solution works but it's not very elegant, especially if there are a bunch of non-Drupal URLs. My site only has two, so it's not that big of a deal to hard code this into drupal.lua.
The other thing I'd like to know is how do you do your Lua dev?






