The Alternative PHP Cache (APC) is a free and open opcode cache for PHP. It can help speed up your Magento installations.

First, install the PHP APC package (Assuming you are using Ubuntu as your web server):

sudo apt-get install php-apc

Now configure APC for use with Magento. Edit /etc/php5/conf.d/apc.ini:

extension=apc.so
apc.enabled = On
apc.optimization  = 0
apc.shm_segments = 1
apc.shm_size = 512
apc.ttl = 7200
apc.user_ttl  = 720
apc.num_files_hint = 1024
apc.mmap_file_mask = /tmp/apc.XXXXXX
apc.enable_cli = 1
apc.cache_by_default  = 1
apc.max_file_size = 10M
apc.stat = 0
#apc.include_once_override = 1

Once you have changed the apc.ini file you will need to restart the Apache Web Server:

service apache2 restart

Finally, configure Magento to use APC: Edit app/etc/local.xml and add the following:

<global>
....
    <cache>
        <backend>apc</backend>
        <prefix>MAGE_</prefix>
    </cache>
</global>

That’s all there is to it. To check that APC is being used you can use the APC.php file as discussed in my post.

Speed testing more than one url

If you need to test more than one URL then you will need to tell Siege to use a file to load the URL’s from. Simply create a text file called urls.txt and add each URL you want to test on a separate line.

$ vim urls.txt
 
http://www.mywebsite.com/about-us/
http://www.mywebsite.com/contact-us/

To tell Siege to use your urls.txt you need to use the -f parameter.

siege -v -c10 --reps=once -d5 -f urls.txt 
** SIEGE 2.72
** Preparing 10 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200   0.61 secs:    7817 bytes ==> /about-us/
HTTP/1.1 200   0.66 secs:    7821 bytes ==> /about-us/
HTTP/1.1 200   0.67 secs:    7821 bytes ==> /about-us/
HTTP/1.1 200   0.67 secs:    7821 bytes ==> /about-us/
HTTP/1.1 200   0.72 secs:    7818 bytes ==> /about-us/
HTTP/1.1 200   0.74 secs:    7821 bytes ==> /about-us/
HTTP/1.1 200   0.78 secs:    7821 bytes ==> /about-us/
HTTP/1.1 200   0.60 secs:    8050 bytes ==> /contact-us/
HTTP/1.1 200   0.60 secs:    8050 bytes ==> /contact-us/
HTTP/1.1 200   0.63 secs:    7821 bytes ==> /about-us/
HTTP/1.1 200   0.68 secs:    7819 bytes ==> /about-us/
HTTP/1.1 200   0.69 secs:    7821 bytes ==> /about-us/
HTTP/1.1 200   0.61 secs:    8052 bytes ==> /contact-us/
HTTP/1.1 200   0.60 secs:    8046 bytes ==> /contact-us/
HTTP/1.1 200   0.61 secs:    8043 bytes ==> /contact-us/
HTTP/1.1 200   0.62 secs:    8051 bytes ==> /contact-us/
HTTP/1.1 200   0.60 secs:    8044 bytes ==> /contact-us/
HTTP/1.1 200   0.61 secs:    8052 bytes ==> /contact-us/
HTTP/1.1 200   0.65 secs:    8051 bytes ==> /contact-us/
HTTP/1.1 200   0.62 secs:    8051 bytes ==> /contact-us/
done.
 
Transactions:		          20 hits
Availability:		      100.00 %
Elapsed time:		        9.32 secs
Data transferred:	        0.15 MB
Response time:		        0.65 secs
Transaction rate:	        2.15 trans/sec
Throughput:		        0.02 MB/sec
Concurrency:		        1.39
Successful transactions:          20
Failed transactions:	           0
Longest transaction:	        0.78
Shortest transaction:	        0.60

As you can see, Siege has requested both URL’s from the file at random intervals.

Speed testing a web page with all it’s assets (JavaScript,CSS, Images etc)

Everything we have done so far has been testing single html files which is useful for testing page generation. But what if we need to find out the speed of a whole web page including all the images, javascript, css files, video etc? Simple, you put all the URL’s of all the webpage assets into the urls.txt file. However, doing this by hand can be quite painful. Fortunately we can use a proxy tool to create the URL’s for us.

Introducing sproxy

The author of Siege, Jeffrey Fulmer (see the siege websute) has also written a companion program to Siege called ‘sproxy’. Quite simple, sproxy logs all urls to a text file for use with Siege. To do this you need to tell your web browser to connect to the proxy and then simply load your webpage.

Installing sproxy on Ubuntu (and derivatives)

Unlike Siege, sproxy doesn’t appear to be packaged for Ubuntu, so we need to compile and install it.

$ curl http://www.joedog.org/pub/sproxy/sproxy-latest.tar.gz -o sproxy-latest.tar.gz
$ tar xvfz sproxy-latest.tar.gz
$ cd sproxy-1.02/
$ ./configure
$ make
$ sudo make install

Once sproxy is installed you should configure your browser to use the proxy. In Firefox, go to Preferences > Advanced > Network and click the ‘settings’ button. Then select ‘Manual Proxy Configuration’ and enter ’127.0.0.1′ in the ‘HTTP Proxy:’ field, and ’9001′ in the Port Field. Once you have done this, click ‘OK’ and close your Preferences dialog.
[screenie]

Go to your terminal and launch sproxy. By default it will bind to the localhost and use port 9001. Now go to your browser and load a single page on your website. When it has finished loading, go back to your terminal and quit sproxy using CTRL-C.

andrew@andrew-laptop ~ $ sproxy
SPROXY v1.02 listening on port 9001
...appending HTTP requests to: /home/andrew/urls.txt
...default connection timeout: 120 seconds
^C
andrew@andrew-laptop ~ $

Now view your urls.txt file and you should see the URL’s of all images,css and javascript (and any other assets) that your web page contains. Check the file through and remove any URL’s you don’t want to test such as Google Analytics.

Once you’ve cleaned your urls.txt file you can then siege it as we did previously. This time we’ll simulate one user making one request of the whole web page, assets and all.

siege  -c1 --reps=once -f urls.txt 
** SIEGE 2.72
** Preparing 1 concurrent users for battle.
The server is now under siege..      done.
 
Transactions:		          38 hits
Availability:		      100.00 %
Elapsed time:		       26.23 secs
Data transferred:	        0.38 MB
Response time:		        0.19 secs
Transaction rate:	        1.45 trans/sec
Throughput:		        0.01 MB/sec
Concurrency:		        0.27
Successful transactions:          38
Failed transactions:	           0
Longest transaction:	        0.62
Shortest transaction:	        0.10

Simulate Browser Caching

Siege, by default, requests each URL from the server regardless of any expiry headers sent by the server. This allows us to simulate a page load with an empty cache but we can also configure Siege to request the URLs and respect any expires headers that are sent. To do this, open your ~/.siegerc file in your text editor and find the Cache revalidation section (around line 101 in my file). Simply change the line to ‘cache = true’, save it and re-run your test, this time with the -v flag.

As a website owner your website performance is crucial to your business. You would expect your website to be able to cope with thousands of visits per minute but unless you’ve prepared for it by purchasing quality hosting services and tuning the servers there is a good change that your website won’t cope with a lot of traffic and in a lot of cases can lead to a loss of revenue. Tuning your web servers to handle more traffic without crashing is a science of its own and there are many ways to improve performance but before you dive in and start tweaking your Apache or MySQL configurations you need some way of measuring the website performance improvements you make. There are many tools available for speed testing your website and they all have their merits. One tool that is easy to use is Siege (Website).

Siege is a command line program that helps measure the speed of your website and provides a summary of the performance which you can use to measure the changes on your web servers.

Installing Siege on Ubuntu (and derivatives)

Siege is part of the standard ubuntu packages, so you should install it in the standard way:

sudo apt-get install siege

Additionally, you can download, compile and install the latest version of Siege. Use the steps below.

Installing Siege on Mac OSX

As far as I am aware there isn’t a package version of Siege for OSX so you can either download,compile and install Siege manually or use Homebrew to install.

Manually compile and install

Do the following to download, compile and install Siege on your OSX.

$ curl http://www.joedog.org/pub/siege/siege-latest.tar.gz -o siege-latest.tar.gz
$ tar xvfz siege-latest.tar.gz
$ cd siege-2.72
$ ./configure
$ make
$ make install

This will install Seige to /usr/local/bin/siege.

Installation via Homebrew

First, install homebrew using the instructions from https://github.com/mxcl/homebrew/wiki/installation. Once installed you can simply install Siege in one command:

$ brew install siege

Using Siege

Now that Siege is installed we can begin speed testing your website. First thing to do is to create the siege config file in your home directory.

~ $ siege.config 
New configuration template added to /home/andrew/.siegerc
Run siege -C to view the current settings in that file

We’ll run our first test shortly but first a word of warning!. Siege is a powerful tool and can quite easily bring your web servers down if used incorrectly! I recommend you test this on your own websites and not those of a third party.

OK, lets run our first test. We’ll test the homepage of our site by simulating 10 users with a delay of up to 10 seconds between requests.

~ $ siege -c10 -d10 -r1 -v http://www.mywebsite.com/
** SIEGE 2.72
** Preparing 10 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200   0.12 secs:    4123 bytes ==> /
HTTP/1.1 200   0.11 secs:    4123 bytes ==> /
HTTP/1.1 200   0.11 secs:    4123 bytes ==> /
HTTP/1.1 200   0.12 secs:    4123 bytes ==> /
HTTP/1.1 200   0.11 secs:    4123 bytes ==> /
HTTP/1.1 200   0.13 secs:    4123 bytes ==> /
HTTP/1.1 200   0.11 secs:    4123 bytes ==> /
HTTP/1.1 200   0.11 secs:    4123 bytes ==> /
HTTP/1.1 200   0.12 secs:    4123 bytes ==> /
HTTP/1.1 200   0.11 secs:    4123 bytes ==> /
done.
 
Transactions:		          10 hits
Availability:		      100.00 %
Elapsed time:		        8.12 secs
Data transferred:	        0.04 MB
Response time:		        0.11 secs
Transaction rate:	        1.23 trans/sec
Throughput:		        0.00 MB/sec
Concurrency:		        0.14
Successful transactions:          10
Failed transactions:	           0
Longest transaction:	        0.13
Shortest transaction:	        0.11

Let’s break this down a little. First we entered the siege command with a number of parameters:

• -c10 is the number of concurrent users we want to simulate.
• -r1 is the number of repetitions, in this case, 1.
• -d10 is the delay between each user request (each siege simulated users sleeps for a random interval in seconds between 0 and 10).
• -v is to show the output of each request.
• Finally the url to test. My tests were run on a bona fide website but I have changed the domain name in my examples.

Once you hit enter Siege will run and output it’s results. The first set of results shows each request. This shows the HTTP method, the returned HTTP result code (200 is good ), the time taken in seconds, the number of bytes retreived and finally the URL requested. You can edit your ~/.siegerc to show the full URL if you need to.

After the requests have completed Siege will show you a summary report. This report is documented in the siege man page, which I have reproduced below:

Transactions
The number of server hits. In the example, 25 simulated users [ -c25 ] each hit the server 10 times [ -r10 ], a total of 250 transactions. It is possible for the number of transactions to exceed the number of hits that were scheduled. Siege counts every server hit a transaction, which means redirections and authentication challenges count as two hits, not one. With this regard, siege follows the HTTP specification and it mimics browser behavior.

Availability
This is the percentage of socket connections successfully handled by the server. It is the result of socket failures (including timeouts) divided by the sum of all connection attempts. This number does not include 400 and 500 level server errors which are recorded in “Failed transactions” described below.

Elapsed time
The duration of the entire siege test. This is measured from the time the user invokes siege until the last simulated user completes its transactions. Shown above, the test took 14.67 seconds to complete.

Data transferred
The sum of data transferred to every siege simulated user. It includes the header information as well as content. Because it includes header information, the number reported by siege will be larger then the number reported by the server. In internet mode, which hits random URLs in a configuration file, this number is expected to vary from run to run.

Response time
The average time it took to respond to each simulated user’s requests.

Transaction rate
The average number of transactions the server was able to handle per second, in a nutshell: transactions divided by elapsed time.

Throughput
The average number of bytes transferred every second from the server to all the simulated users.

Concurrency
The average number of simultaneous connections, a number which rises as server performance decreases.

Successful transactions
The number of times the server responded with a return code < 400.

Failed transactions
The number of times the server responded with a return code >= 400 plus the sum of all failed socket transactions which includes socket timeouts.

Longest transaction
The greatest amount of time that any single transaction took, out of all transactions.

Shortest transaction
The smallest amount of time that any single transaction took, out of all transactions.

The truth is, there is no one single fix for the problem. Sometimes changing the permissions of the WordPress site will sort the problem out, but quite often I see blog posts) where the problem still persists.

I had the same problem on many of the sites we host at work and I spend a few hours getting to the bottom of it. We set permissions on our hosting to be quite restrictive and discourage the use of setting directory permissions as 0777 as it can be vulnerable to exploits. We set files as 0644 and directories at 0754, with writeable folders as 0775, Files and directories are owned by a user and are in the same group as the web server. I tried changing the permissions, even going as far as setting the public_html directory to 0777 (temporarily) and yet the WordPress Upgrade would fail.

I fired up my IDE and debugger (Netbeans and Xdebug) and stepped through the WordPress code line by line to identify where it was failing to complete the update and soon discovered it was failing when listing a directory using PHP’s ftp_nlist() function. This would return as boolean false, indicating there was an issue. Just before this happens, the WordPress code sets FTP passive mode to boolean true and this is where the problem was being caused.

The cause was down to a configuration in the FTP server running on our hosts. We use Masquerading to provide the external IP address of the server when switching to passive mode but as the connection was from localhost, this was causing passive mode to fail. A simple configuration change fixed the issue for us.

If you don’t have root access on your hosts server you can fix this by editing wp-admin/includes/class-wp-filesystem-ftpext.php and changing the FTP passive mode to false on line 84:

~$: vi wp-admin/includes/class-wp-filesystem-ftpext.php +84

 83                 //Set the Connection to use Passive FTP
 84                 @ftp_pasv( $this->link, false ); # was @ftp_pasv( $this->link, true);

Note that this will be overwritten when you upgrade WordPress the next time.

Although this is a mis-configuration in the FTP server it would be nice if there was an option in WordPress to choose passive mode or not. There is a patch and a bug report on the WordPress Trac (see http://core.trac.wordpress.org/ticket/7940) but this was closed as the developers of WordPress chose to force passive mode to ‘on’.

From left to right these are:

Shutter

http://shutter-project.org/

Shutter is a feature-rich screenshot program. You can take a screenshot of a specific area, window, your whole screen, or even of a website – apply different effects to it, draw on it to highlight points, and then upload to an image hosting site, all within one window. .

Autokey

AutoKey is a desktop automation utility for Linux and X11. It allows you to manage collection of scripts and phrases, and assign abbreviations and hotkeys to these. This allows you to execute a script or insert text on demand in whatever program you are using.

Pidgin

http://www.pidgin.im

Pidgin is a chat program which lets you log in to accounts on multiple chat networks simultaneously. This means that you can be chatting with friends on MSN, talking to a friend on Google Talk, and sitting in a Yahoo chat room all at the same time.

Pidgin runs on Windows, Linux, and other UNIX operating system

Gnome Do

http://do.davebsd.com/

GNOME Do allows you to quickly search for many items present on your desktop or the web, and perform useful actions on those items.

GNOME Do is inspired by Quicksilver & GNOME Launch Box.

Parcellite

http://parcellite.sourceforge.net/

Parcellite is a lightweight GTK+ clipboard manager. This is a stripped down, basic-features-only clipboard manager with a small memory footprint for those who like simplicity.

Tomboy

http://projects.gnome.org/tomboy/?pagewanted=all

Tomboy is a desktop note-taking application for Linux, Unix, Windows, and Mac OS X. Simple and easy to use, but with potential to help you organize the ideas and information you deal with every day.

Dropbox

http://www.dropbox.com/

Dropbox is a free service that lets you bring your photos, docs, and videos anywhere and share them easily. Never email yourself a file again!

Instead of setting up Exim or Sendmail and configuring it to redirect mail to my account I discovered that you can use a Python one liner to output all SMTP to the command line. Here’s how it’s done:

Test SMTP with a dummy Server in Python

sudo python -m smtpd -n -c DebuggingServer localhost:25

The sudo is needed as you can’t bind to a port number lower than 1024 as a normal user.

To use it you must copy and extract the file to your website document root.

cd ~/mysite/
cp /usr/share/doc/php-apc/apc.php.gz ./
gunzip apc.php.gz

To access the ‘user cache entries’ you will need to add a username and password to the apc.php script. These can be found near line 41.

Once done you can access http://mysite.com/apc.php and you will see the APC page. As the advert says, “simples”.

I’ve been ‘struggling’ to find the ultimate IM Client on my Ubuntu setup. Some do most things but there is usually some functionality missing. Here’s the list of what I want from an IM Client:

• Multiple Accounts (Hotmail/Windows Live, Google, Jabber)
• Chat rooms (Jabber)
• Bring chat to front when new message received or a new message in the room
• history log
• file transfers
• Block contacts
• small/compact contacts list

There are many available clients for Linux.

• Empathy
• Pidgin
• Kopete
• PSi/PSi Plus
• Swift
• Gajim

Empathy

This is the default with Ubuntu and integrates with the system nicely. However, I don’t like the notification system. I want it to bring up the chat window when a message is received, either in a single chat or a room. Also, the sound notifications don’t seem to work on both my Maverick and Natty installs.

Pidgin

I’ve been using pidgin for a long time and keep coming back to it. It does everything I need it to.

To do this you need to tell vim to log it’s output to a logfile:

andrew@andrew$ vim -V9vim.log myfile

This will then create a logfile called vim.log in the current working directory.

<?php 
class Test {
        public function __construct()
       {
            $this->name = 'Andrew';
        }
 
        public function __get($name) {
                echo '__get: ' . $name . "\n";
        }
 
        public function __set($name, $value) {
                echo '__set: ' . $name . ', ' . $value . "\n";
        }
}
 
$name = new Test();
$name->name = 'Amy';
 
echo $name->name;

Here’s the output:

andrew@adele:~$ php check_getters.php
__set: name, Andrew
__set: name, Amy
__get: name

Answer: Yes they do!