If you’re reading this blog post, then chances are, you’ve discovered the wonderful PEAR package called System_Daemon. This well-done package offers the ability to turn any PHP script into a daemon and does a good job of making sure there aren’t memory leaks or problems along the way.

There’s a great demo of the package and an explanation of how to get it up and running on the blog of the creator, Kevin von Zonneveld.

The source code for the demo in the post seems complete enough, but it was missing one major component that seems like it would be common for users. The post unfortunately leaves out how one can set the location of the log file or the PID file for the daemon to run. This is a common necessity for many “shared system”-esque environments that exist out there or for those who just happen to be working under restricted permissions. The documentation for the class doesn’t present this information in an easy-to-find manner either.

So, I’m here to let you know that it’s easy as pie… as long as you know the name of the option you’re looking for. By default, the system seemed to want to use the following for the defaults:

/var/run/{appName}/{appName}.pid

and

/var/log/{appName}.log

There’s a couple steps that you’ll want to take so you can get a System_Daemon up and running under the proper user, using files in locations that are accessible by your user.

First, you’ll want to grab the UID and GID of the user you’d like your daemon to run as. This can be achieved by the following command:

id

Once you’ve got your UID and GID, you can get to setting the options for your System_Daemon.

<?php
// Setup
$options = array(
    'appName' => ... 
    ...
    ...
    'appRunAsGID' => your UID,
    'appRunAsUID' => your GID,
    // This sets where you want the log file to be located
    'logLocation' => '/home/uesrname/daemon.log',
    /**
       * This sets where you want the pid file to be created. 
       * Be careful, there's an undocumented restriction on 
       * the naming convention for where the pid file can be 
       * written. It must be in a directory by the same name 
       * as the pid file like the example below. I don't know 
       * why, but it will throw an error if you try to set it 
       * otherwise.
       */
    'appPidLocation' => '/home/username/daemon/daemon.pid'
);
?>

There you have it. By setting the logLocation and appPidLocation options, you can tell the daemon where you’d like the log files to write to and where the pid should be created. Then, by setting your appRunAsGID and appRunAsUID properly, you’ll be up and running scripts as daemons in no time. While the GID and UID settings may have been evident in the aforementioned demo from the author, the logLocation and appPidLocation options may not have been so clear.

If you enjoyed this post, then please consider subscribing to my feed.

Our servers are getting ready to be awaken by the masses. As such, we needed to ensure our servers would not simply fall over if we should get a sudden influx of traffic when we open our doors to everyone.

When we first released our software, we quickly found that we needed to adjust some Apache and PostgreSQL settings in addition to installing a real PG connection pooler in the form of PgBouncer from the wonderful people at Skype. This is on top of our moderately heavy memcached usage that is already working at the application level. The specifics of this phase of development and the changes made to account for our load are for the next post. You can subscribe to my feed if you’d like to know when that is published.

For now, let’s get to the benchmarks.

Due to our previous changes, things were running smoothly. The various instances of the application were running well on their hardware. However, we hadn’t opened the doors for our service yet. We knew that we would need our servers to be able to handle much more load than they were currently handling. So, we set up some nearly identical to production servers and went to town with Apache Bench.

We’re currently running the following versions of applicable software for these tests:

• Debian 4.0
• Apache/2.2.3
• memcached 1.2.8
• PostgreSQL 8.1
• PgBouncer 1.3
• PHP 5.2.0

For the test, I used ApacheBench, Version 2.0.40-dev. Data was collected by running and entering the information into OpenOffice’s Calc. The graphs were also made with this.

The versions of the two caches that were used are Squid Web Proxy Cache 2.6.STABLE5 and Alternative PHP Cache, which is to be included in PHP 6.

The tests were run on a server that sits in the same data center as the other server to minimize latency issues. Each test was performed 3 times to try to get more accurate measurements. Every test was accompanied by the proper headers to ensure mod_deflate was being used. The number of tests (specified by the -n option) was 500 for any concurrency less than 100. For any concurrency greater than 100, 1000 tests were performed. The peak load numbers were gathered from watching top during each test.

First off, let’s look at the results of a 1KB image with and without Squid Cache:

With this smaller file, the results show that Apache is clearly able to deliver roughly 700% more requests per second with Squid

We can also see how Squid allows Apache to handle even 200 concurrent threads requesting the image without breaking a sweat.

In addition, the server was relaxing, not having to create a bunch of Apache processes, when you look at the load compared to with and without Squid.

The same test was performed for an 100KB image to see if the results would be the same.

With the larger file, we can see that the differences are less apparent.

Even the load times look almost the same when you are using a 100KB image instead of a 1KB image.

However, the kicker is when you look at the load that the server is placed under. With Squid, the web server doesn’t have to work as hard since it doesn’t have to create all those Apache processes to answer for the image.

So, one can clearly see that for smaller objects and files, Squid can have a remarkable difference in what you can push out of your server. The results are much clearer when using a testing platform that allows for one to download embedded content. However, that would be suitable for a post some other time. For now, we’ll move on to the results of our other caching solution.

Seeing how Squid provided such excellent results, it was definitely time to look for a caching solution for PHP. APC was the natural choice considering it’s inclusion in the new version of PHP. After exploring it, we installed it and were astonished again by the results. Our server, which was keeling over under 10-20 requests per second was now able to deliver 50-60 requests per second, a 400% increase in performance! But don’t believe me, I’ll let the charts speak for themselves.

These test were performed on a simple Hello World PHP application:

<?php
    echo 'Hello World';
?>

Our prepend configuration means both memcached and PostgreSQL are invoked when our simple Hello World test was run. This was ideal so we had a baseline when more testing is performed on our actual application code. Here are the results of those tests:

It’s easy to see how APC allows for many more requests per second to be served.

The load times offer an even better look at how APC allows the server to remain calm even under high load. Obviously 15-20 second load times was not acceptable. However, APC allowed the load times to remain under 5 seconds even with 200 concurrent threads slamming on the server.

Again, some of the best information is seen in the peak loads. The server is, quite obviously, doing much less work thanks to APC. This is especially evident in the 100-200 concurrency levels when the server was showing loads of 10-12.

So, if you haven’t thought about installing Squid Cache or a PHP cache, like APC yet, hopefully these benchmarks will be enough to convince you of their merit. Considering the ease with which these two caches can be setup and installed, you’re doing yourself and your hardware a disservice without them.

Well, that wraps up this post. Stay tuned for my next post for hints on tuning Apache configuration settings, PostgreSQL settings, and the trials and tribulations of moving an application from a simple site to a completely automated SaaS.

If you liked this post, then please consider subscribing to my feed.

Well then. Another week means another few games in review. If you read the last review then you would know we came upon a little diamond in the rough called Angry, Drunken Dwarves. But now, we deal with the next games on the list of Ubuntu & Open Source games. If you are unaware how to access these games then you may want to visit part 1 of these reviews.

But regardless of all that here we go!

Armagetron Advanced (Website)
From the get go this game had my attention just from the image in the installation screen:

In case you were living in a hole during the 80s, this game is inspired by the 1982 movie Tron.

It is basically a spawn of a game commonly known as Snake. Except, there’s pretty lights, sound, different game play modes and well, online playing experience. If you’ve ever enjoyed playing Nibbles while learning QBasic–

(yes, Nibbles)

–then you should give it a shot. In case you aren’t up for multiplayer, there is also a single player experience. Here’s a screenshot that doesn’t do it much justice:

Overall, this game is well polished and quite a bit of fun. For more screenshots or info, check out the official site here.

Atlantik (Homepage)
This was another one that sounded like it would be something to kill time every once in a while:

“This is a KDE client for playing Monopoly-like boardgames on the monopd network.

It can play any board supported by the network server, including the classic Monopoly game, as well as the Atlantik game in which the property includes several major cities in North America and Europe.”

Well, alright. I’ve got a 25-30 minute block of time. Why not try it out? Let’s see here, we’ll try and get the list of servers first. Hopefully we’ll be able to find a game!

Okay… maybe not so much. Well, let’s see if there’s at least a dumb AI I can play against. Nope: no dice. At this point, I don’t have time to wait for a new game to start or for one of the 5+ people playing to bum rush a game I might host. The screen shots from the website looked promising:

But, it doesn’t look like there’s been any development since 2004. Wow, I can’t believe that was 4 years ago now. Should you feel like going along with the vision of the author, then there is also a designer for the game.

Atomix
Alright, this one is a bit deceiving. By the description, I thought this was going to be a cool game:

“Atomix is a game designed for GNOME in which you have to build molecules, from simple inorganic to extremely complex organic ones, out of isolated atoms.”

However, I was quick to find out that this only partially the case. Although Atomix provides a bit of entertainment, it is very repetitive. There are 19 levels with no randomization options. Oh and when the description said isolated atoms, they just meant that they are located in a weird place on the map:

The game involves selecting an atom and moving it either vertically or horizontally. The atom moves along the board until it stops.

The object is to eventually make enough moves to create a pattern:

Each level is more and more difficult. However, if you get bored on a level, you can just skip it.

If you like this game or games of this nature, then I would highly consider a board game called Richochet Robots. It’s a similar game style in which you compete with people to ‘beat’ a map by coming up with a solution with the least number of moves. Here’s a pic to give you an idea:

Overall, I prefer the board game.

Attal (Homepage)… maybe their Sourcefourge site… nope, nothing there. Oh, here we go, sorta: Attal Lords of Doom Wiki.

Before you go loading this game, you should know that it is still in development. Also note that for some reason, the window it opens in, likes to hide its window decoration behind your top bar. Which, makes accessing any of the menus or closing the game a pain in the butt. I was unable to get a map or campaign, or really anything going so we’re going to have to rely on the screen shot I was able to find:

Nothing to see here. Doesn’t look like there will be anything to see in the near future either.

Balazar (Homepage)
This game is described as a funny adventure game. Unfortunately, playing the game did not produce any adventure, or fun for that matter. It may be that the version I had was bugged as I did not get any reactions when trying to interact with the various people-things, that I ran into as I was running around the bizarre world.

From the screen shots that I saw on their website here, it looks like the game might be fun if I could speak a different language, and if I could get it to work properly. Ultimately, I ended up following the suicide option the game offered more than once to try and get myself back on track.

I wouldn’t try to sink too much time into this one.

Well, that’s it for part 3 of the Ubuntu (open source) gaming review. If you enjoyed this post, please consider subscribing to my RSS feed and be sure to stay tuned for the Ubuntu (Open Source) Games Review – Part 4!